Keep Driver Reassignment Clear After Job Acceptance

1. Start with the job, not the replacement message

When an accepted passenger job needs another driver, begin with the existing job record. Do not create a second job merely because a new driver is being considered. The job still describes the same passenger movement: its pickup, destination, time window, passenger requirements, and operating notes. What has changed is the allocation decision.

Give the job a stable reference that the dispatcher, driver, and shift handover can recognise. Under that job, keep an allocation history. Each allocation should show the proposed vehicle and driver, the time it was made, the person who made it, its response, and any stated reason for change. A short message thread may support the record, but it should not become the only explanation of responsibility.

This matters most after acceptance. “Assigned” only says that an instruction was issued. “Accepted” says that the named driver responded positively to that particular instruction. If the original driver later becomes unavailable, their earlier acceptance remains part of the history; it does not prove that the replacement driver accepted anything.

Source: BossFlow Fleet workflow scope

2. Separate the four decisions that otherwise blur together

A clean reassignment record distinguishes four decisions. First, the original dispatcher allocated the job. Second, the original driver accepted or declined that allocation. Third, operations recorded that the original plan could no longer proceed. Fourth, a new instruction was issued and the replacement driver responded to it.

Use precise statuses rather than a single vague label such as “changed.” A practical sequence is: allocation issued; driver response recorded; allocation cancelled or withdrawn; replacement allocation issued; replacement response recorded. The cancellation is attached to the old allocation, while the new acceptance is attached to the new allocation.

Do not mark the whole job cancelled if the passenger movement is still intended to proceed. Equally, do not mark the job accepted merely because the first driver accepted earlier. The current execution position should be visible separately from the full history: for example, “replacement awaiting response” or “replacement accepted.”

3. Follow a concrete field sequence

Use this sequence when the original driver becomes unavailable after accepting the job. First, confirm the job reference and identify the exact accepted allocation. Second, record the unavailability as an operational note with a named recorder and time; avoid guessing at reasons that have not been supplied. Third, change that allocation to cancelled or withdrawn, without deleting its acceptance.

Fourth, check the replacement candidate against the job’s stated requirements: passenger capacity, vehicle suitability, relevant time window, existing assignment conflicts, and driver availability. This check is a dispatch decision, not evidence that the driver has accepted. Fifth, issue a new instruction that identifies the same job reference and clearly says it is a replacement allocation. Sixth, wait for and record the replacement driver’s explicit response.

Seventh, update the current job view only after that response: accepted if the replacement accepts, declined if the replacement declines, or awaiting response if no response is yet recorded. Eighth, give any unresolved exception a named owner and next action. This keeps a shift change from turning an open decision into an assumed handoff.

1. Five-item reassignment checklist:
2. 1. Confirm the existing job reference and original accepted allocation.
3. 2. Record the original driver’s unavailability without erasing the response history.
4. 3. Cancel or withdraw that allocation, with recorder, time, and available reason.
5. 4. Issue a distinct replacement instruction after checking stated job needs.
6. 5. Record the replacement driver’s explicit accept, decline, or pending response.

4. Use a small decision table at the dispatch desk

The table is not a substitute for judgment. It helps the dispatcher avoid changing a status before the underlying event has been recorded. Use the wording that matches what is actually known at the time.

5. Keep the record useful for people, not just statuses

For each allocation attempt, record only the operational facts needed to understand responsibility: job reference, allocation identifier, proposed driver and vehicle, issuer, issue time, response time if any, response, status, and a concise change note. A free-text note should clarify the event, not replace the structured fields.

A cancellation note can say “original driver reported unavailable; replacement required,” if that is the known fact. It should not state an unsupported cause, promise a passenger outcome, or turn an operational note into a personnel judgment. Where a passenger-facing update is needed, keep it separate from the dispatch provenance record; this guide is about knowing who accepted the work internally.

At handover, the receiving dispatcher should be able to answer three questions quickly: Which allocation was accepted first? Why is it no longer current? Which driver, if any, has accepted the latest instruction? If the last answer is not clear, the job remains an open exception rather than a completed reassignment.

6. Fictional worked example: Harbour Link Transfer

Illustrative fictional example only: Job PT-204 is a passenger transfer with a stated morning pickup window. Dispatcher Mira assigns Driver Asha and Vehicle MPV-12. Asha explicitly accepts allocation A1. Later, Mira records that Asha is unavailable to proceed. Allocation A1 is marked cancelled, while its earlier acceptance remains visible in the history.

Mira checks a possible replacement, Driver Ken with Vehicle MPV-08, against the stated passenger requirement and time window. She issues allocation A2 for the same job reference and labels it as a replacement. At this point, the job is not “accepted by Ken”; it is “replacement awaiting response.” Ken then replies that he accepts A2. Mira records the response time and changes A2 to accepted.

The current view now identifies Ken and MPV-08 as the accepted operational instruction. The historical view still shows Asha’s accepted A1 and its subsequent cancellation. If Ken had declined, A2 would show declined and the job would remain open for another allocation. This example is fictional and does not describe a real passenger, fleet, timing, service result, payment, or outcome.

7. Close the reassignment only when the current instruction is clear

Before treating reassignment as complete, review the current allocation rather than merely the activity log. It should name one current driver, one current vehicle where the job requires it, one explicit driver response, and any remaining exception owner. If a vehicle changes after driver acceptance, record whether the change requires a fresh instruction or confirmation according to the team’s own operating rules; do not silently assume the earlier acceptance covers every later change.

The reused AI conceptual fleet illustration should be labelled: “Illustrative AI concept: passenger fleet dispatch handoff; not an actual customer fleet or live job record.” It can orient readers to the dispatch context but is not evidence of availability, tracking, passenger status, or service performance.

This narrow discipline makes the next decision reviewable. It does not guarantee that a journey will proceed, solve driver-payment reconciliation, or replace route planning. It simply preserves the operational distinction between an allocation that stopped and the later instruction that was actually accepted.

Source: GOV.UK: writing user stories