The short version
Start with documentation, because it is high volume, rule-governed and the errors are expensive. Expect the integration to be the largest line in any quote. And do not automate the customer conversation before you can answer the question it is actually asking, which is usually “will it arrive when you said?” rather than “where is it now?”.
Where does the time actually go?
Not on moving freight. On the paperwork around it and the exceptions that break the plan:
- Documentation. Bills of lading, commercial invoices, packing lists, certificates of origin, customs paperwork — arriving as PDFs, scans, photographs and occasionally faxes, in every layout imaginable.
- Data re-entry. The same shipment details typed into three systems because none of them talk to each other.
- Exception handling. A delay, a short delivery, a damaged pallet, a customs hold — each becoming a chain of calls and emails.
- Status chasing. Customers asking where things are, and staff checking a portal to answer.
These are unglamorous, high volume, and largely rule-governed, which is exactly the profile that responds well. The strategic work — pricing, carrier relationships, network design — is not where the hours are.
Why is documentation the best place to start?
Because the volume is large, the fields are consistent even when the layouts are not, and the cost of errors is unusually concrete: a wrong commodity code or a mis-keyed weight produces a customs delay with a price attached, and demurrage accrues daily.
It is also the area where the previous attempt most likely failed. Template-based extraction works for the handful of shippers who send consistent paperwork and collapses on everyone else — which in freight is nearly everyone, because you do not control what your counterparties send you.
What about the TMS with no API?
This is the constraint that determines the project, and it should be established before anything else is discussed. Many transport management systems in daily use are a decade or more old, offer a nightly CSV export at best, and are modified only by a vendor who charges for the privilege.
Options exist and they vary enormously in cost: a database read replica if the vendor permits it, scheduled file exchange, screen-level automation as a last resort, or routing around the system entirely by capturing data before it goes in. Which one applies is not something anyone can quote without looking, and a proposal that does not mention it has not thought about the project.
Prove this early. It is the single most common reason a logistics project stalls after the pilot.
Can it handle customer status enquiries?
Partly, and the distinction matters. A system connected to tracking data can answer “where is it” reliably and immediately, which is a real saving because that question is asked constantly and answering it produces no value.
What it cannot do is answer the question underneath, which is usually “will it arrive when you promised, and if not what are you doing about it”. That requires a judgement about a delay nobody has assessed yet. Automating the first without a good escalation to a human for the second produces a customer who is now angry and feels fobbed off, which is worse than a slow reply.
What about exception handling?
The realistic version is assembly rather than resolution. When a shipment goes wrong, the cost is in gathering context — the booking, the carrier updates, the correspondence, the customer’s SLA, what happened last time with this lane — before anyone can decide anything.
A system that presents an exception with all of that already assembled and a suggested action turns a twenty-minute investigation into a two-minute decision. The decision stays with a person, which is right: the trade-offs involve commercial relationships that are not in any database.
Does this work for a small freight forwarder?
Often better than for a large one, because the processes are less entrenched and a single person can make a decision. A twenty-person forwarder where three people spend most of their week on documentation has a clear, measurable problem and a short chain of approval.
The constraint is budget and the answer is scope. One document type, one lane, one customer — measured properly — is affordable and it produces the number that justifies the next step. The mistake is scoping a transformation programme when what is needed is one process fixed.
What should we measure?
Time per shipment file, error rate on customs submissions, and the proportion of documents needing human touch. Those three are concrete and they map directly onto cost.
Demurrage and detention charges are worth tracking separately, because they are the clearest financial expression of documentation failures and they are usually already recorded. A reduction there is the easiest business case to make to anyone sceptical.
What are the industry-specific risks?
Customs declarations carry legal consequences and the declarant remains responsible for accuracy regardless of what prepared them. That argues for a human check on anything submitted to an authority, and for keeping an audit trail showing what was extracted, what was corrected, and who approved it.
Dangerous goods documentation deserves particular caution — the classification rules are intricate and the consequences of an error are not commercial. That is a category to leave with qualified people, and to use the system only to assemble information for them.
Where should a forwarder start?
Take one month of documents you have already processed, including the shippers whose paperwork everyone complains about. Extract them, compare against what was actually keyed, and produce three numbers: accuracy overall, accuracy on the worst shipper, and the proportion that would have been flagged for review.
Then, before committing to anything, get someone to prove they can read from and write to your TMS. Those two exercises cost a few days between them and they answer the only two questions that determine whether the project is viable.
What about carrier and rate communications?
Rate sheets, surcharge notices and schedule changes arrive constantly, in inconsistent formats, from every carrier, and someone has to read them and act. Extracting them into a structured record is the same problem as shipping documentation and responds the same way.
The value is slightly different, though: it is less about time saved and more about not missing things. A surcharge notice read three weeks late has already cost margin on every shipment in between, and that loss never appears on anyone’s report as a process failure.
How does this affect the customer relationship?
Freight is a service business where the relationship is often the differentiator, and the risk of automating communication is that you remove the contact and keep the cost. Customers who called you because you answer the phone will notice if the phone starts answering itself.
The version that works uses the saved time to make the human contact better rather than rarer — proactive calls about a delay you spotted early, rather than reactive answers to a status question. That is a genuine upgrade to the service, and it is only affordable once the routine chasing has gone.