Hand Over Open Dispatch Exceptions at Shift Change

1. Define the open-exception set

A dispatch shift change should not be a retelling of every job touched during the day. Its narrower purpose is to transfer decisions that are still capable of changing work after the outgoing dispatcher leaves. Include an item when it could alter a vehicle, driver, timing, loading window, load requirement, document position, or a commitment already communicated to another party.

Keep operational states separate. A vehicle can be allocated while driver acceptance is pending. A driver can accept while the vehicle fit is still uncertain. A document can be reported as available while its usable version has not been checked. Separating those facts makes uncertainty visible without turning it into blame.

Do not add closed history merely because it was inconvenient. A loading delay that ended and has no later effect can remain in the job history. A delay that threatens the next pickup, driver hours, vehicle allocation, or loading slot remains an open exception and belongs in the handover.

Source: BossFlow Fleet workflow scope

2. Make one record answer one decision

Create a compact exception entry for each decision that can be understood on its own. Identify the job reference first, then the affected vehicle, driver, load, or document where known. Describe the fact in neutral terms: “L-12 allocated; driver reply pending” gives the next dispatcher more to work with than “driver issue.”

Then write the decision being requested. “Document missing” is a symptom; the useful request may be to verify a version, seek a replacement, hold the allocation, or ask an operations owner to choose between alternatives. The incoming person should not have to infer the real question from a vague status.

Label reported information separately from information your team has checked. This is a practical note about confidence, not a judgment on the caller. It allows the accepting owner to see what can be acted on now and what should be verified before a further change is made.

3. Transfer exceptions in an explicit sequence

Review exceptions by likely operational effect rather than message arrival order. Start with decisions that could affect an imminent departure, a loading slot, driver availability, or another allocated job. Combine items only when they genuinely require one decision; separate them when different jobs, drivers, or owners can act independently.

For each record, the outgoing dispatcher states the current facts, the decision required, the proposed next action, the review point, and the proposed accepting owner. The incoming dispatcher checks the record, confirms whether the owner is appropriate, and explicitly accepts or declines it. Being present on a call or copied into a chat is not acceptance.

When no one can accept the item, leave it visible as unaccepted and use the team’s established escalation path. Do not mark it transferred simply because it was mentioned. A handover is more reliable when it shows the boundary between accepted work and work still awaiting an owner.

1. Sort by immediate operational effect.
2. State confirmed facts, reported facts, and the missing decision.
3. Propose one accepting owner for the next action.
4. Set a specific action and review point.
5. Record accepted, declined, or unaccepted—never assume silence means acceptance.

4. Choose a next action without pretending certainty

The accepting owner does not need to resolve every exception during the shift change. They do need to own a concrete next move. Examples include requesting a driver acceptance or decline, checking the stated vehicle requirement, verifying a document version, seeking an updated loading-window position, or asking the relevant operations owner to decide between options.

Avoid using “monitor” as the entire action. If monitoring is appropriate, note what will be monitored, who will check it, and when the record will be reopened. Likewise, “waiting for reply” should identify whose reply is needed and what decision follows if no reply is received by the review point.

Where the team’s normal recordkeeping permits it, keep declined allocations and changed assignments attached to the original job. Replacing a previous allocation without context can make a later dispatcher assume that the present arrangement was always intended. The aim is to preserve the decision trail, not to manufacture a clean-looking history.

5. Use a small desk-side decision table

The table below is a suggested triage aid, not a claim that one universal fleet procedure fits every operation. Use it alongside the team’s actual job records and existing escalation arrangements. Its value is modest but useful: it prompts both dispatchers to make the next decision, owner, and uncertainty visible rather than relying on colour labels or memory.

6. Fictional worked example: Northline Components

This is a clearly fictional example. At 18:40, the outgoing dispatcher at Northline Components reviews job FC-218, a factory collection planned for the following morning. Lorry L-12 is allocated, but the driver has not responded. A supervisor says L-12 may be needed for an earlier return load; this is reported information, not a confirmed reassignment. The loading note also refers to a document version the dispatcher cannot yet view.

The outgoing dispatcher opens three linked but separate decisions: obtain the L-12 driver response; confirm whether the earlier return load will use L-12; and verify the relevant document version. Mei, the incoming dispatcher, explicitly accepts the driver-response and document-verification actions. She does not accept the vehicle-conflict decision because the night operations lead is the proposed decision owner under this fictional team arrangement.

The record shows Mei’s two accepted actions, the proposed night-operations owner for the vehicle decision, and an unaccepted state until that owner confirms. Mei sets a 19:00 review point for the driver response and document check. Nothing in this example says the collection will proceed; it only makes the remaining choices and ownership clear.

7. Close with an acceptance check

Before ending the handover, scan only the open-exception set. Each item should show one current state, one next action, one review point, and either a named accepting owner or an explicit unaccepted state. Confirm that refusals, reassignments, and changed instructions remain connected to the original job.

The incoming dispatcher should be able to answer four questions without reopening unrelated chats: What could still change this job? What is confirmed? What must happen next? Who has accepted each remaining decision? If those answers are unavailable, a long shift summary has not completed the handover.

This method deliberately stops at the transfer of open dispatch decisions. It does not determine full vehicle readiness, approve freight documentation, replace maintenance processes, evaluate route choices, review trip costs, or promise a dispatch outcome. The existing AI conceptual fleet-yard illustration may be reused only as an illustrative image, not as evidence of an actual fleet or result.

Source: GOV.UK: writing user stories