article image

What WMS and TMS Integration Actually Changes on the Loading Dock

At 05:40 the plan is right. The orders are correct, the vehicles are assigned, the stops are sequenced. By 07:15 the third truck is loaded in the wrong order and nobody in the building knows it yet. They will find out at 11:00, from a driver standing in a customer's yard with the wrong pallet in front of him.

The gap between a correct plan and what physically happens on the dock is what integrating your warehouse and transport systems is supposed to close.

It is almost never how integration is sold.

The question the category never asks

Search for WMS and TMS integration and you will find the same article nine times. APIs. EDI. Data synchronisation. Eliminating silos. All true, all describing plumbing, none of it answering the only question an operations director actually has, which is what changes on my dock on Monday.

Integration gets framed as a data problem. It is really a question about where you draw the boundary around the thing you are optimising.

Plan the warehouse and the fleet separately and both get optimised properly. The routing engine produces an excellent route. The warehouse produces an efficient pick. Both are locally correct. The operation is still worse.

That is not a marketing claim. Arpan Rijal, Marco Bijvank and René de Koster modelled exactly this in Production and Operations Management in 2023, integrating order batching, picker scheduling, staging constraints and vehicle routing into a single problem and testing it against empirical data covering more than a million picked units. Planning the two together rather than in sequence produced total cost savings of 9 to 11 percent.

The important part is what happened to the routing. It got worse. Routing costs rose by 2 to 3 percent in the integrated plan. Total costs fell anyway, because coordinating with the warehouse allowed larger pick batches and fewer pickers, and that saving was bigger than what the routing gave up.

Read that again, because it is the entire argument.

The best transport plan is not the best plan.

An operation running its route optimisation and its warehouse scheduling as separate exercises is not slightly behind an integrated one. It is structurally unable to find the better answer, because the better answer requires accepting a worse route. Nothing in a standalone TMS will ever propose that, and nothing in a standalone WMS can ask for it.

So the question is not whether your systems exchange data. It is whether anything in your operation is capable of making a trade-off across the dock door.

Here is what that looks like in practice.

Why the last stop is loaded first

For a truck running six stops, the goods for stop six go on first. Deepest in the load, furthest from the tailgate. The goods for stop one go on last, right at the door, first off when the driver arrives.

Load it in the wrong order and the driver spends time at every stop moving freight that belongs to later deliveries. That time compounds across the run. It delays every subsequent stop, it damages goods, and it exhausts drivers.

This is not a niche concern. Reverse stop sequence loading is an engineered discipline in food service, beverage and drugstore distribution, where systems integrators build entire pick modules around it. Invar Systems documents a route truck fulfilment project designed specifically for fluid loading in reverse stop sequence, and the outcome the client valued most was not accuracy. It was being able to consistently get drivers on the road on time.

Now notice where the load sequence comes from. It is derived from the delivery route. The route lives in the transport plan. The people who need the sequence work in the warehouse.

If those are two systems, that instruction has to be carried across the gap by a person - a printed sheet, a briefing, a conversation at 6am. It usually is not carried at all. So the truck gets loaded in the order things were picked, because that is the only sequence anyone on the dock was ever given.

The sequence depends on how you pick

One caveat, because it changes the answer completely.

What the warehouse needs from the transport plan depends on the picking model. Pick order by order, as hyperlocal and same-day operations do, and the dependency is timing rather than sequence. Pick in consolidated batches, and the sequencing problem does not disappear, it moves from the pick face into the staging lane. Pick by truck, and the dispatch plan stops being an improvement and becomes a precondition: "by truck" is a category only the transport plan can define, so until that plan reaches the warehouse system the correct pick list cannot be generated at all.

It is worth being precise about the unit, too. Orders do not map neatly onto vehicles. Capacity forces splits, compliance forces splits that capacity would not, and one vehicle often runs more than once in a day. The real unit of planning is the load: a set of orders that fits one vehicle on one run, legally and physically, in a stop sequence. That is what the warehouse picks and stages against, and it only exists once capacity, compliance and route have been planned together.

The three picking models, and what each one needs from dispatch

