Why are trunking and final mile still planned in separate systems?
Gary Rosier-Taylor · Co-founder
What problem does a cross-dock solve?
A cross-dock stops you paying long-distance vehicles to do local work. Take a national distributor with depots in London, Leicester and Cardiff, delivering to stores in Scotland and the North of England.
The simple approach is to load a truck at the depot and drive it to every store. That works when the stores are close. When they're 300 miles away it doesn't: the vehicle spends most of the day on the motorway, the driver runs out of hours before the deliveries are done, and you pay for a long-distance vehicle to do short, local drops.
A cross-dock fixes that. Loads from several depots are consolidated onto overnight trunks, unloaded at a regional hub, and sent out on local routes the next morning. Trunk vehicles do the long, efficient miles. Local vehicles do the drops. Each vehicle does the work it's suited to.
Why is cross-dock planning so hard?
Because every decision depends on another one. For each job, someone has to answer:
- Should it go direct, or through a hub?
- If a hub, which one, and on which trunk?
- Will the trunk arrive before the hub's cut-off, with time to unload and cross-dock?
- Is there an onward route after that which still meets the customer's delivery window?
- Are there enough dock doors for everything arriving and leaving?
Change one answer and the others move with it. Send a job via Leeds instead of Glasgow and you've changed the trunk's load, its arrival time, the onward route that collects it, and maybe the door schedule at both hubs.
Most planning software is built to answer one of those questions well. Very little is built to answer all of them at once.
How do most operators plan cross-docking today?
Usually in two halves, joined together by people.
Trunking is planned in one specialist application, often a desktop tool, and often against a pre-determined trunking schedule that changes once a season rather than once a day. Final mile is planned in another application, which treats whatever arrives at the hub as if it were simply stock at a depot.
Planners export from one system, re-key or upload into the other, and hope the times still line up. They usually do, because the schedules carry enough padding to absorb the gap. That isn't the planners' fault. It's the only sensible way to run two systems that can't see each other. But the padding is cost: trunks that leave half full because the schedule says so, onward vehicles waiting at the hub for loads that were never going to be early, and jobs sent the long way round because nobody had time to check whether the hub would have been cheaper.
When the trunk and the final mile are planned in different systems, the gap between them is filled with padding, spreadsheets and hope.
What happens when a trunk runs late?
When a trunk runs late in a split world, the final mile usually finds out too late to do anything about it.
A trunk leaving Leicester at 18:30 is due at the Glasgow hub at 02:10. The hub needs two hours to unload and cross-dock. The onward routes are due to collect from 05:15. On paper there's an hour of slack.
Then the trunk is held up. The trunking system might know it's late, but it doesn't know which onward routes depend on it, which stores are on those routes, or which customers have tight delivery windows. The final-mile system doesn't know the trunk exists. By the time anyone joins the dots, the onward vehicle has either left without the load or is sitting at the hub burning time.
How does ProprTMS plan cross-docking?
In ProprTMS, multi-leg cross-dock planning is part of the same engine and the same screens as everything else.
Planned together. The optimiser decides, job by job, whether to deliver direct or via a hub. It picks the hub and the trunk, and plans the onward route, all in a single optimisation. There's no fixed trunking schedule to work around: trunks are built from the jobs you actually have.
Hub rules built in. Each hub has its own dwell time and cut-off, and dock door limits are respected. Onward routes only collect once the goods are unloaded, staged and ready, even when the trunk ran the day before.
A safety net. If a job can't make a sensible onward connection, it's planned direct rather than left behind.
Linked on screen. Select any trunk and you see every onward route it feeds, with dates, loads and the slack at the hub. If a trunk is running late, you can see which deliveries are at risk before they fail, not after.
One system. There's no separate trunk planner, no second licence, no second implementation, and no spreadsheets passed between the two.
How does split planning compare with one plan?
The difference shows up in every decision that crosses the hub.
| Planning decision | Trunking and final mile in separate systems | Trunk, hub and final mile in ProprTMS |
|---|---|---|
| Direct or via a hub | Fixed by rule or habit, reviewed occasionally | Decided by the optimiser for every job, every plan |
| Trunk schedule | Pre-determined, changed seasonally | Built from the day's actual jobs |
| Hub timing | Padded to absorb uncertainty | Dwell time and cut-off modelled per hub |
| Dock doors | Checked by hand, if at all | Door limits respected in the plan |
| Onward collection | Planned as if the stock was already there | Only after the trunk has unloaded and the goods are ready |
| Jobs that miss a connection | Found late, rescheduled manually | Planned direct instead |
| A late trunk | Seen in one system, felt in the other | Linked onward routes and at-risk deliveries visible on screen |
| Licences and training | Two tools, two implementations, two skill sets | One platform, one way of working |
Who is this for?
ProprTMS cross-dock planning is aimed at UK operators who:
- run trunks between depots or regional hubs and deliver onwards to stores, sites or customers
- plan trunking and final mile in separate systems, or in a spreadsheet alongside one
- rely on fixed trunking schedules that they suspect carry too much padding
- want to see the knock-on effect of a late trunk before it becomes a missed delivery
It's the same platform you'd use for any other routing work, so the planners who build your local routes can build your trunks too.
Frequently asked questions
What is cross-docking in transport?
Cross-docking is moving goods from inbound vehicles to outbound vehicles at a hub with little or no time in storage. In distribution it usually means consolidating loads onto long-distance trunks, unloading at a regional hub, and delivering onwards on local routes.
What is a trunk leg?
A trunk leg is the long-distance part of a multi-leg journey, typically an overnight run between a depot and a regional hub. The final mile is the local delivery from the hub to the customer.
Does every job have to go through a hub?
No. The optimiser decides for each job whether a hub saves time and cost. Jobs that are better delivered direct are planned direct, and jobs that can't make a sensible onward connection fall back to direct delivery.
Can a trunk run the day before the delivery?
Yes. Trunks can run overnight or on an earlier day, and onward routes are timed from when the goods are actually unloaded and ready at the hub.
Are dock doors taken into account?
Yes. Each location can have a dock door limit, and the plan respects it for vehicles arriving at and leaving the hub. If there aren't enough doors for everything, the plan tells you rather than quietly overbooking them.
Do we need a separate licence for cross-dock planning?
No. Cross-dock planning uses the same engine, screens and subscription as the rest of ProprTMS.
Ready to prove it?
Don't take our word for it. With Propr Start, you run ProprTMS in your live operation for three months and measure it against your own baseline before you decide.
We launch on 1 December 2026 and still have a few founding customer places left. If you run trunk and final-mile operations in the UK, especially if you plan them in separate systems today, we'd love to hear how you do it.
Place names, times and routes in this article are illustrative examples, not customer data.