Hand over unresolved logistics exceptions when the control-tower shift changes

Why logistics exceptions go dark for four hours after the 14:00 IST shift change

In a 24×7 transport and warehouse control tower, the highest risk of service failure occurs during the thirty minutes around shift change (06:00, 14:00 and 22:00 IST). At 13:40 IST, a morning-shift analyst is tracking a broken-down linehaul truck near Nashik, waiting for a regional broker to confirm a relief vehicle number, and waiting for a customer planner in Bengaluru to approve an evening unloading extension. At 14:00 IST, the outgoing analyst pastes five bullet points into a team chat channel and logs off.

The incoming afternoon analyst opens fifty active trips on the dashboard, reads the chat message as "Nashik breakdown being handled by broker", and assumes the relief vehicle is already on the way. Nobody calls the broker back at 14:30 IST. By 18:00 IST, the relief truck has still not arrived, the customer's receiving dock has closed for the night, and a recoverable four-hour delay has turned into a next-day SLA failure and detention dispute.

A chat message or a shared spreadsheet row is a broadcast notification, not a completed transfer of operational ownership. Handing over unresolved exceptions reliably requires linking the shift roster—structured around defined shift windows and handover overlaps as in Frappe HR — Shift Type—to an explicit exception state machine where each open item is accepted by an incoming owner or escalated to the shift lead.

Capture four fields that separate a real handover from a vague status note

Whether your control tower uses a dedicated TMS exception workbench or a structured ticketing queue, every unresolved exception at shift cutoff should display four distinct fields:

1. Current verified event and disposition state: What is the last verified physical fact and timestamp—using unambiguous step and disposition semantics aligned with GS1 — EPCIS and CBV Artefacts—as opposed to unverified verbal promises? (For example: Vehicle MH-04-xx-1122 halted at Km 142 since 11:15 IST; disposition: in_transit_delayed; cargo seal intact).
2. Decision state and commercial boundary: Has a recovery plan already been approved within policy, or is a commercial/customer decision still pending (such as approving a ₹6,000 spot transhipment cost or revising a customer delivery promise)?
3. Specific next action and exact follow-up timestamp: Not "Follow up with transporter", but "Call Broker Sharma by 14:30 IST to verify relief vehicle RC number and gate-in ETA at breakdown point."
4. Outgoing owner -> Incoming owner acceptance state: Pending Handover -> Accepted by Incoming Analyst [Name] at [Timestamp] or Escalated to Shift Lead.

If an AI summariser is used to draft the shift handover brief from morning call logs and ticket notes—following the human-review controls in the NIST — AI 600-1 Generative AI Profile—the outgoing analyst must review and sign off the summary before handover so no hallucinated confirmation ("relief vehicle confirmed") is passed to the next shift.

Illustrative example: reconciling 25 open control-tower exceptions at the 14:00 IST shift handover

Consider a national freight control tower executing its 13:45–14:15 IST shift handover protocol across 25 open shipment exceptions active at the end of the morning shift. Rather than dumping all 25 rows into an email, the handover workbench groups the exceptions into three action tiers and requires explicit sign-off before the morning shift closes.

The handover ledger reconciles all 25 open exceptions cleanly:

• 14 exceptions (56.0%) already have a confirmed recovery path and transfer smoothly to incoming analysts for milestone verification.
• 7 exceptions (28.0%) are mid-conversation (waiting on a broker or consignee callback) and transfer with an explicit Next Action Timestamp so the incoming analyst picks up the phone on time.
• 4 critical overdue exceptions (16.0%) cannot simply be passed sideways from one junior analyst to another because they lack a viable recovery vehicle or require commercial/customer escalation; the handover gate routes these 4 directly to the Shift Lead during the 15-minute overlap huddle (14 + 7 + 4 = 25).

Prevent the "silent ticket dump" in the final fifteen minutes of a shift

Any experienced control-tower manager knows the "13:55 IST ticket dump": an outgoing analyst updates seven tickets at 13:55 IST with the note "Called driver, phone switched off, next shift to check" just to clear their personal SLA timer before clocking out.

Stop this anti-pattern with two simple workflow rules:

1. Freeze unilateral handover transfers 15 minutes before shift end unless co-signed: Any exception whose follow-up timer expired during the outgoing shift cannot be marked Handed Over — Normal; it automatically enters Cohort 3 (Overdue at Handover) and appears on the Shift Lead's overlap review screen.
2. Distinguish "Notification Sent" from "Ownership Accepted": Reassigning the owner_id field in a database does not mean the incoming analyst has seen the ticket. Keep the exception highlighted in Handover Pending Acceptance until the incoming analyst clicks Accept Ownership during the overlap window.

Measure handover leakage as a core control-tower metric

To see whether your shift handover process is working, track three operational metrics weekly:

• Orphan latency after shift change: Average time between shift start (14:00 IST) and the first outbound action taken on Cohort 2 (Pending Callback) exceptions handed over from the prior shift.
• Repeat-handover count (Bounce Count): Exceptions that are handed across three or more consecutive shifts (Morning -> Afternoon -> Night -> Morning) without a change in decision state or escalation tier. Any exception crossing two shift changes without resolution should auto-escalate to operations management.
• Post-handover evidence contradiction rate: Cases where an outgoing note recorded an action as "confirmed" without an attached vehicle number, gate timestamp or written customer approval.

Next actions

1. Schedule a formal 15-minute overlap window at every control-tower shift change (06:00, 14:00, 22:00 IST) dedicated strictly to exception handover acceptance.
2. Replace free-text chat handovers with a four-field exception card: verified state/timestamp, decision status, specific next action with deadline, and incoming owner acceptance.
3. Configure your exception queue to flag any ticket handed across two consecutive shifts without progress and escalate it automatically to the Shift Lead.
4. Audit one week of missed-SLA shipments to check how many experienced a multi-hour action gap immediately following a shift change.