At some point a good customer says the sentence: ‘Can you take orders by EDI?’ For a haulier without an IT department, the question sounds like a six-figure project. It usually is not - but the fleets that treat it as one, and the fleets that treat it as nothing, both get it wrong. The reality is a specific, learnable piece of plumbing with a business case attached.
Strip the jargon and EDI is this: the customer’s system sends orders as structured messages that your system reads automatically - no re-keying, no emailed spreadsheet, no fax-shaped PDF. The message types in road haulage are a small, stable set: the order or despatch instruction coming in; the confirmation, status update and POD going back; the invoice at the end. Different industries dress them in different standards and naming - the retail world’s formats differ from the automotive world’s - but the shape is always the same: fields, codes, and an agreed meaning for each.
The customer’s real ask is never the technology. It is the elimination of re-keying errors, the speed of confirmations, and the status visibility they get when your system talks to theirs. Understanding that turns the project from ‘install EDI’ into ‘give this customer accurate, timely data automatically’ - a solvable problem.
There are three honest routes in, in ascending order of commitment. The portal-conversion path: many EDI providers run ‘web EDI’ services where the customer’s EDI orders arrive on a web portal for you to work by hand, and your portal entries convert back into EDI messages for them - no integration at your end at all, just a browser. This is how most small fleets first ‘do EDI’, and it is a legitimate answer when volumes are modest. The TMS-connector path: most transport management systems have existing connectors to the common EDI networks and the big retail and manufacturing formats - the project becomes configuration rather than development, and this is the right shape once the volume justifies killing the double-handling. And the direct path: a bespoke integration between the customer’s system and yours, which only pays at genuinely high volume or genuinely unusual requirements.
The selection logic is volume times repetitiveness: high volume of identical message shapes justifies integration; low or varied volume says portal.
The first EDI link sets the pattern, so run it deliberately. Get the customer’s specification: which messages, which standard, which codes for products, locations and status - the ‘implementation guide’ they hand over is the contract of the project. Test before go-live: the test phase with sample orders, including the ugly ones - the short shipment, the cancelled order, the amended address - because production’s first ugly order is not the time to learn the mapping. Keep the fallback: the manual process stays warm through the first weeks, because EDI links fail quietly and the undelivered order is the failure that costs the relationship. And assign an owner: one person in the office who understands the link end-to-end, because ‘the computer handles it’ is not an answer when a message queue stops.
EDI is structured messages replacing re-keying - orders in, confirmations and PODs back, invoices out. Start with the customer’s spec, pick the entry path that matches your volume (portal, TMS connector or direct), test the ugly cases, and name an owner. The customer’s real requirement is accurate, timely data; EDI is just the plumbing that delivers it.
The first EDI customer usually starts a cascade, because the second customer’s project is a tenth the work of the first - the messages map to the same internal processes, the TMS connector already exists, and the office has stopped fearing the acronym. Fleets two or three links in discover the strategic shape: EDI customers are stickier, because integration is a switching cost; the order-to-invoice cycle shortens because nothing waits for re-keying; and the data that flows - volumes, lanes, timing patterns - becomes planning intelligence the manual customers never provide. The fleets that never start stay on the email-and-spreadsheet treadmill with the customers who churn fastest. The technology is unglamorous; the compounding is not.
EDI projects are sold as systems work and delivered as office change. The clerk whose morning was re-keying orders now manages exceptions - the failed message, the odd quantity, the price mismatch - which is a different skill and, honestly, a better job, but it needs the transition handled openly: what changes, what stays, who answers when the link misbehaves. The fleets that brief the office through the first link find the second one championed from inside; the fleets that announce ‘the computer will do that now’ spend the project fighting the quiet sabotage of people protecting a process they built their competence on. Automation lands where people were told first.
One customer, one message set, one owner, tested on the ugly cases before go-live, with the manual fallback kept warm. That is the whole method. The fleets that follow it join the supply chains that pay for integration; the fleets that wait for a perfect moment keep re-keying orders while the work walks to the integrated competitor.
What does the first link cost? Portal-style web EDI runs at modest monthly fees; TMS connectors sit inside or alongside the TMS subscription; direct integration is a development project with a developer’s invoice. Against that: the re-keying hours removed, the keying errors eliminated, the faster invoice cycle, and the retention value of being the integrated carrier the customer’s system prefers. For most fleets the honest answer is that the first link pays back inside a year on labour alone - the strategic gains arrive free.