The operator who was working the booking change is on leave from tomorrow. The cargo-ready date slipped on Monday, the amendment was submitted on Tuesday, and the carrier’s revised confirmation has not arrived. Someone else now owns the file, the customer expects an update by Friday, and the deadline for shipping instructions sits somewhere in between. Before anyone logs off, the question that matters is not whether the amendment was handled well — it is whether the next person can pick it up without starting again.

This article answers that question: when a booking change is still open at handover, what should the outgoing operator leave behind so the incoming one can act, not reconstruct?

Why handovers are where open changes get lost

A booking amendment in progress is a strange kind of work-in-progress. Nothing about it is physical: the request is a submitted form, the approval is a message, the expected return is a document that has not been issued yet. The only place the whole state exists is in the head of the operator working it, plus whatever fragments landed in an inbox, a portal and a spreadsheet.

Maersk’s support guidance illustrates the shape of the problem. An amendment is submitted through the hub — shipment number, Amend, original details pre-filled, changes submitted on the review page — and the revised booking confirmation is issued only once the change is confirmed. Between submission and that confirmation, the file’s true state is “requested, not yet confirmed”. If the outgoing operator’s handover note says “dates moved to the 12th” without saying which of those two steps it reflects, the incoming operator inherits an ambiguity they cannot resolve without re-reading everything. The booking confirmation itself is recoverable — Maersk’s guidance describes downloading it as a PDF from the shipment’s Documents tab — but only the revision that exists, not the one still being processed.

Multiply that across a shift change, a sickness absence or a departure, and you get the pattern every forwarding office recognises: the incoming operator re-does two hours of discovery work, or skips it and tells the customer something the record does not support. Neither failure is a competence problem. Both are information problems.

The handover state, in five items

What the incoming operator needs fits in five items, and each is a fact, not an opinion:

  1. The current booking state. Which revision of the booking confirmation the file stands on, and whether any amendment is submitted-but-unconfirmed. “Requested Tuesday, no revised confirmation yet” is a state. “Should be sorted” is not.
  2. The approved values. What the approver agreed to, specifically: the new dates, the equipment, and any cost basis. Our booking amendment tracking article describes the four artefacts — request, approval, returned confirmation, field-by-field check — and a handover is simply those artefacts plus their open status.
  3. The open actions, each with a deadline and an owner. Shipping instructions, equipment collection, customer update. An open action without a named owner after handover has no owner at all.
  4. The evidence pointers. Where the request, the approval and any carrier correspondence actually are — the portal reference, the case number, the message thread — not “in my inbox”.
  5. What has been told to the customer, and when the next contact is due. This is the item most often missed. An incoming operator who re-sends an update, or contradicts one already sent, undoes whatever confidence the previous one built.

The fourth item deserves a note. Different change types travel through different channels — some online, some through case-managed requests with attachments — so “where the evidence lives” is genuinely different per change. The handover has to name the place, not gesture at the systems.

Where assistance fits, and where it must stop

This is also a place where AI assistance earns its keep, because the handover state can be assembled rather than remembered. The raw inputs already exist: the request, the approval message, the submitted amendment, any returned documents. An assistant that gathers those into the five-item state — surfacing the unconfirmed amendment, listing open actions with their deadlines, quoting the last customer update — turns an hour of discovery into minutes of review.

Platform vendors document capabilities in exactly this territory. CargoWise, for example, describes workflow templates configured by mode, lane or customer, task assignments with clear ownership so “your teams know exactly what’s due, who owns it, and what comes next”, and configurable alerts and exception logs for responding to deviations. Those are the vendor’s own descriptions of its forwarding platform, not evidence of any deployment. The structural point stands regardless of the tool: when ownership and status live in the system rather than in a person, handover becomes a lookup.

What the assistant must not do is decide. Whether the incoming operator accepts a partial confirmation, chases the carrier or re-briefs the customer is a judgement about commercial risk, and the human taking ownership has to make it. The useful division is consistent with how we describe evaluating AI in freight forwarding: assemble, compare and flag; approve and close with a person.

A handover that held

Example. A cargo-ready date slip on booking EX-003: original readiness 8 November, supplier moved it to 12 November, one 40HC, nothing collected. The operator submitted the sailing amendment Tuesday afternoon and left Wednesday. Her handover note read: revision 2 stands, amendment requested Tuesday 14:10 for the 14 November sailing, approval from the customer covers the new sailing with freight unchanged, revised confirmation not yet issued, SI deadline Friday 12:00, customer last told “we will confirm the new sailing by Thursday”. The incoming operator’s first act was to check for the revised confirmation and run the amended confirmation check against the approved values before Thursday’s customer contact — the same discipline our article on checking before you update the customer describes. No discovery work, no duplicated messages, no guessed dates.

The note took four minutes to write. The alternative costs an hour every time a file changes hands — and files change hands constantly.

Make the handover the record

The deeper shift is to stop treating handover as a conversation and start treating it as the file’s state, written down. The five-item state above is worth keeping even when nobody is leaving: it is the same record that answers a charge query months later, the same source a reliable customer status update is built from, and the same evidence trail our ocean booking rescheduling workflow is designed around. A team that writes the state at every handover gets the audit trail as a by-product.

If open booking changes are surviving only in your operators’ heads at shift changes and absences, that is a workflow we can review with you. We can take one of your recent handovers of an open booking change, trace it through the five items, and show you where the state breaks and what would hold it together in your operation. Let’s talk and we will start with that file.