Start with the data that breaks routes, not the data that looks tidy

A route optimisation system can look brilliant in a demo and still fall apart on a Tuesday morning in dispatch.

That usually happens because the team asked the wrong first question. Not “What platform should we buy?” but What data do I need before I can build a route optimisation system that actually works in practice? If the answer is fuzzy, the software will be too. The optimiser will happily produce neat-looking runs based on bad stop data, guessed service times, and vehicle limits that never existed in the real world.

I’ve seen this pattern enough times to call it out plainly. The first version does not need every possible field. It needs the fields that stop the optimiser from making confident mistakes.

The first version needs a small, hard set of fields

If you are building route optimisation for transport and distribution in Australia, start with the data that drives three things: where the stop is, when it can be served, and whether the vehicle can actually carry it.

Non-negotiable fields

For a first working version, these are the fields that matter most:

Stop address
Latitude and longitude
Delivery date or service day
Time window, if one exists
Stop sequence constraints, if any
Vehicle ID or vehicle type
Capacity limits
Load measures, at least one of weight, cube, or pallet count
Service duration, even if it is only a rough average
Depot or start point
Pickup versus delivery flag

If you do not have these, the optimiser can still return a route, but it will be a route on paper, not in the yard.

Fields that can be missing at first

These are useful, but they should not block the first build:

Customer marketing names
Full contact details
Proof of delivery notes
Driver notes written in free text
Product descriptions down to SKU level
Exact dock door assignment
Customer preference tags

Those fields help later, especially for exception handling and customer communication. They are not what makes the first route feasible.

Key takeaway: if the optimiser cannot trust location, time, and capacity, every other field is decoration.

Stop data is where most projects quietly fail

The mess is usually not in the routing engine. It is in the stop master.

Dispatch has one name for the customer. CRM has another. ERP has a third. The geocode points to the head office in the city, while the actual delivery bay is out the back in an industrial estate. Then someone in the warehouse has been manually fixing the address for six months, but only in a spreadsheet no one else sees.

That is why What data do I need before I can build a route optimisation system that actually works in practice? is really a data matching problem first.

How to clean messy stop data without pretending it is clean

Do not try to “fix” everything in one pass. Build a reconciliation layer.

Choose one canonical stop ID Use a single unique ID for each delivery location. Not customer name. Not invoice number. A proper location ID that survives across dispatch, CRM, and ERP.
Store multiple address versions Keep the raw address from each source, plus a standardised address. That way you can trace where the mismatch came from.
Separate customer identity from delivery location One customer can have three sites. One site can receive freight for several customers. Treat those as different records.
Validate geocodes against the actual delivery point A rooftop geocode for a CBD office is not the same as a loading dock geocode. In Australia, that matters more than people admit, especially around multi-tenant sites and industrial parks.
Flag confidence, do not hide uncertainty If the address match is weak, mark it. Do not let the optimiser treat a guessed stop as if it were verified.

If you are already dealing with dispatch drift, the post on Why Do ETAs Differ in TMS, Carrier, and Dashboard? is worth reading alongside this. The same data mismatch usually sits behind both problems.

Historical delivery data helps, but only if it reflects reality

A lot of teams want years of history because they think more data automatically means better routes. It does not.

For route optimisation, the minimum useful history is usually 8 to 12 weeks of clean operational data. That is enough to see weekday patterns, recurring service times, and common delivery clusters. If your network changes with seasons, promotions, or harvest cycles, you will need enough history to cover a meaningful operating cycle, not just a random month.

What history should include

You want history that shows:

actual arrival time
actual departure time
service duration
stop order
route or run ID
vehicle used
driver used, if driver behaviour affects service time
failed delivery or reattempt reason
traffic or access issues, if captured consistently

What too much history looks like

More than 12 months is often where teams start dragging in noise.

Old data becomes misleading when:

your depot moved
the fleet changed
customer density changed
service rules changed
the warehouse cut-off moved
the mix shifted from pallet freight to mixed-case or vice versa

If the operation changed, old data can make the optimiser confidently wrong. For many Australian businesses, especially those running metropolitan and regional routes out of different depots, six to twelve months is plenty if the data is clean. Two years of messy history is worse than three months of usable history.

If you are choosing where to base operations, the data needs change too. The post on What Factors Should I Compare in Two Warehouse Locations? covers the location side of that decision, which feeds directly into routing efficiency.

Capacity planning is where weight alone gets people into trouble

If vehicle capacity planning is part of the route optimisation system, this is the part most teams underestimate.

They record weight because it is easy to get from the ERP. Then the truck runs out of cube, or pallet spaces, or axle-friendly load balance long before it hits the weight limit.

The capacity fields that matter most

In practice, the order of usefulness is usually:

