Handle a Receiving Window Change Before Dispatch

1. Treat the changed window as an exception to one job

A changed receiving window does not automatically create a new dispatch job. Open the existing job record and preserve the original planned receiving window, the assignment already made, and the status reached so far. Add the new information as a dated change event. This retains the context for why a lorry, driver, loading position, or sequence was selected.

Record only what is known: who supplied the revised window, how it was confirmed, the stated start and end time where available, when confirmation was received, and any limit or unanswered question. A message reference, call note, email reference, or receiving-party contact can support the record, but the note should distinguish confirmed facts from assumptions.

The question is deliberately narrow: can the planned movement still proceed under the changed receiving window? Do not restart a full review of the load, vehicle, documents, or readiness items unless this change reveals a specific related exception. The existing readiness record remains the basis; this is one attached decision point.

Source: BossFlow Fleet workflow scope

2. Capture a usable confirmation before asking for a decision

A message such as “later is acceptable” is not yet a usable field instruction. Convert it into a record another dispatcher can understand without entering the original conversation. Include the job identifier, receiving location or receiving party already on the job, prior window, proposed or confirmed replacement window, and source of confirmation.

If the receiving side gives a broad statement rather than a precise interval, state that limitation plainly. For example: “Receiving contact indicated that a later arrival may be considered; no latest receiving time was stated.” Do not turn ambiguity into a firm arrival instruction. The decision owner can decide whether clarification is needed or whether the job should be held.

Keep the original window visible beside the replacement. A later reader must be able to see that the instruction changed rather than assume the first plan never existed. This matters when a driver has already received an earlier update or when a shift handover occurs before departure.

3. Name one decision owner and make the decision explicit

The person who receives a change is not necessarily the person who decides its operational effect. Name one current decision owner, such as the dispatcher, transport supervisor, warehouse operations owner, or another role used by the business. Record the actual person or role with authority rather than implying authority through a vague status.

The owner records one immediate outcome: proceed with the current assignment, hold departure while a fact is clarified, revise the driver instruction, or reopen allocation because the new window conflicts with the current plan. A decision may remain pending, but pending needs an owner and a next check. “Noted” does not tell a driver or the next dispatcher what happens next.

Keep receiving-party confirmation separate from the internal decision. The external confirmation records what the receiving side stated. The internal decision records what the fleet will do. This prevents a revised window from being mistaken for automatic approval to depart.

4. Follow a field sequence before updating the driver

Use a short sequence. First, attach the change to the existing job. Second, check whether the new window conflicts with the assigned vehicle, driver, loading position, or another recorded commitment. Third, place the decision with the named owner. Fourth, record the outcome and decision time. Fifth, send or confirm one current instruction to the driver.

The instruction should be action-led and version-aware. Identify the job; state whether the driver should proceed, hold, or await another update; give the applicable receiving window or next confirmation point; and identify who handles a new exception. The driver should not have to infer which chat message overrides an earlier message.

If no decision exists yet, say so accurately. “Hold departure; dispatch will update after receiving-time clarification” is clearer than forwarding an uncertain message. Do not state a departure, arrival, loading, acceptance, or allocation result that has not been recorded.

5. Desk-side decision table

Use the table as a prompt rather than an automatic rule. The named decision owner still reviews job-specific facts and records the result against the existing job.

6. Fictional example / 虚构示例

Fictional example / 虚构示例: Meridian Parts has a planned lorry job to a receiving site. Before dispatch, the receiving contact confirms that the original window has changed to a later stated interval. The dispatcher adds the confirmation time, source, original window, and revised window to the same job record. No new job is created.

The dispatch supervisor is named as decision owner because revised timing may affect another allocated movement. The supervisor checks the existing assignment and records: “Hold departure while the loading slot and revised receiving interval are compared; next check owned by the dispatch supervisor.” The driver receives one current instruction: “Job remains active. Do not depart yet. Await dispatch update.”

The owner can later record a revised proceed instruction or a reason to reopen allocation. This example is fictional. It does not state a real route, company, person, timetable, service result, or outcome. It demonstrates record sequence only and does not predict what a fleet should decide.

7. Five-item close check and narrow differentiation

Close this exception only when a person on the next shift can obtain a dependable operational answer from the job record. This guide is intentionally smaller than freight readiness. It does not certify the load, vehicle, documents, driver availability, or site conditions; those remain in their relevant records if review is needed.

The existing AI conceptual fleet illustration may be reused and labelled: “Illustrative AI concept: freight readiness discussion before dispatch; not an actual customer fleet.” It is contextual imagery only. It does not evidence a vehicle, route, receiving site, decision, or operational result.

1. The original receiving window remains visible and revised information is attached to the same job.
2. The confirmation source, time received, and any remaining uncertainty are recorded.
3. One current decision owner is named.
4. The recorded outcome says proceed, hold, revise, or reopen allocation, with a next action where needed.
5. The driver has one current instruction that does not conflict with an earlier message.

Source: GOV.UK: writing user stories