A message proposing another destination is evidence of a request, not authority to replace the approved delivery instruction.
1. Keep the original instruction visible
A delivery-address change starts as a request against one existing freight job. Do not overwrite the original approved address when a dispatcher receives a call, email, chat message, or note from a driver. Preserve the job reference, original address, proposed address, request source, and the time the request was received. The purpose is modest: a later reviewer should be able to see what instruction existed before the exception appeared.
Treat the message as evidence that somebody asked for a change, not evidence that the request is authorised. A revised address is also not delivery completion evidence. Keep the current approved instruction visibly separate from the proposed replacement so the assigned dispatch team knows which version it may presently rely on.
Source: BossFlow Fleet workflow scope
2. Use a concrete review sequence
| Observed record state | Suggested internal action | Instruction dispatch may use |
|---|---|---|
| Request message received; owner unknown | Hold the exception and identify the owner | Original approved destination |
| Owner identified; confirmation unresolved | Record the condition and seek stated evidence | Original approved destination |
| Owner approves replacement clearly | Link the new authorised instruction | Recorded replacement destination |
| Owner declines the request clearly | Retain the request and decision history | Original approved destination |
| Evidence conflicts or is incomplete | Hold, name the next action, avoid inference | Original approved destination |
Use this suggested internal sequence: first, identify the single freight job and its current approved destination. Second, capture the proposed destination exactly enough to distinguish it from the original. Third, record who made the request, through which source, and when. Fourth, name the authorised decision owner for this job. Fifth, seek recipient or site confirmation where the team’s own operating arrangement requires it. Sixth, list affected instructions or documents. Seventh, record an authorised outcome: approved, declined, or held pending a stated condition.
Do not use a status such as “changed” when the evidence only supports “request received.” If an owner has not decided, the usable instruction remains the original approved address. If details conflict or the decision owner cannot be identified, mark the exception held and give the unresolved condition a named next action.
- Identify the job and preserve its approved destination.
- Capture the proposed destination and request evidence.
- Name the authorised decision owner for this exception.
- Record confirmation, affected records, and unresolved conditions.
- State which instruction dispatch may currently rely on.
3. Suggested internal change worksheet
The following is an adaptable suggested internal worksheet, not a carrier requirement, a universal freight standard, a Malaysia service rule, or a legal obligation. It helps a dispatch desk make the boundary visible: job and destination reference; original approved address; proposed address; request source and received time; authorised decision owner; recipient or site confirmation; affected instructions and documents; dispatch acknowledgement; decision time; and unresolved conditions.
A worksheet entry should distinguish a factual observation from a conclusion. For example, “site contact replied with the proposed address” records an observation. “Destination approved” requires the decision owner’s recorded outcome. The worksheet does not decide whether a destination is suitable, available, or completed; it only keeps the request and decision trail legible.
4. Decide from the evidence available
Use the decision table as a desk-side prompt. It is suggested internal practice, not a rule imposed by any carrier or source. A response can support a specific next record without supporting a broader conclusion. When uncertainty remains, record the hold rather than filling the gap with an assumption.
5. Fictional example / 虚构示例
Fictional example only: Job FL-208 is recorded with an approved delivery destination called North Quay Receiving. At 09:20, a chat message attributed to a customer contact proposes East Quay Annex instead. The dispatcher attaches the message reference to the exception record, retains North Quay Receiving as the current approved instruction, and records the proposed address separately.
The assigned decision owner has not yet recorded an outcome. A site acknowledgement is still unresolved, and an internal delivery note would need review if an approval is later recorded. The dispatcher marks the request “held pending owner decision and stated confirmation.” The dispatch team may rely on North Quay Receiving for the existing job instruction; it may not treat the proposed address as approved. This fictional example contains no real customer, carrier, route, timing, result, or service claim.
6. Close the address exception carefully
Before closing the exception, complete this five-item suggested internal check: the original address remains retrievable; the proposed address is linked to the same job; the decision owner and outcome are recorded; affected instructions or documents have a visible review state; and the assigned dispatch team has acknowledged the instruction it may rely on. If any item is unresolved, close neither the exception nor the broader job merely because a message was received.
An approved replacement should be recorded as a new authorised instruction linked to the original, rather than as invisible substitution. A declined request remains useful history. A held request should show what is missing and who owns the next action. None of these records establishes that a vehicle moved, that a site received goods, or that delivery was completed.
7. Narrow differentiation and illustrative image
This guide concerns one narrow dispatch decision: whether a proposed delivery destination may replace the approved destination for one freight job. It is distinct from changing a receiving window at the same site, correcting a document reference, assigning another driver, recording a vehicle movement, or reviewing proof of delivery. Keeping these decisions separate prevents a single address message from silently changing unrelated job facts.
Image label: AI concept illustration — fleet yard and dispatch setting; illustrative only, not an actual customer fleet. The supplied BossFlow Fleet workflow page describes keeping vehicle, driver, and job connected while separating assignment, acceptance, execution, and completion states. That context does not make this worksheet a carrier standard. The supplied GOV.UK page supports using observable outcomes as checklist material; it does not set a freight operating standard or promise an outcome.
Source: GOV.UK: writing user stories
Try the decision with fictional records
The demonstration runs independently. It does not connect to customer data, real dispatches, payments or the original project backends.
Open the matching demoExplore the full workflow
