Development of an AI system for cross-docking optimization

Cross-docking AI: why the flow falls apart under overload

The transshipment hub carries the entire chain: trucks are unloaded here, sorted by destination, and sent onward without warehouse storage. While the load is even, the scheme works on its own.

At peak — when a dozen trucks arrive within an hour and the unloading plan was drawn up in the morning and has not been recalculated since — the flow breaks in three places at once.

First — dock downtime. Dock doors are occupied by work that does not create flow: a vehicle with an urgent route waits in queue while the ramp is given to pallets that could easily go out on the next shift. Second — manual recalculation of priorities.

The dispatcher keeps the sequence in their head and switches dock doors based on calls, so a decision comes with a 15–20 minute delay, and by the end of the shift the queue grows faster than they can clear it.

Third — traceability. If a scanner or accounting node fails, the “cargo — dock — trip” link breaks, and the consignment is searched for by paper marks, no longer understanding which vehicle it left on or whether it left at all. The error surfaces not at the moment of failure but at customer receiving.

Cross-docking AI addresses exactly these points: dock doors are allocated according to the actual composition of the flow, priorities are recalculated on the fly, and consignment state is recorded at every transition between zones. We explain how it is structured and what it delivers in numbers.

What managed transshipment delivers: effect in measurable values

The effect of managed transshipment is visible not in a demo but in warehouse operational metrics: vehicle processing window, smoothness of supply waves, share of incorrect priorities.

We capture these values before launch and compare them on the live flow — otherwise improvement can neither be proven nor protected from rollback to manual mode.

The processing window — gate-to-gate time — shrinks by allocating dock slots in advance rather than at the moment of arrival.

The model accounts for cargo type, dock door occupancy, and receiving readiness, so a vehicle pulls up to the dock where it is already expected, not to the first available one. On dense flows, this reduces the window by a quarter or more.

Supply predictability grows through wave leveling: arrival time variance within the window narrows, and peak hours stop determining shift headcount. Dock utilization is distributed more evenly, and some idle time disappears without expanding space.

A separate class of failures is incorrect priority: perishables and cargo with a fixed release time went to the end of the queue as soon as a trip shifted.

Priorities are recalculated automatically with every change in the situation, so the share of such errors drops to single-digit percentages, and the dispatcher works with exceptions rather than manual row sorting.

The optimizer runs on top of the accounting system: we pull orders, stock, and slots from SAP via standard interfaces and do not create a separate data warehouse.

This eliminates discrepancies between the transshipment plan and the actual warehouse state — the planner sees the same picture as receiving.

Cross-docking AI: operating modes and their limitations

The optimization mode determines how often the schedule of dock doors, unloading zones, and picking order is rebuilt. This determines data requirements, plan stability within a shift, and the cost of error in source data.

Forecast based on shipping history builds the schedule in advance: it estimates arrival distribution by windows and cargo structure. Online priority recalculation reacts to an event — vehicle arrived earlier, composition changed — and rebuilds the queue based on facts.

What changes when switching between modes

Changing mode is primarily a new level of data quality.

Forecast needs shipping history and reference data; online recalculation needs arrival events from the accounting system (SAP EWM) with a delay of just a few minutes — otherwise decisions are made based on an outdated picture.

Model limitations are common to all options: forecast works poorly on new routes and one-off promotions, online recalculation depends on the completeness of recorded events, and hybrid inherits both weaknesses if priority rules are not formally described.

How implementation proceeds: from flow audit to shift handover

We start not with the model but with measurements: we look at how cargo actually passes through dock doors, where a queue accumulates at receiving, and how much time manual dispatcher decisions take.

Based on the audit, we record baseline metrics — cycle time from vehicle arrival to shipping, share of dock reassignments, dock door downtime — and then compare each subsequent step against them.

1. Flow audit. We analyze inbound deliveries, delivery windows, capacity of dock doors and temporary storage zones, and retrieve scanning and downtime logs for several weeks.
2. Priority scheme. We agree with the shift supervisor on rules: what matters more — shipping deadline, consignment weight, temperature regime, customer urgency. The rules become formal criteria, not a decision “at the dispatcher’s discretion.”
3. Integration setup. We connect to warehouse and transport systems, item master data, and weight control data. We verify that the algorithm sees the same stock and statuses as the operator.
4. Training on warehouse history. On labeled shifts, the system learns to predict processing time and the risk of missing the shipping window; separately, we configure rules for rolling back to manual mode.
5. Shift testing. We launch in shadow mode: the algorithm suggests allocation, but the dispatcher is in command. We compare suggestions with actual decisions and review discrepancies with peers.
6. Solution handover. We train the shift to work with suggestions, hand over documentation on rules and settings, and leave a support channel for the first period of independent work.

Configurations, flow diagrams, and regulations at delivery

We hand over not a presentation, but a working kit that the shift can use without us. Everything is stored in your repository and versioned: any rule change is visible in history, and rollback to a previous version takes minutes, not a day.

