At seven in the morning the plan is right. Every stop has a time, every truck has a driver, and the numbers add up.
By nine it is wrong. A road is closed, a customer's gate is backed up, a pallet was loaded in the wrong order. None of that is unusual. What decides how the day ends is not whether something goes wrong but when somebody notices, and whether there is still a cheap way to fix it at that moment.
Most transport operations find out at the worst possible time: when the customer rings at three in the afternoon to ask where the truck is. By then the only thing left to do is apologise. This article is about the loop that catches the problem at half past nine instead, while every option is still open.
The day is a loop, not a plan
A plan is a guess made before anything has happened. Running the day means comparing that guess with what is actually happening, often enough to act, and deciding in advance what counts as worth acting on.
The loop has five steps:
| Step | The question it answers | When |
|---|---|---|
| Release | Is this vehicle, driver and load fit to leave as planned? | Before the gate |
| Watch | Is anything drifting away from the plan? | All day |
| Decide | Does the drift threaten a stop later in the route, and what are the options? | The moment it does |
| Act | Who does what, and who tells the customer? | Before the cheapest option expires |
| Close | What actually happened, and what should tomorrow's plan learn from it? | End of the day |
Most operations do the first and part of the second. The third and fifth are where the money is.
In Thailand, part of the loop is already a legal duty
The Department of Land Transport requires bus and truck operators to appoint a transport safety manager, and in 2024 it spelled out what that person is expected to do every day. Seven duties, in the Department's order:
- Confirm the vehicle safety check, by reviewing the driver's daily inspection form before the vehicle is released
- Confirm the driver's alcohol test, before and after work
- Confirm the driver is fit to drive, by asking and watching for tiredness, drowsiness and illness
- Brief the driver on the route's risk points from road and weather conditions, set the rest, stopping and safety check points, and follow the status of the job throughout the journey
- Go through the work plan with the driver again, so there is no misunderstanding
- Confirm the load: the load list, how the goods are arranged, and how they are secured
- Follow and check the transport situation throughout the journey
Read that list as an operating manager rather than a compliance officer and it is most of the loop above. Items 1, 2, 3, 5 and 6 are the release step. Items 4 and 7 are the watch step, twice.
The Department wrote those duties for safety, not for delivery performance. But the same person, looking at the same screen, checking the same driver, is the natural owner of both. An operation that treats the safety duty as a form to file and the delivery control as a separate job is paying for the same watching twice and getting less out of each.
If you buy transport rather than run it, this is also a question worth asking a carrier: who is your transport safety manager for my lanes, and what does "following the journey" look like on an ordinary Tuesday?
Watch the slack, not the dot
A map full of moving dots feels like control. It is not, because a dot does not tell you whether anything is wrong.
What tells you is slack: for each stop still to come, the time between when the truck is now expected to arrive and the latest arrival the stop will accept. A truck forty minutes behind plan is fine if every remaining stop has an hour of slack. A truck ten minutes behind plan is a failure if a stop later in the day had only five.
Two practical points about the feed most Thai operations already have.
It arrives in steps. The Department's specification for journey data recorders requires position and speed to be sent in real time or at least once every five minutes, with speed recorded every minute. At 60 km/h a truck covers 5 km between five-minute updates. A dot that has not moved for two updates means ten minutes stopped, which could be a closure or could be a coffee.
A gap is not a loss. The same specification requires the device to store at least 24 hours of data when it cannot reach the network. A truck in a dead zone has not disappeared. Its record arrives late.
The recorder tells you where the truck is, how fast it moved and how long the driver has been driving. It does not tell you that a drop is finished, that a customer refused a pallet, or why a stop took an hour. The loop needs a second, simpler stream from the driver: arrived, unloaded, left, and a reason when any of those is late.
A worked day: the delay on leg two lands at drop four
One six-wheeler, one driver, four drops, back to the depot. This is the plan at seven in the morning:
| Stop | Drive | Arrive | Latest arrival accepted | Slack | Unload | Leave |
|---|---|---|---|---|---|---|
| Depot | 07:00 | |||||
| A | 60 min | 08:00 | 10:00 | 120 min | 40 min | 08:40 |
| B | 45 min | 09:25 | 12:00 | 155 min | 30 min | 09:55 |
| C | 50 min | 10:45 | 13:00 | 135 min | 35 min | 11:20 |
| Rest | 30 min | 11:50 | ||||
| D | 100 min | 13:30 | 14:00 | 30 min | 40 min | 14:10 |
| Depot | 90 min | 15:40 |
Look at the slack column before anything goes wrong. Three stops have two hours or more. D has thirty minutes. That one number is the most important fact about this route, and it is not where the truck will be when the trouble starts.
At 09:10, halfway between A and B, the road ahead is closed. The truck sits for 70 minutes. Nothing else changes, so every later time moves by 70 minutes:
| Stop | Arrive now | Latest arrival accepted | Slack now |
|---|---|---|---|
| B | 10:35 | 12:00 | 85 min |
| C | 11:55 | 13:00 | 65 min |
| D | 14:40 | 14:00 | 40 min late |
B and C are still comfortable. D fails, by exactly the delay minus D's slack: 70 minus 30.
Here is the whole problem in one line. The delay happens on leg two at 09:10. The failure happens at D at 14:40. Anyone watching the truck sees a truck that will still reach B and C well inside their windows, and relaxes. Anyone watching the slack sees that D is gone the moment the truck has been stopped for more than half an hour.
This gives every route a rule for when to raise the alarm: a delay on any leg becomes an exception as soon as it exceeds the smallest slack left anywhere downstream, not the slack at the next stop.
Every fix has a deadline
At about half past nine, with the truck stopped for twenty minutes and the closure reported, the controller can already project the failure at D. There are options, and each one stops working at a different time:
| Option | Result | Stops working |
|---|---|---|
| Do nothing | D refuses or holds the truck, 40 minutes late | |
| Ask D to receive until 15:00 | All four drops delivered, if D agrees | When D can no longer re-roster its receiving team, which only D can tell you |
| Skip C today: rest at B, then drive B to D in 120 minutes | D arrives 13:35, inside its window. C moves to another day | When the truck leaves B for C, at 11:05 |
| Keep the route and have another vehicle take D's goods | Needs a second vehicle, a driver and a transfer point | Earliest of all, because the goods are on this truck |
The skip-C option only exists until 11:05. The failure it prevents lands at 14:40. The cheap decision expires three hours and thirty-five minutes before anyone at D would notice anything. That gap is what a control loop buys, and it is why a controller who waits for the customer to call has no options left.
Which option is right is a commercial question, not a transport one: is C or D the customer who matters more today, and will D bend its receiving time? The controller cannot answer that alone at 09:30. Someone has to have answered it before the day started.
The legal check every re-plan has to pass
A re-plan that saves D by breaking the law on driving time is not a re-plan. Section 103 bis of the Land Transport Act, read in Thai, says that within a twenty-four hour round a licensed driver may not drive continuously for more than four hours from the moment driving starts, and may drive a further period of not more than four consecutive hours only after an unbroken rest of at least half an hour. Section 127 sets a fine of up to 5,000 baht on the licensed crew member who breaches it, which in practice means the driver, not the company that planned the route.
Two things about that section matter for the loop.
It counts time, not distance. An hour stuck at a closure with the driver at the wheel uses the same four-hour allowance as an hour at 80 km/h. A delay does not just push arrivals later. It can push the driver past a legal rest point that the original plan fitted comfortably.
It contains no daily total. Summaries in circulation often attach an eight-hour or ten-hour daily cap to this section. The section itself does not say that. If a daily limit applies to your drivers, it comes from somewhere else, and it should be read in the original before it goes into a plan.
This article counts only time at the wheel, including time stuck in traffic, and treats only a deliberate, unbroken half hour away from the wheel as the rest the section requires. Unloading stops are not counted as rest. That is the cautious reading, and it is the one a controller can defend.
Apply it to the worked day. In the original plan, the driver reaches the rest after C with 155 minutes at the wheel. After the closure, the driver reaches B with 175 minutes, and would reach C with 225, still inside four hours with 15 minutes to spare. The original sequence was legal even on the bad day.
The skip-C option is where the check bites. Driving straight from B to D takes 120 minutes. Without a rest first, that is 175 plus 120, or 295 minutes continuously at the wheel, which is 55 minutes over. With a half-hour rest at B from 11:05 to 11:35, the driver starts a fresh block and arrives at D at 13:35 with 120 minutes used, then drives home for another 90, finishing the second block at 210 minutes. The same fix is illegal without the rest and legal with it, and it still reaches D on time.
This is exactly the test the handbook describes for interactive scheduling software: a change is only accepted if the vehicle can still complete the work within its capacity, its time, the law and the service promised. A controller with a spreadsheet has to run the same test by hand, every time.
The state is running its own version of this loop on the same feed. Over the New Year week at the turn of 2020, the Department followed 598,484 buses and trucks through its GPS centre and found 31,112 of them exceeding the speed limit, about 5.2%. Whatever your controller is not watching, somebody else may be.
Decide in advance who may do what
The loop fails most often not because nobody saw the problem but because the person who saw it was not allowed to fix it. A controller who has to find a manager, who has to call the sales team, who has to call the customer, will run out of time before the 11:05 deadline in the example above.
Write down, before the day starts, which exceptions the controller solves alone and which need someone else:
| Exception | Controller decides alone | Needs someone else |
|---|---|---|
| Delay inside the smallest downstream slack | Watch, no action | |
| Delay beyond it, fixable by re-sequencing within the same vehicle and the legal driving time | Re-sequence and tell the affected customers | |
| A customer will be missed today | Propose the options | The person who owns that customer chooses which customer waits |
| Driver not fit, vehicle defect, or a driving-time breach if the plan continues | Stop the vehicle | Operations manager, for the replacement |
| Anything involving safety on the road | Stop first | Everyone else afterwards |
Also decide the customer promise for bad days. A customer told at 09:40 that the truck will be forty minutes late usually has options. A customer who discovers it at 14:40 has none, and neither do you.
Close the day, or tomorrow repeats it
The last step is the one most often skipped, because by the end of the day everyone is tired and every truck is back.
For every stop, record three things: planned arrival against actual arrival, planned time on site against actual time on site, and a reason code for anything more than the slack you allow. Keep the reason codes short and split them by who controls the cause:
- Our side: loaded late, loaded in the wrong order, wrong or missing documents
- Customer side: gate queue, receiving not ready, refused goods
- Road: closure, accident, congestion beyond the plan
- Vehicle or driver: defect, fitness, legal rest taken where it was not planned
Then read them weekly, not daily. A rescue that happens every week at the same stop is not a rescue. It is a planning error. If D is always forty minutes late, the plan's travel time or D's window is wrong, and the fix is to change the plan once rather than save the day every Thursday. The stop times and travel times you record belong in the delivery point record your plans read from, which is the subject of master data before software: addresses, access, opening hours and vehicle restrictions.
The closing step also keeps the performance number honest. If late deliveries are counted only when a customer complains, the loop will always look better than it is. How to define the number so that it holds up is in measuring on-time delivery honestly, then actually moving it.
What to set up this week
- Add a slack column to every route plan. For each stop, the latest arrival the customer will accept minus the planned arrival. Most plans already have both times and have never subtracted them.
- Mark the smallest downstream slack on each route. That is the route's alarm threshold. Tell the controller what it is before the truck leaves.
- Agree three status messages with drivers: arrived, unloaded, left. Plus a reason whenever one is late. The recorder will not send these for you.
- Merge the release checks with the safety duties. Vehicle form, alcohol test, fitness, plan confirmed with the driver, load checked. One person, before the gate, every vehicle.
- For every stop with less than an hour of slack, write down the fixes and when each one expires. Extend the window, re-sequence, skip a drop, send a second vehicle.
- Run every re-plan through the driving-time check before telling the driver: minutes at the wheel since the last unbroken half hour of rest, plus the new driving, must stay at four hours or under.
- Write the decision rights table and give it to the controller. Who chooses which customer waits is a commercial decision, and it cannot be made at 09:30 by someone who has to ask.
- Close every day with planned against actual and a reason code, and read the codes weekly. Change the plan for anything that repeats.
How narrow a customer's window is decides how much slack a route ever has to work with, and why that costs more than the kilometres is covered in why your delivery window costs more than your distance.
The one line worth keeping
The problem you can still fix cheaply is almost never at the stop where the truck is. It is at the stop with the least slack, hours down the route, and the time to fix it runs out long before anyone there knows anything is wrong.