Pallet count
Cube
Weight
Special handling constraints

That order changes by freight type, but the main mistake is the same. People assume one measure is enough.

What is usually recorded incorrectly

Weight is often rounded, copied from a product master, or missing packaging weight.
Cube is frequently stale because packaging changes faster than master data.
Pallet count is wrong when mixed freight is broken down manually at the dock.
Special handling notes are buried in comments instead of structured fields.

If you are moving general freight, parcel, or mixed pallet loads, cube and pallet count often matter more than weight for route feasibility. Weight still matters for legal and vehicle limits, but it is not the whole story. A vehicle can be under weight and still be full.

This is where freight handling at the dock affects the optimiser. If freight is not consolidated consistently, the route engine gets bad capacity inputs before the truck even leaves. In operations with freight handling, warehousing, and transport tied together, that handoff has to be tight. Services like Freight Handling and Warehousing & Storage matter because they reduce the number of bad inputs entering the planning cycle in the first place.

Stop duration data is usually unreliable, so build around that

This is the other trap. Teams want precise stop durations before they start. They do not have them, so they guess. Then the optimiser produces elegant routes that collapse at the first loading bay.

The question is not whether you have perfect stop duration data. You do not. The question is how to stop missing durations from poisoning the plan.

A practical way to handle it

Use a tiered approach:

If you have measured history, use median stop duration by stop type, customer, and freight profile.
If you have partial history, use grouped averages by zone, vehicle type, and delivery pattern.
If you have no history, start with conservative defaults and adjust after two to four weeks of live runs.

Do not use a single average for every stop. That is how you get routes that look balanced in the system and blow out in the yard.

What to measure instead of guessing

If your current data is thin, capture these three things first:

time arrived on site
time first item offloaded
time vehicle departs

That gives you a real service duration, not a theoretical one. If the driver waits for access, note that separately. If the delay is caused by customer receiving, dock congestion, or paperwork, you need to know which one. Otherwise the optimiser will blame the wrong part of the run.

A route that saves 40 minutes on screen but adds 15 minutes of unloading at three stops is not efficient. It is just tidy-looking failure.

The first build should be strict about data, not broad about ambition

If you are asking What data do I need before I can build a route optimisation system that actually works in practice?, the honest answer is this: enough to make the optimiser respect geography, time, and capacity, and no more than you can keep accurate.

That means your first build should prioritise:

verified stop locations
realistic vehicle capacity rules
actual service times
simple delivery windows
current fleet and depot structure
one source of truth for each stop

What to leave for version two

You can add these later:

driver preference scoring
customer-specific ranking rules
carbon emissions reporting
advanced traffic modelling
automated exception messaging
multi-echelon inventory logic

Those are worthwhile. They are not the thing that gets the first route right.

If you are also thinking about transport risk during peaks, especially in Australia’s pre-Christmas freight surge, the post on How do I manage transport risk during peak season? is a sensible next read. Route optimisation only helps if the data still holds when volumes spike.

A simple checklist before you switch the optimiser on

Use this as a gate before you let the system plan live runs:

Can every stop be matched to one verified location?
Do you know which stops have time windows?
Can you identify vehicle capacity by the right measure, not just weight?
Do you have at least 8 to 12 weeks of usable history?
Can you separate delivery time from waiting time?
Do dispatch, ERP, and CRM agree on the same stop ID?
Are depot start times and cut-offs current?
Can the warehouse confirm what actually left the dock?

If the answer is no to two or more of those, do not blame the optimiser yet. Fix the inputs first.

What good looks like in real operations

A decent route optimisation system does not need perfect data. It needs dependable data.

That usually means the system can:

build routes that fit the vehicle
respect delivery windows
avoid impossible stop counts
keep ETAs within a realistic band
survive messy exceptions without manual rework all day

For businesses running metropolitan, regional, or interstate movements across Australia, that often depends on the handoff between warehouse, dispatch, and transport. If those are already operating as separate silos, a broader Transport & Distribution setup can help align the data flow before you automate the planning logic.

The shortest path to a route engine that holds up

Start with one depot, one vehicle type, and one clean week of deliveries. Reconcile the stop master. Validate geocodes. Pull 8 to 12 weeks of actual service history. Use pallet count, cube, and weight together. Then test the optimiser against real dispatch constraints, not a perfect mock-up.

That is the practical answer to What data do I need before I can build a route optimisation system that actually works in practice? Not every field. The right fields. Clean enough to trust. Stable enough to plan on.

If you want the faster path, RAKC Group’s Logistics Solutions service can help align warehousing, transport, and distribution data so the routing logic is built on operations that actually match the floor, not just the spreadsheet.

What Data Do I Need for Route Optimization?