No engineers. Mailbox connected. First declaration in 4 minutes

What everyone assumes

A customs broker's work arrives as email. That part is not disputed.

What everyone assumes next is the part that kills the conversation. To automate declarations you need developers, an integration project, and clients who will change how they send documents. Every vendor pitch ends at "and then your developers integrate with our API" — a sentence with no meaning at a brokerage that has no engineering team. Not a small one. Not an outsourced one. None. That is normal for the trade.

So the default answer becomes hire. Same skill on the phone, same hours at the desk: who clears more? The person who types faster. Equal skill: the one with better templates. Equal templates: the one who already knows which sender belongs to which client. Keep changing the variable and the conclusion is the same — throughput is bounded by how fast people open mail, attribute it, and retype it. Growth is a hiring problem. Margin per declaration stays flat.

The brokerage did not need "automate declarations" as a slogan. It needed something narrower and harder: turn the mailbox we already have into an API we do not have to build.

The variable that actually moved

The variable was not a new portal, a new inbox, or a client onboarding queue. It was where the pipeline started.

XB ClearanceFlow connected to the brokerage's existing Microsoft 365 mailbox. No forwarding rules to maintain. No new inbox for staff to learn. No change to how shippers send manifests, invoices, packing lists, corrections, or chasers.

From there it reads each inbound message, extracts the declaration data, and — the part that actually matters — works out which client it belongs to. Attribution is the unglamorous centre of brokerage automation: a document is worthless until it is filed against the right customer. ClearanceFlow resolves it from signals in the message itself, and learned 19 sender rules over the first fortnight as traffic arrived.

Hold skill, hours, and formats constant. Change only the start of the pipeline — mailbox in, structured declaration out — and the desk stops scaling with volume. Where attribution rests on a single piece of evidence, the declaration goes to a review queue. The broker sees what the system inferred and why, and confirms or corrects in one click. Nothing is filed on a silent guess.

Historical declarations were loaded the same way, in bulk. Same mailbox pattern. Same attribution problem. One afternoon instead of a migration project.

What they can sell now

The brokerage was live the morning after signup. The first structured declaration landed four minutes after the mailbox was connected — no integration project, no developer, no change to how documents arrive.

There was no per-client onboarding queue. All 27 client companies were live on day one, 25 of them going on to receive declarations, the whole operation from a single user account. The connection has run continuously since it was switched on.

The back-catalogue was its own afternoon: 500+ historical declarations, filing dates reaching back months, loaded in around two hours. Steady-state, the pipeline handles around 11 declarations a day, every one automatically attributed to a client.

The outcomes the brokerage points to are not ones our database can see. Capacity: the same operations team now reckons it can carry roughly three times the customer volume, because the work that scaled with headcount — opening mail, identifying the client, retyping contents — no longer does.

Visibility: a broker's clients traditionally have no idea where a declaration is until someone answers the phone. Every document now lands as a structured record on arrival, so the brokerage can show clients clearance state directly. That was the gap customers had complained about. Closing it mattered more to them than the speed did.

What they can sell now is not a faster typist. It is more clients on the same desk, and a status their customers can see without calling.