When should the pick start?

The second question cannot be answered across a gap either.

A picking queue sorted by when orders were entered is sorted by the wrong thing. Order entry time has no relationship to when the goods have to be on a vehicle.

The right sequence runs backwards from the commitment. Take the delivery window, subtract the transit time for the route, and you have the moment the vehicle must leave. Subtract the loading window, subtract the staging time, and you have the latest moment the pick can start and still make it. That is a pick-by time, and it belongs on every order in the queue.

Sort the queue by pick-by time and the floor works the day's real commitments in order. An order going out on the early run rises above orders created before it. When three runs are in progress with different departure times, the queue shows which picks are critical right now and which have slack, without anyone cross-referencing a manifest. And when a pick-by time passes with the pick not started, that order can be flagged while there is still time to make the departure - rather than after the truck has left late.

Every input to that calculation comes from the transport side. Route, transit time, departure time. None of it exists inside a warehouse system that ends at the dock door.

How tightly coupled is this? In the same 2023 study, widening delivery windows by fifteen minutes produced total cost savings of 4 to 6 percent. Fifteen minutes. That is the scale at which warehouse and transport timing interact, and it is far finer than any nightly batch file can resolve.

Research on cutoff-based shipment promises in OR Spectrum in 2024 adds the corollary: what determines whether a warehouse hits its deadlines is utilisation, not demand or processing variability. The lever is not working harder. It is sequencing the work you already have against the promises you have already made.

The pick you should never have done

Everything so far flows one way, from the transport plan into the warehouse. The reverse direction is where a disconnected operation quietly burns the most labour.

A customer reschedules. A delivery goes on hold. A stop fails. In a disconnected operation the warehouse finds out afterwards, usually after the goods are picked, packed and staged. The pick was wasted, a staging lane is occupied by freight that is not going anywhere, and someone has to put it all back.

When the delivery status and the pick task live in the same system, the rescheduled stop cancels the pick before the picker reaches it. And the same channel runs forwards: if the warehouse can see live driver positions, picking for same-day work can be triggered by proximity rather than started hours in advance, so the order is ready when the driver arrives instead of sitting staged since the morning shift.

This is a systems problem, not a training problem

It is worth being clear about who is at fault on that badly loaded truck, because most operations go looking for a person.

The loader was never given the sequence. Nobody on that dock decided to ignore the route. The route was in another system, held by another team, and the only ordering information available at the dock was the order things came off the pick face in. The same is true of the picker who started the wrong order at 06:30, because the queue they were working from did not know a truck was leaving at 08:00 with their goods on it.

Operational knowledge that lives in one experienced coordinator's head is not resilience. It is a single point of failure that goes on holiday. Connecting these systems moves that knowledge out of people and into the process, so the person loading the truck does not need to know the route, and the day does not degrade when the coordinator is away.

What it looks like when there is only one plan

This is the gap Illuminate built Depot WMS and Cargo TMS not to have. Depot is the planning half, Cargo the execution half, and they share a data layer rather than an interface, so there is no boundary for a trade-off to fail to cross.

Depot evaluates the day's outstanding orders against every available vehicle, matching on compliance rules - cold chain to reefer trucks, tailgate deliveries to tailgate vehicles, hazardous goods to certified assets - as well as on weight and CBM capacity and zone structure. Vehicle capability and live availability come from the asset registry in Tagz AMS, so an asset in a maintenance window never appears in a plan. The planner reviews, adjusts the edge cases, and commits.

Because capacity and compliance are evaluated in the same pass, the plan resolves into loads rather than into trucks. A movement that exceeds one vehicle is split across loads while remaining a single visible transfer; co-loading conflicts are surfaced with the rule they breach and cannot be committed; and an asset can be scheduled for several runs in a day, each tracked separately as its own load with its own sequence of stops.

Commitment is the orchestrating event. In the same moment, the warehouse picking plan is generated with pick-by times already calculated, the load plan for each vehicle is issued to the dock in loading sequence, with picking directed on the mobile app in order or batch mode as the work requires, and driver trips appear in Cargo with the route, stop sequence and customer detail, before the vehicle leaves the yard. No export, no rekey, no manifest printed from a different version of the plan.

