What to Specify Before You Commission Export Ops Software

Most export ops software projects don't fail at the build stage. They fail three weeks into discovery when the developer asks "so what exactly does your quoting process look like?" and the ops lead says "it depends."

It always depends. That's the point. The question is whether your brief forces someone else to reverse-engineer your business — or whether you've already mapped it yourself.

Here's what a useful spec actually contains, written for UK and Australian exporters who are about to hand this problem to a software team.

Start with the document set, not the feature list

The instinct when writing a brief is to list features: "we need a portal, we need a dashboard, we need automated notifications." Resist it. Start instead with the documents your business generates and receives.

For a typical UK or Australian exporter, that list might include: commercial invoice, packing list, certificate of origin, bill of lading or airway bill, export customs entry, and any trade-lane-specific permits or phytosanitary certificates. For some markets — say, goods into the Gulf or into South-East Asia — there are additional attestations, specific formatting requirements, and sometimes Arabic or Malay translations of key fields.

Every one of those documents has a source of truth for its data (a sales order, a product catalogue, a freight booking), and every time someone re-enters that data by hand you have a failure point. A useful spec names those failure points explicitly. "Packing list is typed into a Word template from the proforma invoice every time" is a statement a developer can act on. "We need better document management" is not.

Use the Document Readiness Checklist to walk your trade lanes before you write anything — it will surface the gaps you've stopped noticing.

Map the handoffs, not the happy path

Your brief will naturally describe what happens when everything goes right. A shipment comes in, the forwarder confirms, the invoice goes out, goods clear customs. Fine. But software is only worth building if it handles the exceptions without someone dropping everything.

Map every point where data crosses a boundary between people, systems or companies:

• Sales confirms an order → ops needs to raise a commercial invoice: is that a copy-paste from the CRM, a separate spreadsheet, a template in Outlook?
• Freight rates are confirmed → landed cost needs updating on the quote: who does that, how long does it take, and what happens if the rate changes after the client has agreed?
• A customs hold is flagged → who finds out first, through what channel, and who has authority to release additional documentation?

Each of those handoffs is a candidate for automation or at least structured data capture. If your brief doesn't mention them, your developer won't either — and you'll end up with a clean front end bolted onto the same broken chain of emails underneath.

The Shipment Exception Handling Workflow post covers the ops logic behind exception capture in more detail, and is worth reading before you write this section of your spec.

Be specific about volume and frequency

"We do a lot of shipments" tells a developer nothing useful. These numbers do:

• 40–60 export shipments per month across three trade lanes (UK to AU, UK to UAE, AU to SG)
• 3–4 document sets per shipment, averaging 6 line items per invoice
• Quotes generated: roughly 120 per month, conversion rate around 35%
• Peak periods: Q4 pre-Christmas and February (post-CNY)

Volume drives architecture decisions. Forty shipments a month probably means a fairly lean tool with smart templates. Four hundred shipments a month means you need to think about integrations, automated triggers and potentially a freight forwarder portal rather than just an internal tool.

Frequency of exceptions matters too. If 10% of your shipments hit a customs query, that's worth building a workflow around. If it's one a year, it's not — put the effort into the documents that prevent the query.

Name your compliance touchpoints by trade lane

"Compliance" in a brief is almost meaningless. "We need CITES permits for live plant exports to the EU, our freight forwarder handles the customs entry but we generate the export declaration reference, and our ATA Carnets are managed manually through the London Chamber" — that is useful.

For UK exporters specifically: HMRC's CHIEF-to-CDS transition, UK Global Tariff classifications, commodity-specific controls under the Export Control Joint Unit, and rules-of-origin requirements under the UK-AU FTA (in force since 2023) are all worth naming if they touch your process. For Australian exporters: the ABF's Integrated Cargo System, DAFF-controlled goods, and permit requirements for strategic goods exports deserve the same treatment.

You don't need to explain the regulations to your developer. You need to mark the points where your process must comply, because those are the fields that cannot be optional, the validations that cannot be skipped, and the document outputs that have to match a prescribed format.

Define what "done" looks like for each workflow

Scope creep kills trade ops builds faster than almost anything else, because every time someone in the team looks at a prototype they see something they want to add. The antidote is agreeing, in the spec, what "done" means for each workflow before a line of code is written.

A useful done definition for an invoice workflow might be: "A user can generate a compliant commercial invoice from an existing order record, review it on screen, download it as a PDF, and mark it as sent — without opening any other system." That's testable. "Better invoice management" is not.

Write a done definition for each of your core workflows — quoting, document generation, exception handling, partner communication — and you'll have something a developer can actually scope and price. You'll also find, in writing them, that some workflows you thought were core are actually edge cases that don't need software at all.

Decide upfront what integrates and what doesn't

Every integration doubles the complexity of a build and adds a dependency you'll maintain forever. Be deliberate.

The integrations worth considering for most UK and AU export ops tools:

• Your freight forwarder's booking system — usually via email or a PDF still, and that's fine if volume is low. At scale, an EDI or API connection pays for itself.
• Your ERP or inventory system — if product data, HS codes and country of origin already live somewhere, pulling from it beats re-entering.
• Your CRM or quoting tool — if a confirmed quote should auto-generate a commercial invoice, the link is obvious and the ROI is clear.

Integrations worth skipping in a first build: carrier tracking (fragmented APIs, unreliable data, high maintenance cost), banking or FX feeds (complex and rarely worth the build for ops purposes), and any system your team uses only occasionally.

What We Got Wrong Building an Export Quote Tool walks through exactly this kind of scope trade-off from the inside of a real build — worth reading before your kickoff meeting.

The human-in-the-loop question

AI-assisted document review is real and it works — but the spec needs to say explicitly where a human must stay in the loop. For most export operations, that means: any document that carries a legal declaration (certificate of origin, export licence application), any shipment to a controlled or sanctioned destination, and any document set where the consequences of an error are customs seizure or a financial penalty.

That's not a limitation of the software. It's a design decision. Build the tool to flag, to draft, to pre-fill — and then require a named sign-off. The system should make the human's job faster and the error harder to make, not remove the human from the chain.

One thing to do before you write the brief

Walk one end-to-end shipment with a notebook and time every step. Not the fast one — pick a complicated one, ideally one that had a problem. Count the number of times the same piece of data (a product description, an HS code, a unit price) is typed into a different field in a different system.

That number is your brief's north star. The software's job is to cut it. Everything else is detail.

If you want a sense of where your quoting process is haemorrhaging time before you even get to a spec, the Import/Export Quote-Time Estimator will give you a baseline to argue from when you're talking to a developer about scope.