A spreadsheet never announces that it has stopped working. There is no error, no crash, no day on which it fails. What happens instead is that a person quietly becomes the system. One planner knows which tab is current, which customer's rate is out of date and which row you must not sort. When that person is on leave the operation runs at half speed, and nobody can say exactly why.
That is the real signal, and it arrives long before anyone counts how many rows the file has. This is what a transport system is actually made of, what a Thai operation measured when it put one in, and the tests that tell you whether yours has already failed.
Four products, one word
"Transport system" is sold as one thing. It is four, and they are bought separately in most operations.
- The record of the job. One row per consignment: who ordered it, what it was, which vehicle took it, when it arrived, what it was charged. This is the spine. Everything else reads it.
- The plan. Which drops go on which vehicle in which order. Routing and scheduling.
- The position. Where the vehicle is now, and where it was. Tracking and telematics, which is a separate class of product from the planner and usually a separate supplier.
- The money. Turning the record into an invoice, a driver's pay and a cost per job.
Most operations that say "we need a system" want the first and the third. They want to stop re-typing the same consignment into three places, and they want to stop answering the phone with "let me call the driver". The usual mistake is to go shopping for the second, because routing software is the one with the impressive demonstration.
What the software actually touched
A Thai study charted this properly. The company runs five collection points in Bangkok and its surrounds, line hauls into retail distribution centres in Chanthaburi and Nakhon Sawan, and delivers locally from there. The researchers timed the same forty-step cycle before and after a cloud transport management system went in, in seconds, step by step.
These are the steps that changed:
| Step | Before | After |
|---|---|---|
| Calculate the freight charge, tell the customer the amount | 40 s | 10 s |
| Summarise the delivery orders by zone | 1,500 s | 60 s |
| Issue the truck manifest and summarise expenses by zone | 1,500 s | 30 s |
| Sort delivery orders by district at the receiving end | 1,800 s | 10 s |
| Assign routes | 1,800 s | 10 s |
| Calculate expenses, collect payment on delivery | 120 s | 5 s |
| Issue a per-route expense voucher | 600 s | 180 s |
| Despatch the vehicles | 300 s | 180 s |
| Driver submits documents, reports returned goods | 3,600 s | 600 s |
| Summarise the day's deliveries and returns | 600 s | 60 s |
Now look at what did not change. The line haul is 54,000 seconds in both columns. The local delivery running is 14,400 seconds in both columns. Unloading from the sender's vehicle, counting the goods, sorting them by zone, loading, verifying against the paperwork, handing over, collecting cash at the door: every one of those is the same number before and after.
Fifteen hours of line haul and four hours of delivery running, 68,400 seconds out of a charted cycle of 111,218, is 61.5% of the job, and the software did not touch a second of it.
That is not a criticism of the system. It is what a transport system is. It is a filing and calculating machine. It removes re-typing, re-summarising and searching. It does not make a truck faster, and every claim that it will should be read as a claim that it will let you change the way you run the trucks, which is a different and much harder thing.
The step that got worse
One step went the wrong way. Issuing a single delivery order rose from 70 seconds to 120 seconds. The authors put it down to staff being new to the system.
Fifty seconds does not sound like much. The sample period covered 150 delivery orders, so it is 7,500 seconds.
Add up every step that improved and the gross saving is 10,715 seconds, just under three hours. Subtract the 7,500 seconds handed back at the counter and the net is 3,215 seconds: 53 minutes and 35 seconds. The one step that got slower ate 70% of the gain.
Two things follow, and they are the most useful part of the whole study.
A system moves work upstream. Summarising by zone collapsed from 1,500 seconds to 60 because somebody typed the consignment properly at the point of capture. The person at the counter pays for everyone else's saving. If you do not plan for that, the counter becomes the bottleneck and the staff there become the ones who hate the system.
Measure the whole cycle or you will believe the wrong number. Anyone who had timed only the steps they set out to fix would have reported a three-hour saving. The real figure was 53 minutes.
So what is 53 minutes worth?
Nothing, until something changes shape.
Fifty-three minutes a day of back-office time is real, but it is not money in the way a vehicle-day is money. It becomes money if a shift disappears, if a person who was doing summaries starts chasing the routes that lose money, or if it lets you take on more volume without another admin hire. If none of those happen, the cost has moved from one line to another and the total is the same. The same test that applies to any transport saving applies here: it is only real if a vehicle-day, a shift or a site actually disappears. That is worked through in what transport really costs you per unit.
Which is why the second Thai case is worth putting next to the first. A private transport company at Suvarnabhumi was running its vehicles back to base empty. Its monthly transport cost fell from 51,200 baht to 47,020, a saving of 4,180 baht a month, or 8.16%.
Read the Thai text and the attribution is precise: the saving came from adopting a milk run route pattern, which shortened total distance. The transport management system is what planned the routes, tracked the vehicles and held the new pattern in place. The software did not earn the 8.16%. The change in the way the trucks ran earned it, and the software made the change possible to plan and possible to keep.
That gives you the question to ask before signing anything. What will we do differently once we have this? If the answer is only "the same work, with less typing", you are buying a filing cabinet, and you should price it like one.
Five tests that say the spreadsheet has gone
Not a number of rows. Not a number of trucks. All five of these are observable this week.
- Two people need the file at the same time. The moment planning and invoicing both need to be in it, you are either taking turns or keeping two copies that disagree.
- The plan changes after it is published and there is no safe way to change it. An urgent order arrives at 15:00. Somebody edits the sheet, prints a new copy, and one driver leaves with yesterday's.
- A question about last month needs the month rebuilt. If "what did we charge this customer on this lane in March" means opening four files, the history exists but is not readable.
- One person is the only one who can run the day. Covered above, and it is the most expensive of the five because it never appears in any budget.
- The same fact is keyed in three places. Once into the order sheet, once onto the delivery document, once into the accounts. Each re-keying is a chance for the three to disagree, and they will.
Test three has been measured. In another Thai case, a transportation company that planned from staff experience rather than from records timed itself before and after building a proper database. The average time to look a piece of information up fell from 1.05 minutes per job to 0.13, and the average time to work out what a job cost fell from 2.10 minutes to 0.30. Roughly: under ten seconds to find a fact means you have a system, and a couple of minutes means you have a person searching.
Why routing software is rarely the thing to buy first
It has the best demonstration and it is the hardest to make pay. Three reasons.
It does not give you the right answer. Most routing packages do not produce an optimum. They produce the best plan they can find inside the constraints and the demand you gave them. Feed them a delivery point whose real gate closes at 15:30 and they will confidently schedule 16:00.
It has to be fed every day. Buying the package is the small cost. Supplying accurate demand data every single morning is the large one, in staff time and in discipline. Used for planning, on last quarter's data, a routing package is cheap and very useful. Used interactively every day, it is a permanent job.
Stop count is not what breaks manual planning. It looks like it should be. One vehicle with five drops has 120 possible sequences, which a planner can hold. Ten drops has 3,628,800, and twelve has 479,001,600. But a planner does not enumerate sequences; they look at a map and use geography, and they get within a few per cent of the machine on a simple round. What a person genuinely cannot do is hold a delivery window, a gate height, a site with no forklift, a maximum drop size, an axle weight limit and a driving-hours ceiling against each other, for every candidate, at the same time. Some constraints cannot be used in manual planning at all, which is why manual plans quietly drop them.
So the honest test for routing software is not how many drops you have. It is whether the shape of the work genuinely changes from day to day, and whether it carries hard constraints that must all hold at once. If your delivery points are the same every week, a fixed route built once and reviewed quarterly beats a daily optimiser that needs feeding. Which regime you are in is decided by how stable your locations are, and that is worked through in fixed routes or plan-every-day.
The order to buy in
- The record of the job. One consignment, one row, one place, entered once. This can be a shared database before it is ever a product. Everything else reads it, and nothing else works without it.
- The costing that reads that record. As soon as the record is trustworthy, cost per job, per customer and per lane come almost free.
- Position, if your customers telephone. Buy this when the phone calls are the pain, not because tracking is modern.
- Routing, last, and only if the work is genuinely variable and constrained.
And before any of the four: the delivery point record. Gate heights, receiving windows, access, the coordinate captured at the gate. A planning system is a calculator, and a calculator fed the wrong address returns a confident wrong answer with times on it. That record is built from data you already hold, and how to do it is in master data before software.
What it will not fix
It will not fix an order pattern. If half your work arrives after the cut-off, a system will schedule the chaos more neatly and cost the same.
It will not survive bad master data, and it will not tell you the data is bad. It will produce a plan.
And it will not remove the paperwork the law requires. The Thai study found steps it could not delete for exactly that reason. A system can produce a required document faster; it cannot decide that the document is unnecessary.
One last detail from that study is worth carrying away. Asked which measures to keep, the small operation settled on fourteen: seven on reliability, six on speed of response, one on collecting money from customers. Not one on cost per kilometre. When an operating team is asked what it actually needs to watch, it asks for service and cash. That is a fair description of what a first system should be built to answer, and a good check on any supplier whose demonstration opens with a cost dashboard.