A driver reports a blocked entrance, the dispatcher forwards the message and the customer still expects the original delivery time. Information exists, but no decision has been made. The transport operations manager needs an exception queue showing ownership, order impact and the next action. The hypothetical journey below supports a proposed operating model. It defines responsibilities and checks, rather than universal response times.
Separate the signal from the operating decision
In this hypothetical example, a vehicle carries six pallets to a store. At 09:10 the driver reports that the agreed entrance is blocked; the receiving window ends at 10:00. The TMS holds the order and consignee contact, telematics shows the vehicle position and WMS has confirmed dispatch. None of these sources alone establishes whether another entrance is usable or whether receiving can still finish in time.
Create a work item linked to the trip, stop, obstacle type and initial evidence. In this proposed model, detection time, registration time and work acceptance time are separate fields. The dispatcher accepts the assignment, verifies the contact and identifies the next step. Automatically assigning a task to a group does not establish that someone has started handling it.
GS1 EPCIS distinguishes event time from repository record time. That distinction is useful for the queue too: a message can arrive after the obstacle occurred. Our operating model does not require an EPCIS implementation. It uses the separation of times to keep a delayed report from looking like a new event or concealing elapsed time.
Sources: [1]
Give the owner authority and an escalation route
The dispatcher checks an alternative entrance with the consignee. If this changes neither the contractual promise nor the price, they can act within approved authority. If a new window or paid waiting time is needed, route the task to the person authorised to approve that particular change. The handoff includes options, consequences, the required decision and the time after which an option is no longer useful.
For the example, the team sets the next review for 09:25. This is an illustrative working deadline, not an industry standard. If no decision exists at that time, the system alerts the duty manager. The original customer commitment ending at 10:00 does not move automatically. Retain the forecast, any newly agreed window and the person who informed the customer as distinct records.
A pause needs a reason, an owner for the awaited response and a review time. Waiting for a customer does not remove delivery risk or stop every clock. Specify which internal deadlines use a working calendar and which use elapsed time. At shift change, require acceptance of open work; unaccepted tasks return to the shift manager.
Collect evidence without multiplying work items
Telematics, a driver message and a customer call may describe the same obstacle. Associate them with the existing task using the trip, stop and problem type, while keeping conflicting observations visible. Do not automatically merge different damage events or addresses merely because they occurred close together. A signal received after closure needs classification as a delayed record or a new problem.
OpenAPI describes an HTTP API contract, including requests and responses. The task integration contract also needs business rules: a stable message identifier, change version, allowed transitions and repeat handling. An API description alone does not determine who can approve a delivery change. The process owner defines that authority for the team to implement and test.
Provide a controlled fallback log for TMS outages, with a local identifier and owner. After recovery, reconcile it against the queue and ask the dispatcher to resolve uncertain matches. Retain the original signal, verification result, selected action and closure evidence. Technical message delivery must not automatically close the operational work item.
↔ Scroll the table horizontally
| State | Owner | Check |
|---|---|---|
| Signal registered | Duty dispatcher | Accept or transfer the work |
| Approval required | Authorised manager | Decision and validity period |
| Obstacle removed | Dispatcher | Recovery evidence and communication |
| Additional charge remains disputed | Finance manager | Separate cost decision |
Sources: [2]
Close the consequence and test the queue
In the example, the consignee confirms another entrance, the vehicle arrives and receiving finishes within the agreed window. The dispatcher checks the receiving event and document before closing the obstacle. If waiting charges arose, finance continues reviewing them in a separate linked task. Operational closure therefore preserves visibility of the open financial consequence without holding up a delivery that has recovered.
The acceptance test should reproduce a repeated signal, an unaccepted assignment, a missed deadline, a dispatcher handover and a document arriving late. Verify that the customer receives only the current approved message and that a new change does not erase the original promise. Retain test identifiers and transition history. The shift manager accepts the result after checking the queue under their actual working role.
Monitor unaccepted tasks as a share of all currently open tasks. Age for an unreviewed item equals current time minus registration time; remove it from this sample after its first substantive review. Count reopenings by reason for each completed shift. Use transition history as the source and make the shift manager accountable. Refresh the share on task changes, age every minute and reopening counts after each shift. This is a proposed monitoring cadence. Establish thresholds after measuring the operation; a breach should trigger investigation of workload and authority.
Action checklist
- Define the exception key and the rules for attaching repeated signals.
- Name the decision owner, deputy and method of accepting responsibility.
- Separate next action deadlines, forecasts and agreed customer commitments.
- Test fallback logging, recovery and closure evidence on a hypothetical trip.
Questions and answers
Can the operational chat remain in use?
The chat can remain a reporting channel. Attach its message to the work item that retains the owner, deadline, decision and outcome. That work item becomes the control record.
Who decides whether to notify the customer?
The process owner defines notification conditions and the authorised role. The dispatcher prepares verified facts and a proposed action; an unapproved forecast should not be presented as a new commitment.