How should a TMS handle a stop change after dispatch?
Format: Article.
Keep the last approved stop plan in view while staff check the change. A new address should start a review, not silently replace the driver's plan. Approval is one step. Sending the change is another. The driver's reply must show which version they received and understood.
Dispatch needs to know what changed, who asked for it, and which plan the driver has. The office may see a new address while the driver still sees the old one. A screen that looks up to date can hide a handoff that is not done.
This is a proposed design for an established carrier's dispatch team. Core Agentic's TMS sales demo shows stop details and dispatch work. That does not prove this change-review process is installed. Agree on the rules and test them as part of the build.
Keep the two plans side by side
Give each change its own version ID. Tie it to the load and the right stop. Keep the old plan beside the new request. Check the address, site name, appointment, contact, load number, and special notes. Show each old value beside the proposed one so the reviewer can see the full change.
Not all edits have the same effect. Fixing a phone extension is not the same as changing the delivery site. One changed stop may affect later stops too. Show the reviewer the full set of stops at risk. Keep the details that did not change as they were.
Keep the source message and the name of the person who sent it. Use your approved contact process to check their right to change the shipment. A familiar name is not enough. A forwarded email may leave out who gave approval or what they agreed to change.
Copy this stop revision record
| Field | What to enter |
|---|---|
| Load and stop | Internal load ID, customer reference, stop position |
| Current plan | Last approved revision and its source |
| Proposed change | Exact old and new values, not “address updated” |
| Request authority | Requester, verified contact, source message |
| Impact review | Affected appointments, downstream stops, open questions |
| Approval | Authorized dispatcher, decision, reason, time |
| Communication | Approved revision sent through which channel |
| Driver acknowledgment | Revision received and understood, with time and source |
| Final state | Rejected, waiting for facts, approved awaiting acknowledgment, or active |
Agree what “active” means before the build. One useful rule is to wait for the driver's required reply before calling the new plan confirmed. Keeping the old plan in view does not mean it is still safe or valid to follow. Dispatch and safety leads must set the hold and contact steps when neither plan is cleared for use.
Keep approval attached to the exact revision. If the address changes again, an earlier approval must not carry forward by default.
A hypothetical warehouse switch
Imagine load L610 has an approved delivery to the customer's north warehouse. After dispatch, a customer contact asks for delivery to the south warehouse instead. The message supplies an address but no appointment or receiving contact.
The dispatcher creates version R2. R1 stays in view as the last approved plan, not an order to keep going. The new site is still a request. Dispatch asks the approved customer contact for the missing details. It also checks what the change means for the later stops.
The reply confirms a new appointment. A dispatcher with the right authority approves R2. The office sends that exact version to the driver. The driver replies, “Got the message.” Dispatch asks the driver to name the warehouse and appointment. It records the reply against R2, not just against the load.
A short reply is not always wrong. This example shows why the team needs a clear rule for what counts as a reply. R2 ends with the driver's response and its time. R1 stays in history. Staff can now tell what changed and which plan reached the driver.
Test conflicts before using the design
Rehearse these cases with synthetic records:
- Two dispatchers receive different changes to the same stop. The second change should not erase the first review.
- A customer withdraws the request before approval. The pending revision closes without changing the approved plan.
- The driver acknowledges R2 after R3 has arrived. Show that the acknowledgment refers to R2, not the newest revision.
- The message cannot be delivered. Keep the communication state unresolved instead of declaring the driver informed.
- A dispatcher approves a change while another person edits its address. Require a fresh review of the changed version.
For each case, inspect what the office sees and what the driver is meant to receive. Passing a database check alone does not show that both sides understand the same plan.
Leave operational judgment with dispatch
A changed stop record is not a safe route or a promise of arrival. It does not settle driver hours. Qualified staff must decide if the change can be carried out and how. Show missing facts. Do not push the driver to make an unchecked change work.
Bring one stop-change thread with private details removed to Core Agentic. Show where staff lose track of approval or the driver's reply. Use the TMS sales demo to discuss the change controls your build needs. Book a Demo.
Sources and scope
Core Agentic TMS and design context. The operating steps and fictional examples are first-party recommendations, not verified installed controls or customer results.