You have a system. Orders get entered, trucks roll, invoices go out. And half the day still goes on the things that system doesn't cover. One client billed off their own rate card. A delivery slot booked over the phone. Data retyped from one window into another. Here's what a TMS actually covers, what it doesn't, and what to do when your process has outgrown it.
“A boxed system runs the process you were supposed to have. Your business makes its money on the thing that sets it apart.”
A TMS, or transport management system, is software for running transport. It takes an order, plans it into a route, assigns a driver or a carrier, keeps the shipping documents together, and settles the cost at the end. In a good TMS you can see where the freight is, what the trip cost, and whether the job has been invoiced.
So much for the definition. In practice, companies mix up three systems, because all three touch the same order:
None of them replaces the other two. That's where the trouble starts. When somebody goes looking for logistics software, they rarely want one box. They want the three worlds to stop drifting apart.
The pain in a logistics business is seldom inside one system. Almost always it sits on the seam between them: between the TMS and the warehouse, between the warehouse and the ERP, between your systems and the ones your carrier and your customer run.
A TMS plans and settles transport: orders, carriers, routes, documents, and the cost of each trip.
It won't replace a WMS or an ERP. Most of the pain sits not inside one system but where the three of them meet.
A boxed product works as long as your process looks like everyone else's. It stops working once you make your money on exceptions: unusual billing, delivery slots, one large customer's requirements.
You rarely need to replace everything. Usually it takes a layer built for your process and a few integrations, added without stopping operations.
There are two places where a box ends. Both look harmless until you price them.
The first is exceptions. One large customer wants to be billed off their own rate card. Another needs delivery booked into their time slot. A third accepts documents only in its own format. Any one of those can be handled by hand. Together they add up to a full-time job. And one person in the company is the only one who knows how they work.
The second is seams. An order has to move from the TMS to the warehouse, stock from the warehouse to the ERP, the invoice into accounting, the shipment status out to the customer, the consignment number over to the carrier. If a human does any of those steps, you pay for it twice: once in time, once in the errors that surface a week later.
You can spot it from one symptom: a spreadsheet living next to the system. That isn't the team being lazy or badly trained. It's the invoice for a feature the box doesn't have and your process needs.
There's a second symptom, quieter and worse. You ask why something is done a particular way and hear "because the system won't let us do it otherwise". At that point the software has stopped serving your process, and your process is serving the software.
Rulewave is a global logistics operator. We built their warehouse management system in 2019 and still maintain it, and we've worked with the company without a break since 2010. The interesting part isn't inside the system, it's at the edges: real-time SAP, warehouse scanners, delivery bookings, DHL, pickup route optimization, and invoicing in both the Netherlands and the United States. Those are the seams. Stitched once and watched for years, they stop costing money. If you're weighing up a nearshore partner, one detail matters more than the rest: the engineers who built that system are the ones still answering for it.
The most expensive plan in logistics is "we replace it all at once". Operations have no window to stop. And a project touching transport, the warehouse and accounting at the same time grows faster than a company can absorb it. We almost never propose it.
This is how we usually work:
What not to do: don't buy a second box for the same problem, because it usually adds a third seam instead of removing the first. Don't open the conversation with technology, because the choice of database isn't a business decision. And don't price this kind of project by the hour; price it by the cost of risk and downtime. We take that last point apart in the piece on what custom software costs. If your pain sits on the warehouse side, start with custom WMS versus off-the-shelf.
What your operation gets out of it: less manual work on the seams, less knowledge locked in one person's head, and a predictability no spreadsheet next to the system will ever give you. You can see how that plays out with our clients in our case studies.
Transport management system. It handles transport orders, route planning, work with carriers, shipping documents, and settling each trip.
An order enters the system once and moves through every stage inside it: planning, execution, documents, settlement. At each stage you can see where the freight is and what it costs. The value shows up where the next step happens on its own. If somebody retypes data between the stages, the TMS is only covering part of the work.
Roughly three. Boxed products on a subscription: quick to roll out, but you take on the vendor's process. Transport modules inside a larger ERP, which make sense when the rest of the company already runs on that ERP. And systems built around a specific process, which companies reach for when they make their money on something the box doesn't handle. The choice isn't a feature ranking. It's an answer to one question: should your process fit the software, or the other way around?
A boxed product is usually billed per user or per vehicle. Entry is cheap and the cost grows with the company. A system built for your process is a one-off build plus maintenance. The more useful question is a different one: what does today's manual work on the seams cost you, and what does the downtime cost when something drifts out of sync. We break that down in what custom software costs.
SAP is an ERP first, though it does have a transport module. In companies already running on it, that module sometimes serves as the TMS. More often we see a different arrangement: SAP stays the system of record, while transport and the warehouse run on separate systems connected to it. That's how it works at Rulewave. SAP answers in real time, and warehouse operations run in a system built for that process.
Transport, the warehouse, an ERP or carrier integration. Let's walk your process together before anyone mentions technology.
Let's talk about your processA single integration, a customer portal, or the module your current system is missing. We'll price the scope quickly and precisely.
Scope your project
