For logistics and supply-chain operators we automate the operational back-and-forth: quote requests, track-and-trace replies, and the document sets that move between carriers, customers and systems. On our logistics project a booking took seven minutes of work instead of forty, and the share of document sets containing an error fell from 12% to 2%.
Staff chase status updates across carrier portals and emails and copy them to customers by hand.
Rate requests and tenders are answered manually, slowly, and inconsistently.
BOLs, customs forms, and PODs move as email attachments and get rekeyed at every step.
Reps spend selling time building prospect lists instead of talking to shippers.
A pipeline that sources, enriches and qualifies shipper prospects, then syncs them to your CRM.
Pull status from carrier systems and push proactive updates to customers automatically.
Extract data from shipping documents and route it to your TMS with exceptions flagged.
Connect TMS, carriers, and customer portals into one monitored flow with retries and alerts.
document sets with errors
Client under NDA. The figures are the client’s own, comparing the periods before and after launch.
This is the project behind the case above, described the way it happened. A freight forwarder of 50–70 people working with dozens of carriers. Bookings came in by email, by messenger and by phone, and a dispatcher retyped each one into a spreadsheet and then into document templates. Forty minutes per shipment, and roughly every eighth document set had to be redone — usually discovered at the printer or, worse, by the driver.
Email, messengers, the portal and the phone land in one queue in a single format. Phone booking was not abolished: the call is transcribed and lands in the same queue.
Carriers, rates and documents live in one place, so a rate stops existing only inside somebody’s correspondence.
The whole set is generated from the booking, using each party’s own details. Sets with errors went from around 12% to around 2%.
Statuses come from the carriers and are visible to the customer in a portal. The dispatcher stopped being a relay between the customer and the driver.
The rate is fixed on the booking, the invoice is built from it, and reconciliation with a carrier runs shipment by shipment rather than from memory and a chat history.
Margin is visible per shipment, and failures are broken down by cause — carrier, customer, documents — instead of collapsing into one “it did not work out”.
Three months. The forty minutes a dispatcher spent on a booking became seven, and document sets with errors went from 12% to 2%. Most of the time went into the document templates themselves: every direction and every customer has its own. What deliberately stayed with people: choosing the carrier, negotiating the rate, anything that goes wrong in transit, and vetting a new carrier.
One to two weeks. Fixed, and credited in full against the build.
A fixed quote against the scope the audit produced.
On this project. Two to four months is the range across our cases.
Model and infrastructure usage plus maintenance. Moves with volume.
Declarations and commodity codes are validated against the tariff and escalated to a broker when uncertain. A wrong code is a fine, not a retry.
Any flow touching hazardous classifications or sanctions screening stops and escalates by rule, never on a confidence score.
Automation around scheduling treats the legal limits of the market it runs in as hard constraints, not as preferences to optimise.
Much of this sector runs on EDI and on partner systems no one will modify for you. The integration layer is built for that instead of assuming a modern API.
Watching the tracking feeds and telling a person about the shipment that is about to be late, before the customer does.
Bills of lading, packing lists, CMRs and invoices read and matched — which is where the manual hours in freight actually go.
Assembling a rate response from your tariff and past pricing, ready for a person to check and send.
Route optimisation is a solved category with good products in it. We would integrate one rather than build one.
If partners send scanned paper and will not change, expect an accuracy ceiling and plan the exception desk around it.
Anything that would sign a customs declaration on your behalf stays with your broker.
Each page states the workflow, the systems it integrates with, what it costs and when it is the wrong choice.
Reads incoming invoices, checks totals, tax and supplier against the ERP, and posts only what clears the rules.
Sorts mixed incoming documents by type and routes each one to the queue, folder or system that owns it.
Watches tender portals for matching notices, extracts the requirements and flags the ones worth bidding on.
Yes — over APIs, EDI, webhooks, or portals. Where a carrier has no API, we automate the portal or document flow and monitor it the same way.
We don’t propose an off-the-shelf product either. The audit is there precisely to see where your process differs from the ordinary one, and the build is shaped around that difference. And if it turns out a standard tool covers you well enough, we’ll say so plainly — the process map stays with you in any case.
It’s a fair thing to ask, and responsibility matters more here than accuracy. A person answers for it, and the system is built so that they can: a doubtful case is never posted quietly, it goes to a review queue. Low confidence isn’t an error for us, it’s a route. Around 70% clears straight through and a person looks at the rest — and where exactly that line sits is yours to decide.
That’s a common requirement, and a reasonable one. We fit the setup to your data rules: if nothing may leave, the model runs locally inside your own perimeter, and the documents never cross it.
That’s not unusual, and it’s fine. Integrating without an API is the most underestimated line in a quote, which is why integration surface comes first among the four cost drivers, and why we don’t name a fixed price before the audit. Working without an API is perfectly possible — files, exports, email — it simply costs more, and it’s better to know that early. Which is why, fairly often, we build the API for you.
It happens often, and usually for one reason: the pilot was measured on the happy path and the exceptions were left for later — though the exceptions are where most of the work turns out to be. So we look at the share that clears without a person rather than at extraction accuracy, and we agree in advance who handles the rest, and how.
No, that isn’t what this is about. What goes is the retyping, not the people: decisions stay with a person — the disputed document, the non-standard transaction, the conversation with the client, the signature under the reporting. On one accounting project, closing a client month went from three days to four hours, not because anyone was let go, but because a qualified specialist stopped keying in details by hand. The time that frees up most often goes into growth: more clients with the same team, without the costs rising alongside.
It’s a fair question, and sometimes doing it yourselves really is the right answer. We say so when the volume doesn’t justify a build: below roughly 300 documents a month the arithmetic usually doesn’t work. The calculator on this site includes running costs, so you can weigh that up before you ever talk to us.
They do change, and that’s exactly what we build for: the model is a replaceable part here, not the foundation. The source of truth is our own database — the document, the counterparty, the entry. The model is attached to the side, and we update it whenever something better appears; for you that’s planned maintenance, not a rebuild.
We use cookies for analytics — to see which pages bring enquiries. Nothing else, and nothing before you agree. Cookie Policy