Keep a Cancelled Freight Job Separate from the Vehicle Movement

1. Start with one freight job and six separate facts

A cancellation received after dispatch is an exception within the original freight job, not a reason to delete that job or replace its history. Begin from the existing job reference. Keep the customer’s request separate from the record of dispatch, the current vehicle situation, and any goods event. A message saying that the customer wishes to cancel may be important, but it does not by itself establish whether collection occurred, whether goods are on board, or whether a later vehicle movement is authorised.

Create six labelled entries as suggested internal practice: cancellation request; verified customer instruction; dispatcher decision; current vehicle and goods situation; driver acknowledgement; and operational outcome. Give each entry a time, source or observer, and named owner where known. “Unknown” is a usable state. It is more accurate than filling a gap with an assumed return, delivery, collection, or release decision.

This guide is about a cancellation after dispatch. It is not an empty-vehicle repositioning instruction, a no-load pickup, a driver reassignment, a receiving-window change, or a delivery-proof discrepancy. Those events may arise around the same job, but they answer different operational questions and should remain separately labelled.

Source: BossFlow Fleet workflow scope

2. Preserve observable history before deciding what changes

First preserve what can be observed without making a conclusion. Record the original job reference, assigned vehicle and driver, the dispatch event already recorded, the cancellation message or call reference, its stated sender, and its received time. Record the last known vehicle update and the last known goods state exactly as available. A dispatch record remains history even if the customer later asks to cancel.

Then distinguish a request from verification. The dispatcher, or another named operations owner under the team’s internal arrangement, should verify which instruction is current when that point is unclear. Suggested verification may compare the identity or agreed contact route of the instruction source with the job record, capture any clarified wording, and record what remains unknown. It should not turn a partial message into a conclusion about goods, authorisation, or responsibility.

The supplied Fleet workflow material supports keeping the job, vehicle and driver connected, and separating assignment from acceptance and completion from later review. Its examples describe a workflow scope; they do not prescribe a cancellation procedure. The worksheet below is an original, adaptable internal proposal. It is not a carrier requirement, universal industry standard, Malaysia service rule, or legal obligation.

3. Follow the decision sequence before a new movement

Use this desk sequence in order. First, pause any unconfirmed next instruction in the job record; do not erase the prior dispatch. Second, log the cancellation request verbatim enough to preserve its operational meaning. Third, identify the person who must resolve an unknown instruction state before any new movement is authorised: the named dispatcher or designated operations decision owner. Fourth, obtain or record the latest available vehicle and goods situation. Fifth, ask for driver acknowledgement of the current instruction or of the fact that it remains pending.

Sixth, the decision owner records one explicit outcome that the available information supports: cancellation verified and next instruction recorded; cancellation request not yet verified and instruction state remains unknown; cancellation request withdrawn or superseded with the current instruction recorded; or another bounded outcome stated without guessing. Seventh, communicate only the current recorded instruction to the driver and retain acknowledgement where available. Eighth, add later movement or goods evidence as new events, rather than editing earlier facts to make the timeline look simpler.

The decision sequence is deliberately narrow. It does not assume return authorisation, a substitute job, collection reversal, delivery completion, a fee, a liability position, service availability, or a particular transport procedure. If the live situation cannot be established, record that uncertainty and keep the next decision owner visible.

4. Suggested internal cancellation worksheet

Use one compact worksheet attached to the original freight job. This is a suggested internal practice, not a carrier-specific form. It is intended to make the unanswered question visible: what instruction, if any, is current for this dispatched vehicle and these goods? Keep evidence links or message references where the team already uses them, but avoid presenting an inference as evidence.

The table offers five common record states and the immediate recording decision they may support. It does not decide a real-world outcome. The dispatcher or designated operations owner remains responsible for resolving an unknown instruction state before a new movement is authorised.

5. Fictional example / 虚构示例

Fictional example: Job FJ-204 is a before-collection freight job. The record shows that a vehicle was dispatched and that the driver acknowledged the original assignment. Later, a message attributed to the customer asks to cancel. The desk does not change the job to delivered, does not delete dispatch, and does not label the vehicle’s next location as a return. The last available driver update does not establish whether collection has occurred.

The dispatcher logs the request as received but unverified, records the vehicle and goods situation as unknown, and names the operations lead as the decision owner for the current instruction. The driver is asked to acknowledge that a revised instruction is pending; the acknowledgement is recorded when received. Only after the decision owner records a verified instruction can a new movement be authorised in the internal record. If verification remains incomplete, the outcome remains “instruction state unresolved” rather than an invented operational result.

This fictional example contains no real customer, carrier, vehicle, route, price, fee, service-level claim, or outcome. It illustrates a recording sequence only. It does not state that the same sequence is required for another carrier, freight type, or operating model.

6. Five-item close check

Close the cancellation exception record only to the extent that the available facts allow. The original job may still contain separate open work, evidence, or later events. A clean exception record makes the boundary visible without claiming that every broader business question has been settled.

1. The cancellation request is retained with its source and received time.
2. Verification status is stated separately from the request.
3. A named dispatcher or operations owner resolved, or still owns, the unknown instruction state.
4. Current vehicle and goods information is recorded as observed or unknown, not inferred.
5. The final recorded outcome does not alter dispatch, movement, collection, or delivery history without corresponding evidence.

7. Narrow differentiation and illustrative image

This field guide is narrower than a general fleet system guide because it handles one timing problem: the customer changes intent after dispatch while the actual vehicle and goods situation may still be incomplete. Its useful distinction is between an instruction event and an execution event. Keeping both allows a team to see what was requested, what was verified, who decided, what the driver acknowledged, and what later occurred without compressing those facts into one status.

The existing AI conceptual fleet-yard illustration may be reused with the label “Illustrative AI concept: fleet yard; not an actual customer fleet or operational record.” It is visual context only and does not evidence a vehicle location, goods status, carrier process, or result. The GOV.UK material can support only the general idea of describing an actor, need and observable outcome; it does not support transport procedure. Source citations are added by the renderer.

Source: GOV.UK: writing user stories