The software arrives, the data is loaded, the first plan comes out, and the plan is wrong. Two trucks are sent to a site that can only take one at a time. A ten-wheeler is routed down a lane it cannot turn in. A drop is scheduled for 11:30 at a plant that stops receiving at 11:00 for lunch and does not start again until 13:00. Within three weeks the planners are overriding the system on most routes, and within three months the system is a piece of shelfware everybody blames.
Almost none of this is the software's fault. A planning system is a calculator. It reads a record of every place a truck goes, applies rules to it, and returns a plan. If the record is wrong, the plan is wrong, and it is wrong confidently, in a printout, with times on it.
That record is master data. It is the part of the job that nobody wants to do, it takes weeks, and it is the only part that keeps working after the software changes. This is what belongs in it, why three of the fields are harder in Thailand than the textbook admits, and how to fill them from data your operation is already generating.
What a plan is actually reading
A delivery plan needs seven kinds of input: how much is going, how far apart the points are, what each customer will and will not accept, what the vehicles can do, what the drivers are allowed to do, what the route as a whole can look like, and what the goods themselves impose.
Notice what that list is mostly made of. Only the first one, demand, changes every day. The other six describe places, vehicles and rules that are the same tomorrow as they were yesterday. That asymmetry is the whole argument for master data. You cannot stop re-entering tomorrow's orders, but you should only ever have to work out once that the Samut Prakan site has a 3.8 metre gate and stops receiving at 15:30.
So the useful way to hold it is one record per delivery point, owned by somebody, with the order data flowing past it rather than into it. Every planner, every carrier brief and every system you ever buy reads the same record.
Four fields in that record do most of the damage when they are wrong.
Where it is, which is not the same as the address
The first field is location, and in Thailand the address is not it.
A Thai address runs from the smallest unit to the largest: house number, village number in rural areas, soi, road, sub-district, district, province, postcode. The problem is not the order. The problem is that house numbers are not laid out in order along a street. They are scattered, particularly inside private areas and housing estates, so two numbers one apart can sit nowhere near each other. The finding from the researchers who looked at this is blunt: the numbering pattern cannot be matched against street lines at all, which means the interpolation that geocoding was built on does not work here. There is also no national database of address points to fall back on. The Fundamental Geographic Data Set publishes thirteen layers, including administrative boundaries, roads, land use and elevation, and none of them can put a pin on a building.
You can see the result in the numbers. A team at Naresuan University put 1,511 Thai addresses through five geocoding services, with 1,100 going into the comparison. Submitting the full address including the postcode, Google returned a rooftop-level match on 3.73% of them and an interpolated one on 61.45%. Bing had the best rooftop rate at 17.82%, but failed to match 68.45% of the addresses at all. MapQuest returned an interpolated match 98.55% of the time, Yahoo! 97.45%, OpenCage 88.18%.
An interpolated match is the dangerous one. It is not an error message. It is a pin, on a map, in roughly the right area, and it will be silently accepted by every planning system you feed it to.
Two findings from that study are worth acting on directly.
The first is that dropping the postcode raised the match rate and lowered the accuracy. Good matches rose to 21.64% for MapQuest, 17.91% for Bing and 17.27% for Google once the postcode came out, but every one of the five services got positionally worse. The services fall back to a wider area and report success. If you are geocoding in bulk and judging the result by how many rows came back matched, you will pick the setting that is measurably worse.
The second is about how the string is written. Thai addresses are usually written with the component labels in them: the words for village number, sub-district, district and province sitting in front of the values. When the researchers submitted an address with those labels included, MapQuest and Yahoo! returned locations in the United States and in Japan. The same address with the labels stripped out, values only, geocoded correctly in Phitsanulok. Your ERP almost certainly stores the address as one free-text line with the labels in it, because that is how it gets printed on an invoice.
None of this is a reason to give up on geocoding. It is a reason to treat the geocoded pin as a first draft and the verified coordinate as the master data.
What to do:
- Store a latitude and longitude as its own field, separate from the postal address. The address is for the invoice and the paperwork. The coordinate is for the plan.
- Capture it at the gate, not from a desk. The point you want is where the vehicle stops, which is the entrance the truck uses, not the building centroid and not the front door of the office. A driver standing at the gate with a phone gives you a better coordinate than any service will.
- When you do geocode in bulk, send values without the Thai labels, keep the postcode in, and treat everything that did not come back as a rooftop match as unverified.
- Never let a delivery point be created without a coordinate. This is the single control that stops the file rotting, and it has to be enforced at the point of creation, because nobody goes back.
What can get in
The second field is access, and it has two halves that get confused: what the site can take, and what the road to the site can take.
The site half is unwritten. Nobody publishes the width of a factory gate, the turning circle in a yard, the height of a canopy over a loading bay, whether there is a dock or a driver working off a tail lift, whether there is a fork-lift and somebody licensed to drive it, or how many vehicles can be on the site at once. There is no authority to look this up with. Either you hold it or nobody does.
The road half is published, but not in one place. Under Section 61 of the Highway Act, the Director of Highways for a given road can announce in the Royal Gazette a prohibition on vehicles over a stated weight, load weight or axle weight using that road, or on vehicles that could damage it. Which office has to approve that announcement depends on what kind of road it is: the Director-General of the Department of Highways for motorways, national highways and concession highways, the Director-General of the Department of Rural Roads for rural highways, and the provincial governor for local highways.
Read that again from a planner's seat. A vehicle that is comfortably legal on the national highway can be over the limit on the provincial road that leaves it, and over a different limit on the local road at the end, and the three limits were set by three different offices. The national axle table tells you what your truck may weigh. It does not tell you what this lane will accept.
The second paragraph of the same section is the one that catches people. Where an emergency or an accident has damaged a road or made it unsafe, the officer controlling that highway can impose the same prohibition immediately, by a notice posted openly at the location, for a stated period. That restriction is real, it is enforceable, and on the day it goes up it exists nowhere except on a sign at the roadside. The only way it reaches your planning file is if the driver who saw it tells somebody and somebody writes it down.
What to record per site:
- The largest vehicle that has actually delivered here, with the date. Not what the customer says they can take. Sites routinely say they can take a ten-wheeler because one came once, at night, and reversed for twenty minutes.
- The binding constraint and its number. Gate width in metres, height clearance in metres, or the turn that fails. A record that says "small truck only" tells a planner nothing they can substitute against.
- The unloading method and who does it. Dock, tail lift, forklift, or by hand. This is a cost, it is a time, and it is a frequent argument.
- The route restriction on the last stretch, held against the lane rather than the site, and dated. It changes.
When it will actually receive
The third field is time, and the trap is that "opening hours" is three different things.
There are the hours the site is open. There are the hours it will accept a vehicle, which are usually narrower. And there is the window your goods are actually expected in, which may be narrower still and set by someone in purchasing who has never spoken to the gate.
The standard constraint list for a delivery plan is longer than most people's data allows for: a specified delivery time, a delivery window between two clock times, early closing days, lunch breaks, access restrictions by vehicle size, unloading restrictions where no fork-lift is available, drop size limits where only so many pallets can be received at once, parking problems where the vehicle cannot stand in the road, and paperwork rules where the driver has to wait for a check and a signature.
Every one of those is a property of the site. Almost none of them is in a typical customer master file, which usually holds a name, an address, a payment term and a phone number.
Two Thai specifics deserve their own fields.
Lunch is a hard stop at a great many sites, and it is not a soft one you can push through with a phone call, because the person who signs is not there. If a site stops receiving between 12:00 and 13:00, that hour is a wall in the plan, and a planner who does not know about it will route straight into it and lose an hour of a vehicle's day.
Receiving windows and gate queues are different things. A site that receives from 08:00 to 16:00 but processes vehicles one at a time through one gate, with a fifteen-vehicle queue at 08:00, is not an eight-hour window. What you want in the record is the window and the arrival time that historically gets you released fastest, which is a thing you can measure rather than ask.
How long the stop takes
The fourth field is the one most operations do not hold at all, and it is the one that decides how many drops fit in a day.
A stop is not one number. It is a fixed part that happens no matter how little you deliver, and a variable part that scales with the size of the drop. The fixed part is the gate, the queue, the paperwork, the manoeuvre, the walk to find somebody. The variable part is the actual handling.
The textbook model splits sites into access groups and gives each a pair of numbers. In the worked version, an easy site runs 10 minutes fixed plus 0.025 minutes a case, a middling one 20 minutes plus 0.050, and a difficult one 25 minutes plus 0.075. The exact figures are a UK case-handling example and not a Thai pallet operation, but the shape is the point, and the shape is what you should be fitting your own numbers to.
You can fit it from two observations. Say your own timestamps at one customer show that deliveries of about 6 pallets take an average of 34 minutes and deliveries of about 18 pallets take an average of 70 minutes. The variable rate is the difference divided by the difference: 70 minus 34, over 18 minus 6, is 36 minutes over 12 pallets, or 3 minutes a pallet. The fixed part is what is left when you take the variable part out of either observation: 34 minus 6 times 3, which is 16 minutes. Check it against the other point, 18 times 3 plus 16, and you get 70.
So that site's record says 16 minutes fixed, 3 minutes a pallet. A 12-pallet drop there should take 52 minutes.
Now take a second customer with the same 12 pallets, but a gate queue, no dock and a tail lift, which measures out at 45 minutes fixed and 5 minutes a pallet. That drop takes 105 minutes. Same goods, same quantity, twice the vehicle time, and the difference is entirely a property of the place.
Put that on a day. If six hours of a shift are available for stops after driving and breaks, the first kind of site fits six or seven drops and the second fits three. Any planner working from one average stop time across all customers will build a route that is impossible at one end of the file and lazy at the other, and will get the blame for both.
You are already generating this data
The reason master data projects stall is that they look like data collection projects. Mostly they are not. Most of what you need has already been recorded and nobody has read it.
The journey data recorder. Vehicles covered by the Department of Land Transport's announcements carry a recorder that logs position, speed and time, transmits at least every five minutes, and holds the data for six months. That is a stationary period at a set of coordinates, several times a day, for every covered vehicle in the fleet or in your carrier's fleet. Arrival and release times at your customers, measured, going back half a year. The mandate is written vehicle class by vehicle class and does not reach every truck, so check what applies to the vehicles on your work before assuming the history is there. The same six months of evidence is what makes it possible to test whether your lanes actually repeat, which is the question behind choosing between fixed routes and planning every day.
Your own proof of delivery timestamps, if the driver records arrival as well as signature. Two timestamps per stop give you the stop duration; matching them to the delivery note gives you the quantity; a scatter of those pairs gives you the fixed and variable numbers above for every site you visit often enough.
Your own gate. The same arithmetic works on inbound vehicles, and the arrival-to-release distribution at your own dock is what any sensible free time allowance should be built from, rather than from a number in a carrier's standard terms. That is the argument in how waiting time charges work.
The drivers. Everything unwritten about access lives in their heads and nowhere else. A one-page form, filled in once per site, on which a driver marks the gate they use, the largest vehicle that fits, what goes wrong and what time it goes wrong, will get you further in two weeks than any survey.
What this buys is not just a better plan. A transportation company quoting your work prices exactly what you can describe, and prices the gaps at worst case. The tender data a carrier is entitled to expect includes the delivery quantity by location, the constraints on delivery times and the known problems at specific locations. A file that can answer those is the difference between a rate built on your operation and a rate built on a guess, which is the ground covered in what a carrier needs before it can quote.
The order to do it in
Do not start at record one and work down. The file is long and the value is concentrated.
- Rank your delivery points by vehicle time consumed, not by revenue and not alphabetically. Stops times average duration. The top fifty are where the plan actually breaks.
- Fix location first, because everything downstream reads it. Coordinate at the gate, verified, for the top fifty. Then the next fifty.
- Then time windows, from what the site actually does, not from what the customer master says.
- Then access, from drivers and from the largest vehicle that has genuinely delivered.
- Then stop duration, fitted from your own timestamps, and only for sites you visit often enough for an average to mean anything. A site you serve twice a year gets a guess and a flag.
- Then set the rule that closes the loop. No new delivery point without a coordinate, and a standing instruction that a driver who meets a restriction reports it the same day. Master data does not decay slowly. It decays the first time somebody creates a record in a hurry.
What it is worth, honestly
It is worth being straight about the size of the prize, because master data is usually sold with the software and the software is usually sold with a savings percentage.
A transportation company studied in 2023 had been planning its work from staff experience rather than records. When the researchers rebuilt the planning around a database of vehicles, drivers and customers, the time to look a piece of information up fell from 1.05 minutes to 0.13 minutes a job, and the time to work out a job's cost fell from 2.10 minutes to 0.30. Those are minutes, on a small operation, and on their own they would not pay for anything.
That is the honest scale of the clerical saving, and it is not the reason to do this. The reason is that until the record exists, every decision above it is being made on somebody's memory. You cannot compare two routing options, test a delivery frequency, brief a carrier accurately, or hold anyone to a delivery window, because there is nothing to compare against. The plan that comes out of a good system built on a bad file is not better than the planner's guess. It is the planner's guess with a timestamp on it, and much harder to argue with.
Build the file. Then buy the software.