At 16:30 two vans from the same carrier arrive at the warehouse for the same three pallets. One is turned away, and next month’s invoice carries a charge for a wasted collection. Or no van arrives: the pallets sit on the dock until the warehouse closes, and the customer promised delivery tomorrow learns from the tracking page that nothing has moved. Both afternoons began with a booking request that got no reply.

If your stock comes from a supplier, sits in a third-party warehouse and leaves with a carrier you book, logistics orchestration is the work of keeping every handoff between those partners in one of three states, requested, accepted or completed, with evidence the receiving partner owns, and with a named person responsible while a handoff is unresolved. A handoff is a transfer of responsibility. Sending a message starts one; only the partner’s acceptance moves it on.

Logistics orchestration in operational terms

Vendor definitions of logistics orchestration, or supply chain orchestration, talk about visibility, connectivity and end-to-end coordination. In operational terms it is narrower and harder: keeping one order’s commitments across several organisations visible and owned. Your supplier, your warehouse and your carrier each run their own system, and each is the authority on its own work. Orchestration does not replace those systems, and it is not a tracking feed laid over them. It is the coordinating process that holds the common reference for the order, records each partner’s acceptance and completion against it, and names who acts when a handoff sits unresolved.

Connecting systems moves information between them. Orchestration decides, for each handoff, what counts as accepted, what counts as done, and who is responsible in between. An integration can do the first without anyone having decided the second, which is how a team ends up with a link to every partner and still loses an order between two of them.

The handoffs on one order and their three states

A handoff is the transfer of a responsibility from one party to another. One distributor order that ships from a third-party warehouse has four of them. The supplier hands goods to the warehouse: goods sent, then goods received and accepted. The coordinator hands the pick to the warehouse: pick requested, pick accepted, pick complete. The coordinator hands the collection to the carrier: booking requested, booking confirmed, collection made. The carrier hands the goods to the customer: delivered, with proof of delivery. In each case one party owns the truth about the execution, and the coordinator can hold only that party’s evidence of it.

Each handoff sits in one of three states. Requested is what the coordinator has asked for and can prove it asked for: the sent request, with its time and the order reference it carried. Accepted is the partner’s own acknowledgement, carrying the partner’s reference: a booking number from the carrier, a receipt reference from the warehouse, a pick confirmation. Completed is the partner’s evidence that the physical work happened: the collection confirmation, the receipt with counted quantities, the signed proof of delivery.

The coordinator’s own record of having sent something is evidence of the first state only. It proves that a request left. It does not prove that the request arrived, that anyone read it, or that the partner agreed to do the work. A system that moves a handoff to accepted on the strength of its own send has confused its message log with the partner’s answer, and both afternoons in the opening come from that confusion.

Why a timeout is ambiguous

Suppose the coordinator sends a booking request and nothing comes back within the time it usually takes. There are two possibilities, and they look identical from the coordinator’s side. The request may never have arrived, because a portal was down or a message was rejected on the way in. Or the request arrived, the carrier accepted it and created a booking, and the acknowledgement was lost on its way back. In the first case there is no booking. In the second there is a booking the coordinator does not know about. The screen shows the same thing in both cases: a request sent, and no reply.

Each of the two natural responses is right in one case and wrong in the other. Sending the request again fixes the first case and, in the second, creates a second booking for the same pallets. Marking the booking done and moving on is fine in the second case and, in the first, leaves nothing booked while everyone downstream behaves as though something were. The coordinator cannot tell which case they are in by looking harder at their own records, because the missing information belongs to the carrier.

Treat the timeout as a business state with an owner and a clock. The partner may or may not have accepted, and someone has to find out. Recovery takes one of two forms. Where the partner allows a lookup by the common reference, check before acting: ask the carrier’s system what it holds against this order, then either attach the booking number you find or send the request again knowing that none exists. Where the partner offers no lookup, the request moves to confirmation pending with a named person, a time limit and a permitted next action, such as phoning the carrier or holding the collection instruction. A pending state that someone owns is a healthy state. An unowned pending state is where orders are lost. In either form, the instruction to the warehouse to release the pallets to a carrier goes out only once booking evidence is recorded.

One order, four handoffs, one afternoon

The order below is illustrative, and the carrier’s behaviour is a general pattern and describes no named carrier’s system. A distributor’s third-party warehouse confirms at 14:00 that three pallets for order 4471 are picked and ready. At 14:01 the coordinator requests a carrier booking for a 16:30 collection, quoting 4471. At 14:02 the request times out: no response, no booking number. The table follows the booking through the afternoon on three paths.

On the first two paths nothing on the coordinator’s screen distinguishes this afternoon from a good one. The carrier had accepted the first request as B123, so the retry creates a second collection that only the carrier can see, and the assume-success path leaves no booking that anyone can see. Both teams find out at the dock.

The designed path turns the timeout into a record with an owner and a limit. If this carrier allows lookup by reference, the process checks and attaches B123 without anyone lifting a phone. If it does not, at 14:30 the pending item is the first thing on Priya’s screen with “phone carrier” beside it. Either way the collection instruction goes to the warehouse only after B123 is recorded.

