What We Got Wrong Building an Export Quote Tool
Field notes on the decisions, dead ends and cuts from a real export quoting build.
What You Need to Know
The biggest trade-offs in building an export quote tool are: how much margin logic to encode vs leave to the rep, whether to pull live freight rates or use fixed buffers, and when to stop adding fields. Most first versions over-engineer the input side and under-engineer the output — the document the customer actually sees.
Best For
- ✓Exporters evaluating whether to build or configure a quoting tool
- ✓Ops leads or commercial managers who've inherited a quoting spreadsheet that's starting to cause margin problems
- ✓Founders considering commissioning a custom trade ops tool for the first time
Not For
- ×Importers looking for landed cost tools (different problem, different build)
- ×Teams whose quoting process is already systemised in a working CPQ or ERP
- ×Businesses quoting services rather than physical goods
Key Takeaways
- ✓ Quote input forms almost always collect data that already exists in a CRM or ERP — remove those fields before you build.
- ✓ A fixed rate card with a configurable FX/freight buffer is more operationally stable than live rate feeds for most exporters.
- ✓ Write your output document — a real quote, for a real customer — before speccing the input form. The document is the actual spec.
- ✓ Approval workflow gates on large quotes usually create workarounds; flags with visibility achieve accountability without bad data.
- ✓ Custom build is justified by a specific, recurring failure — not a general desire for a better system.
The first spec for this project was four pages long and had twenty-three input fields on the quote form. By the time we shipped, it was nine fields and a handful of calculated outputs. The cuts hurt in the moment. They were the right call.\n\nThis is a field note from building a quoting tool for a mid-sized exporter — consumer goods, mixed freight modes, customers in the UK, EU and Australia. Not a sanitised case study. A record of what the spec got wrong, what we argued about, and what we'd change if we started again.\n\n## The spec assumed reps wanted to enter more data\n\nThe original brief came from the commercial director, not the sales reps. That matters. Directors see margin erosion on reports; reps see a quote that has to go out in twenty minutes while a customer is on the phone.\n\nTwenty-three fields felt thorough to the director. To a rep, it was a wall. The first thing we heard in user testing — two reps, one afternoon, nothing fancy — was: "I'd just go back to the spreadsheet."\n\nSo we did a triage pass. We asked: which fields change the price, and which fields just get copied onto the document at the end? Anything in the second category got moved to a later screen or pulled from the customer record automatically. That alone cut the form by a third.\n\nThe lesson: quote input forms almost always conflate data collection with data entry. If your CRM or ERP already holds the customer's default currency, delivery address and payment terms, a quote tool that asks for them again isn't smart — it's just a more fragile spreadsheet.\n\n## The FX and freight buffer argument\n\nThis is where the project nearly stalled.\n\nThe exporter quoted in GBP to UK customers and in AUD to Australian customers, but bought freight in USD and sometimes EUR. Their existing spreadsheet had a single FX rate cell that someone updated on Mondays. Which meant quotes sent on Fridays used a rate that was five days old — and on a £40,000 shipment, a 1.5% FX move is £600 off your margin before you've even confirmed the booking.\n\nWe had three options:\n\n1. Pull live exchange rates via an API and apply them to each quote.\n2. Use a fixed internal rate set by the finance team, refreshed weekly.\n3. Apply a configurable buffer on top of whatever rate was used — say, 2% — so the quote always had a cushion.\n\nOption 1 sounds cleanest. It isn't. Live rates create a problem: a quote you sent yesterday is now showing a different margin in the system today, even though nothing changed operationally. Finance hated that. It also introduces a dependency on a third-party API that can go down.\n\nOption 2 was what they already had, just automated. It solved the Monday-refresh problem but didn't help with rate risk on longer-validity quotes.\n\nOption 3 — a buffer — was what we shipped. The finance team sets a rate weekly, the system applies a configurable buffer (they landed on 1.8%), and the rep sees a floor price, not a live rate. It's conservative. It costs them the occasional win on price. But margin holds, and the ops team isn't chasing currency losses on accepted quotes.\n\nIf you're building something similar, the Quote Margin Protector tool is a good way to pressure-test your buffer logic before you commit it to a system — run a few real shipment scenarios through it.\n\n## What we cut from the first version\n\nFreight rate integration. The original spec included a live rate pull from their freight forwarder's API. We cut it in week two. The forwarder's API was unreliable, the rate structure was more complex than the documentation suggested, and the exporter's ops lead said — correctly — that they renegotiate rates every quarter anyway, so live rates would be out of date within weeks. We replaced it with a rate card table the ops team maintains. Uglier, but it works and they control it.\n\nApproval workflows. The director wanted a multi-level approval flow for quotes over a certain value. We pushed back. In a team of eight reps, a formal approval gate adds two to four hours to every large quote — right when speed matters most. We shipped a simple flag instead: quotes over the threshold get a notification to the commercial director but don't require sign-off to send. They can intervene if they want. In three months of use, they've intervened twice.\n\nPDF template customisation. The original brief included a template builder so each rep could adjust the quote layout. Nobody actually wanted that — they wanted the standard template to look professional, not a blank canvas. We hardcoded one template, made it clean, and moved on. The time we saved went into the margin calculation logic instead.\n\nThis is a pattern worth naming: features that sound like flexibility usually mean the spec-writer doesn't want to make a decision. Push for the decision.\n\n## The output side was underspecified\n\nWe spent most of the early sprints on inputs — the form, the rate logic, the customer lookup. The output, the actual PDF quote the customer receives, got two lines in the spec: "generate a professional quote document."\n\nThat vagueness cost us two extra weeks.\n\nThe exporter had four different quote formats depending on product category, three different payment term structures, two different Incoterm options for Australian customers versus UK customers, and a legal disclaimer that the compliance team wanted positioned in a specific place. None of that was in the spec.\n\nIf you're commissioning something like this, write out a sample quote document before you start — a real one, for a real customer — and mark every field that varies. That document is the actual output spec. Everything else is input infrastructure.\n\nFor context on how Incoterm choices affect what appears on export documents and where liability sits, the Incoterms Chooser is a useful reference to have open during that conversation.\n\n## The thing we got right: keeping a human in the margin check\n\nOne decision the commercial director pushed for early and that we nearly argued him out of: the system flags but doesn't block quotes where the calculated margin falls below a threshold. A rep can still send a low-margin quote. They just see a yellow warning and the delta from their floor.\n\nWe thought that was too soft. We were wrong. Rigid blocks create workarounds — reps start entering higher freight estimates to get the margin above the threshold. Flags with visibility create accountability without forcing bad data.\n\nThis connects to a broader point about keeping humans in the document review loop: the goal isn't to remove judgement from the process, it's to give the person exercising judgement better information in less time.\n\n## Build vs buy: when does custom make sense here?\n\nThe honest answer is: rarely at first. Most exporters who think they need a custom quote tool actually need a properly configured instance of something like Cin7, DEAR or a CPQ module bolted onto their CRM — before they pay for a build.\n\nThe case for custom is narrow but real: when your freight rate structure is idiosyncratic enough that off-the-shelf margin logic doesn't hold, when you're quoting across multiple modes (air, sea, courier) with different chargeable weight rules, or when the output document needs to carry product-level detail that generic CPQ tools flatten into a single line.\n\nThis exporter hit all three. That's what made the build justifiable. But it took a discovery session — one day, the right people in the room, a printout of three real quotes — to confirm it. Don't commission a build until you've done that session. As covered in why freight quoting spreadsheets start costing deals, the trigger for a build is usually a specific, recurring failure — not a general sense that things could be better.\n\n## What we'd specify differently\n\nIf we ran this project again, the spec would open with the output document, not the input form. It would include a rate-buffer policy signed off by finance before a line of code was written. And it would cut the approval workflow on day one instead of week four.\n\nThe quote tool that shipped is faster, less error-prone and produces better-looking documents than the spreadsheet it replaced. The reps use it. That's the bar.\n\nIf you're at the point of thinking a custom build might be worth it — bring a printout of your last five quotes and a note on where they went wrong. That's the brief.
Useful tool
Try Samvara's Import/Export Quote-Time Estimator — Hours, cost and capacity from slow quotes.
How Samvara researches this guide
We write for exhibition organisers and import/export operators in the UK and Australia. Guides favour specific, verifiable operational advice over generic tips — grounded in systems we have shipped, client workflows, and current industry practice. We revisit articles as tooling and regulations change.
Written by
Shreyansh Doshi, Founder of Samvara
Shreyansh Doshi is the founder of Samvara Technologies, a product studio building operator software and SaaS products for exhibition, import/export, travel and fitness businesses in the UK and Australia. He writes about product delivery, operations systems, and where AI does and does not belong in a real workflow.
Keep Reading
More in Field Notes