Then it runs back the other way. Live ETAs surface in the warehouse view. A rescheduled stop in Cargo pulls the pick in Depot. Proof of delivery closes the Depot fulfilment order and the sales order in Flow OMS, and stock updates to reflect what was actually delivered rather than what left the building.

There is a difference between connected and integrated. Integrated means two systems that were built separately and made to talk. Connected means one system that was never separate.

Do you have to replace your WMS?

No, and for most operations that would be the wrong project. Depot WMS runs either as a standalone warehouse management system with bidirectional ERP sync, or as an orchestration layer on top of a warehouse system you are keeping. The second mode exists precisely because the handover between planning and execution is worth fixing on its own.

Frequently asked questions

What is the difference between a WMS and a TMS?

A warehouse management system manages what happens inside the facility: receiving, putaway, inventory, picking, packing and load preparation. A transport management system manages what happens outside it: dispatch, routing, driver execution, tracking and proof of delivery. Integration is what makes them behave as one process rather than two.

Does integrating a WMS and a TMS actually save money?

Peer-reviewed research says yes, and by more than most operations expect. Rijal, Bijvank and de Koster (Production and Operations Management, 2023) found total cost savings of 9 to 11 percent from planning warehouse operations and vehicle routing together rather than sequentially. Ramaekers and colleagues (European Transport Research Review, 2018) reported around 14 percent in the smaller-scale B2C e-commerce scenarios they modelled. Notably, the integrated plan produced slightly worse routing costs and better total costs.

Why is load sequence important in delivery operations?

A truck is unloaded in the reverse of the order it was loaded. If the freight for the last stop is not loaded first, drivers move goods out of the way at every stop. That adds time at every drop, delays later stops, increases damage, and shortens the effective delivery window of the whole run.

Does the picking method change how warehouse and transport need to connect?

Substantially. Picking by order makes the dependency a timing one. Batch picking moves the sequencing problem into the staging area. Picking by truck makes the dispatch plan a precondition, because the pick list cannot be generated until the plan defines which orders belong to which vehicle and run. Full comparison here.

When should warehouse picking start before dispatch?

Work backwards from the delivery commitment: subtract transit time to get the departure time, then subtract loading and staging time to get the latest moment the pick can start. That pick-by time, not the order entry time, is the correct basis for sequencing the picking queue.

Can you integrate a WMS and a TMS without replacing either one?

Yes, using an orchestration layer above the existing systems. Illuminate's Depot WMS supports this as a deployment mode, adding dispatch planning and connected execution over a warehouse system a business intends to keep.

Which operations benefit most?

Those running multi-stop vehicles through customer or retail networks: wholesale and FMCG distribution, food and beverage, pharmaceutical distribution, 3PL operators and retail distribution centre networks. See Distribution and Couriers and Logistics.

References

The plan is the easy part. We run the execution.

If your warehouse and your fleet are still coordinating through spreadsheets, briefings and printed manifests, the cost is not in the handover. It is in every decision your operation cannot make because the two halves are optimised apart.

Talk to us about closing it



For media inquiries, please contact:
contact@illuminate.ae

Illuminate Software Solutions was founded in Dubai in 2017, when a consulting and solution delivery business that had operated in Canada since 2000 turned its operations and automation experience into products. It operates from the UAE, India and Canada. Its eight products - Cargo, Ryse, Tagz, Flow, Lyst, Depot, Mrkt and Kart - cover delivery logistics, warehousing, order management, CRM, pricing, assets, point of sale and customer portals. Each runs on its own, and none need integrating with each other: they share one data model, so a delivery confirmed in one product updates inventory, invoicing and the customer's order in the others. Anything outside connects to that same layer in real time - ERP systems, carriers, marketplaces, IoT devices - which is what gives AI a connected foundation rather than fragmented data. More than 10 million deliveries and a quarter of a billion dollars in order value have been processed to date, and every product is built in-house by one team with more than 25 years in business operations. illuminate.ae