The same states sit on the other handoffs of order 4471. Upstream, the supplier’s despatch note, carrying the purchase order reference, is the request. There is no separate acceptance to record on this handoff; it stays requested until the warehouse’s receipt confirms what arrived, which may differ from what was sent, and that receipt is the only completion evidence the coordinator should hold. The pick request the coordinator sent to the warehouse is accepted when the warehouse acknowledges it with its own pick reference, and completed when the warehouse confirms three pallets ready, which is the 14:00 message this example started with. Real operations add several orders per collection, cut-off times, consolidation and returns; none of them change what counts as evidence.

Handoffs inside one warehouse, between its software layers and its equipment, including what to do when a confirmation never arrives, are covered in our guide to WMS, WES and WCS. What a shipment does to the customer’s remaining order, and why shipped is evidence of carrier handover rather than a status someone sets, is in our guide to order fulfilment software. Accepted versus received stock from a supplier is in our guide to procurement software.

One reference on every request

One order reference travels on every request. 4471 is on the pick request to the warehouse and on the booking request to the carrier, and the purchase order that brought the stock in ties the supplier’s despatch note to the same order. Each partner adds its own reference: the warehouse’s receipt and pick references, the carrier’s B123, the proof of delivery number. The coordinator keeps the mapping, so that a despatch note, a receipt, a pick confirmation, a booking and a proof of delivery can be tied back to one order without anyone searching an inbox. A retried request must carry the same reference as the original, so that a partner who did accept the first can recognise the second as the same job.

What each person sees and can say

The operator coordinating shipments sees, for each order, every handoff and its state, with the unresolved ones first and the permitted action beside each. For 4471 at 14:05 that is one line at the top: booking confirmation pending, owner Priya, limit 14:30, phone carrier. The customer-service colleague sees which promise to the customer rests on which handoff, and what state that handoff is in.

That view fixes what each of them can truthfully say. While the booking is requested or pending, the honest sentence is that collection has been asked for today, the carrier has not yet confirmed, and someone will know by 14:30. Once accepted, it is that collection is booked under B123 for 16:30. Once completed, it is that the goods were collected at 16:30 and are due tomorrow. On the assume-success path the colleague would have said “booked” at 14:03 with nothing behind it, and tomorrow’s promise would have rested on a state nobody had checked.

What to ask of any orchestration platform

Whether you are looking at an orchestration platform, a transport management system or an integration a developer proposes, the questions are the same, and they are about evidence. For each handoff, what does it record as acceptance, and where does that evidence come from: the partner’s own acknowledgement with the partner’s reference, or the system’s record that it sent something? What happens on a timeout: does it retry, does it mark the step done, or does it create a pending item with an owner? Can it look up a request by the order reference in the partner’s system, for the partners that allow it? Who is notified when a handoff has been pending past its limit, and what can that person do from the screen they are looking at? Can the release of the next step, such as the collection instruction to the warehouse, be made conditional on confirmed evidence from the previous one? And how does it represent a booking cancelled after acceptance, or a collection that took two of the three pallets?

Run the 14:02 timeout through any demonstration. If the answer is that the platform retries until something comes back, it moves messages and leaves the ownership of uncertainty with you.

When a simpler answer is enough

You may not need any of this. If you work with one carrier through a portal whose booking confirmation email arrives reliably, a written rule that nothing is collected without the booking number on the sheet does the job of the pending state, and a person reading their inbox does the job of the lookup. If a transport management system or your third-party warehouse’s own portal already handles booking confirmation and exceptions, and your team trusts what it shows, the work is to make sure the collection instruction waits for it. And if what your team lacks is knowing where a consignment is once it has been collected, that is a tracking-visibility problem, and a visibility product serves it better than an orchestration process would.

Where Keel fits

Keel is an operations platform shaped around how a business coordinates work with its partners. For the team in this example, the person coordinating shipments sees the three pallets confirmed ready, the requested collection and the missing confirmation together on one screen, with the permitted next action beside them. The business decides what counts as sufficient confirmation from each partner: a booking number from the carrier, a receipt reference from the warehouse, a phone confirmation recorded by a named person. It decides who may resolve an uncertain handoff and how long it may stay uncertain. The collection instruction cannot be released to the warehouse until that confirmation is recorded; the process applies the rule so nobody has to remember it. When a new carrier comes on that supports lookup by reference, the check and the screen change together: that carrier’s timeouts are checked by lookup, and the older carriers still route to a person.

Keel supports tailored operator tools, workflows that combine human steps with processing, and business rules expressed in code. An implementation of this example would have to design, build and test the connection to each partner’s system, the mapping between the order reference and each partner’s references, the lookup and retry behaviour for each carrier, the reconciliation of what the partner reports against what the coordinator recorded, and the escalation when a limit passes. A step recorded in a workflow is the coordinator’s record that it asked; it is not a guarantee that the carrier did something exactly once, which is why the partner’s own reference remains the evidence. Keel ships no carrier connections, no transport management module and no partner network. Keel leads the implementation and agrees the handover with your team.

Keel is not the answer in the three cases above: a transport management system or warehouse portal that already handles confirmation and exceptions and that your team trusts, a single stable carrier relationship that runs on a written rule and a confirmation email, or a problem that is about where goods are rather than who has accepted responsibility for them. Keel is the right conversation when the handoffs, the confirmation rules and the operator’s view of what is unresolved need to be your own, and need to keep changing as partners change while each partner keeps its own system.

If you would like to talk it through, bring one handoff where your team cannot currently tell whether a partner has accepted the work, with the references you use and the confirmation path you follow today. We can talk through which coordination responsibilities a Keel implementation should own and whether Keel fits.