• Solution configurations — parameter files: forecast horizon, dock door and dock priority rules, confidence threshold below which a decision goes to the dispatcher for confirmation.
• Flow diagrams — where cargo status comes from, how warehouse accounting system events are linked to shipping requests, and where manual intervention points are.
• Access policies — roles and rights: dispatcher corrects, analyst only reads, service writes to its own environment; key rotation rules and lifetimes.
• Documentation — data model description, reference data, field map, failure scenarios, and known limitations by cargo type.
• Shift regulations — what the dispatcher does when the forecast diverges from fact, communication with the accounting system is lost, or manual mode is needed.
• Deployment and rollback procedure — environments, list of steps for rolling out a new version of rules, and a way to return to the previous one in a single pass.
• Acceptance protocol — control shifts with metrics: share of decisions accepted without edits, arrival time deviation, number of manual switches.

We finish the handover with a walkthrough: we discuss each artifact with your team so that operations do not depend on us.

Transshipment hub case: metrics before and after

Implementation case — a retailer’s transshipment hub retailer transshipment hub with more than 40 dock positions and 180–220 trips per day. The dispatcher assigned incoming trucks to unloading windows manually, relying on a spreadsheet and calls from carriers.

The share of vehicles that arrived outside the agreed window reached 23%, and repeated repositionings — 3–4 per trip: the semitrailer was moved to add consolidated cargo.

What was changed

The model calculates the transshipment scheme over the shift horizon: it matches unloading and loading windows, weight and dimension constraints for each cargo, customer priorities, and actual vehicle arrivals.

The dispatcher received a queue with estimated time and the reason for each decision; their role shifted from manual selection to handling exceptions.

What changed

Share of vehicles outside the window — 5–7%, repeated repositionings — 0.6–0.9 per trip at the same volume. Manual dispatching operations per shift decreased fourfold; the freed-up time went to non-standard cargo and emergency legs.

Transport idle time during operations decreased by about a third, and the evening peak stopped spilling over into the next shift.

We take metrics from the dispatching log and vehicle arrival data, so the project result is compared by shift, not by feeling. This measurement also showed where the model makes mistakes: on mixed consolidated trips, it had to be further trained on actual repositionings.

What to do if the site already has a warehouse system?

The existing warehouse system does not require shutdown or full replacement — the AI layer is added alongside and receives data through an intermediate exchange layer.

The choice comes down to three coexistence modes, and they differ not in functions but in who makes the priority decision in a conflict.

The intermediate layer holds a queue of receiving, shipping, and movement events, normalizes item and warehouse reference data, and suppresses duplicates by operation key.

Redelivery of an event does not create a second task at the site, and data version discrepancy is resolved by event time, not delivery time.

During phased replacement, the new logic first runs in shadow mode: decisions are written to the log but are not put into operation.

Reconciliation of plan and fact for each receiving wave shows where the calculation diverges, and only after consistent matching does control switch to the new system. Rollback is the reverse switching of decision routing, without data migration.

Integration with the accounting system remains one-way for data and two-way for statuses: the previous system retains the role of source of truth until control is transferred.

Common technical doubts before launch

Before calculating the effect, we address four questions that most often delay the start: whether there is enough data, what happens if communication fails, what forecast accuracy is sufficient, and who is responsible for the system after handover. Below are short answers to the point.

What happens if communication with the accounting system fails?

The system continues to work on the last confirmed data and maintains a queue of operations, then synchronizes after communication is restored. Discrepancies are flagged and included in a report for the dispatcher — planning does not stop and does not issue incorrect assignments.

How accurate should the forecast be?

We fix the metric before launch: the share of deviations that fall within the agreed window by arrival time and consignment volume. We compare not with an ideal but with current manual planning — the forecast ranks options, and the decision remains with the dispatcher.

Who is responsible for the system after launch?

We hand over configurations, integration diagrams, and incident response procedures, and train your team. The model, integrations, and monitoring remain with us; business rules and route priorities remain on your side. During the first weeks of support, we track planning metrics and adjust thresholds.

Let’s discuss your transshipment scheme and come back with a plan

Any cross-docking review always starts with site inputs: without them, the model remains theoretical and the calculation detached from the shift.

We capture the current transshipment picture and see exactly where time is lost — at vehicle approach, in receiving, or in cargo accumulation for shipping.

To discuss the task substantively and come back with a timeline estimate and work plan rather than clarifying questions, send us:

• site layout: receiving, buffer storage, and shipping zones, number of dock doors and their throughput capacity;
• export from the accounting system for several months — vehicle arrival and departure times, delivery composition, volume by route;
• cargo reference data: dimensions, weight, temperature regime, requirements for adjacency at the site;
• carrier shipping windows and priority rules: which routes must not be delayed under any circumstances;
• shift constraints: number of forklifts and operators, working hours, receiving regulations.

After that, the work proceeds without your involvement: we clean the data, assemble the transshipment model, run it on your history, and compare decisions with what dispatchers actually did.

We come back with a timeline estimate, stage plan, and a list of what needs to be prepared at the site to start the project — from data exchange with the accounting system to the first shifts in operator suggestion mode.