Dynamic Dispatch Software: Same-Day Re-sequencing, Cancellations, and SLA Recovery Playbooks

Every delivery plan begins with good information. By 10 AM, some of that information is wrong.

A driver spent 20 minutes at a stop that was planned for 5. Three orders were cancelled. A traffic incident has closed the fastest route to the afternoon’s highest-density zone. And two deliveries are now projecting late against their committed windows.

Dynamic dispatch software is the layer that handles those changes after departure. It re-sequences active routes when conditions shift, absorbs cancellations without requiring manual dispatcher intervention for each one, and executes predefined SLA recovery playbooks when risk signals emerge.

This article explains how each function works, what quality looks like in each case, and what connects them into a coherent operational response.

What Dynamic Dispatch Software Is Built to Handle

Static route planning tools produce a plan. Dynamic dispatch software maintains a delivery operation.

The distinction defines what each tool is responsible for: the planner is done when the route leaves the depot; the dynamic dispatch system’s work begins at that moment.

The three functions in this article address the most common and most consequential mid-day disruptions in last-mile operations. Each one has a defined operational cost when managed manually and a measurably better outcome when handled through automated dispatch intelligence.

The three scenarios that static planning tools cannot address

Scenario	What a static planning tool does	What dynamic dispatch software does
New order arrives mid-route	Has no mechanism to insert the order; dispatcher must manually evaluate and assign	Evaluates the full active fleet for the optimal insertion point; updates the route and notifies the driver automatically
Order cancelled mid-route	Dispatcher must identify the cancellation, remove the stop manually, and notify the driver; route is not re-optimized	Removes the stop, recalculates the tightened route, surfaces any available capacity for new orders, triggers cancellation confirmation to customer
SLA risk detected on active delivery	No mechanism to detect or respond; risk surfaces as a missed SLA in the end-of-day report	Triggers the predefined SLA recovery playbook for the specific exception type; executes automated responses within defined parameters

Same-Day Re-sequencing: When the Plan Must Change in Motion

Re-sequencing is the function that adjusts the stop order of an active route when the current sequence is no longer optimal. It applies when a new order is inserted, when a stop takes significantly longer than planned, when a traffic event changes the relative travel cost between stops, or when a failed first attempt removes a stop and changes the available time for remaining ones.

What triggers a re-sequencing event

Four conditions commonly trigger a re-sequencing calculation on an active route:

• New order insertion: A same-day order arrives and needs to be assigned to an active vehicle. The optimal insertion point is not necessarily the geographically nearest stop; it is the stop position that allows the new order to be completed within its window with the least impact on existing commitments
• Service time overrun: A driver spends significantly longer at a stop than the planned service time. The overrun shifts every subsequent ETA. Re-sequencing evaluates whether the current stop order is still optimal given the delay, or whether a different sequence recovers more time
• Traffic event: A road closure or significant congestion event changes the relative travel cost between stops on the remaining route. The stop order that was optimal at 8 AM may not be optimal at 1 PM when a key road is closed
• Failed first attempt: A delivery attempt fails and is removed from the active route. The time that would have been spent at that stop becomes available. Re-sequencing uses that time to tighten the remaining sequence or improve the ETA accuracy for subsequent stops

How re-sequencing quality is measured

Re-sequencing is commonly sold on speed: how quickly the algorithm produces a result. Speed matters, but it is the wrong primary metric.

A re-sequenced plan produced in 10 seconds that only considers the affected route is less valuable than one produced in 2 minutes that considers the full active fleet and finds a better insertion point on a different vehicle.

The evaluation criteria that actually predict operational value:

• Constraint fidelity: Does the re-sequenced plan honor every time window, vehicle capacity limit, driver hour constraint, and SLA commitment that the original plan respected? A re-sequence that produces a faster route by violating a committed delivery window has not improved the plan
• Network scope: When a new order arrives, does the system evaluate all active vehicles for the optimal assignment, or does it only evaluate the geographically closest vehicle? The best insertion point is often not on the nearest vehicle
• Driver communication: Is the updated sequence transmitted to the driver through the same channel they already use? A re-sequencing calculation that requires a separate dispatcher-to-driver communication step adds delay between the decision and the action

Cancellations: Absorbing Order Changes Without Disrupting the Fleet

Order cancellations are a regular event in e-commerce and retail delivery. What varies is how the cancellation is handled operationally.

A cancellation that is absorbed automatically by the dispatch system converts a disruption into an opportunity. On the other hand, a cancellation that requires manual dispatcher action for each occurrence accumulates as a drain on dispatcher capacity.

The cost of a cancelled order managed reactively

When an order cancellation is handled manually, the sequence of events is:

• The cancellation notification arrives from the OMS or the customer service team
• A dispatcher is notified and takes the action of removing the stop from the driver’s route in the dispatch system
• The driver is contacted to confirm the updated route
• The freed vehicle capacity is noted but not automatically offered to waiting orders
• The customer receives a cancellation confirmation from a separate system

Each step in this chain takes time and requires dispatcher attention. At high cancellation volumes, the cumulative dispatcher time is significant. And the freed capacity is frequently not recaptured because there is no systematic mechanism for surfacing it to the order allocation process.

How dynamic dispatch absorbs cancellations

When cancellations are handled through dynamic dispatch software, the sequence compresses to seconds:

• The cancellation event propagates from the OMS to the dispatch system through an API connection
• The stop is removed from the active route automatically
• The route is re-optimized to close the gap left by the removed stop, recovering the time that would have been spent on service and travel to that location
• The freed vehicle capacity is surfaced to the order allocation system as available for new assignments
• The customer receives a cancellation confirmation triggered by the dispatch event, delivered through the same notification channel as their original dispatch confirmation

The operational value of automating this sequence is twofold. The dispatcher’s attention is preserved for the decisions that require judgment. And the freed capacity is consistently offered back to the network.

The customer confirmation aspect matters for reducing WISMO contacts. A cancellation that is not confirmed to the customer within minutes generates a support contact from a customer who is uncertain whether the cancellation was processed. The support contact costs money. The automated confirmation triggered by the dispatch event costs nothing.

SLA Recovery Playbooks: From Detection to Resolution

An SLA recovery playbook is a predefined response workflow that activates when the platform detects a specific risk signal.

The activation trigger, the response steps, the customer communication, and the escalation path are all configured in advance. When the signal fires, the playbook executes without requiring a dispatcher to initiate each step.

The value of a playbook over manual triage is timing. A manual triage process takes as long as it takes for a dispatcher to notice the signal, evaluate the situation, decide on a response, and execute it.

A playbook executes in seconds. In a delivery window that may be 30 minutes, the difference between a 3-minute response and a 15-minute response determines whether the SLA is recoverable.

What a recovery playbook contains

A well-structured SLA recovery playbook has five components:

Playbook component	What it specifies
Detection trigger	The specific signal that activates the playbook: ETA drift exceeding a threshold, failed first attempt event, carrier capacity alert, or SLA window countdown reaching a defined lead time
Automated response	What the system executes without dispatcher approval: customer notification, re-sequencing calculation, alternative carrier evaluation, or stop re-scheduling
Approval gate	Responses that require dispatcher confirmation before execution: carrier re-assignment above a cost threshold, delivery window change beyond a defined range, or escalation to an account-specific contact
Customer communication	The notification sent to the customer: timing, channel (SMS, email, WhatsApp), content (revised ETA, apology copy, alternative offer), and trigger event that sends it
Resolution measurement	The outcome that closes the playbook: delivery confirmed within the adjusted window, customer acknowledged the revised ETA, or escalation resolved by the account team

Routing the recovery by exception type

Different exception types require different recovery responses. A playbook built for ETA drift applies a different response sequence from one built for a failed first attempt or a carrier capacity failure.

Configuring separate playbooks per exception type ensures each response is appropriate to the specific situation.

Common exception-to-playbook mappings:

• ETA drift above threshold: Customer notified with revised ETA; dispatcher alerted with countdown to window close; re-sequencing evaluated if time allows; escalation triggered if window is within 20 minutes and re-sequencing cannot recover
• Failed first attempt: Next available window assessed; customer notified with rescheduled delivery option; address data verified against original order; re-delivery booked in the same dispatch cycle if capacity allows
• Carrier capacity failure: Alternative carrier evaluated from available network; route plan updated for the substitute carrier; customer notified if any delivery window change results; original carrier flagged in performance data
• SLA breach risk at T-minus threshold: Dispatcher receives a countdown alert with the specific deliveries at risk; automated escalation message pre-populated for the account manager or customer contact; re-routing options evaluated and ranked by SLA recovery probability

The playbook for each exception type should be reviewed and updated based on the resolution measurement data from past activations. A playbook that achieves SLA recovery in 80% of activations is performing well. However, one that achieves recovery in 40% of activations needs its response logic reviewed.

How the Three Functions Connect

Re-sequencing, cancellation management, and SLA recovery playbooks are not independent functions. They form a response continuum that covers the full range of mid-day disruptions.

• Re-sequencing is the adjustment function: It responds to changes in the plan by finding a better sequence. Triggered by events that create a new optimization opportunity: a new order, a route deviation, a time window shift
• Cancellation management is the capacity function: It responds to demand changes by freeing and redistributing capacity. Triggered by customer actions that remove committed stops from active routes
• SLA recovery playbooks are the protection function: They respond to performance risk by executing predefined corrective workflows. Triggered by performance signals that indicate a delivery commitment may not be met

The three functions interact. A cancellation triggers a re-sequencing calculation. A re-sequencing event changes the ETA for downstream stops and may trigger an SLA recovery playbook if the re-sequenced ETA shows a window risk. A successful SLA recovery playbook execution may include a re-sequencing call as part of its response logic.

When the three functions share a data layer, these interactions are handled automatically. When they operate through separate tools, each interaction requires a manual bridge: the dispatcher who notices the cancellation also has to initiate the re-sequencing calculation and check whether any playbooks should be triggered by the new route state.

How Locus Handles Dynamic Dispatch

Locus is the world’s first Decision-Intelligent, Agentic TMS. Its architecture connects re-sequencing, cancellation management, and SLA recovery through a shared operational data layer and specialized AI agents that handle each function.

The dispatch decision intelligence behind each function

Three of Locus’s eight specialized AI agents are most active in dynamic dispatch scenarios:

Dispatch agent

It evaluates the full active fleet when a re-sequencing event occurs, finding the optimal insertion or re-sequencing point across the network.

When a same-day order arrives, the Dispatch Agent evaluates every vehicle with remaining capacity to find the assignment that minimizes impact on existing SLA commitments

Customer agent

It triggers customer notifications at each dispatch event automatically. When a cancellation is absorbed, the Customer Agent sends the confirmation.

When an SLA recovery playbook produces a revised ETA, the Customer Agent sends the update via SMS, email, or WhatsApp without dispatcher involvement

Copilot agent

The intelligence interface within Mycroft AI Co-Pilot that surfaces what the other agents are doing and why. When a re-sequencing calculation finds a better route, the Copilot Agent presents the proposed change and its expected impact to the dispatcher for review.

When a playbook activates, the Copilot Agent shows the dispatcher the specific signal that triggered it and the steps the system is executing

The Fireworks Routing Engine runs the re-sequencing calculations across 250+ real-world constraints in under five minutes at enterprise volumes. Locus’s Driver Companion App transmits the updated route sequence to the driver as soon as the re-sequencing calculation completes, without requiring a dispatcher-to-driver phone call.

ShipFlex handles carrier re-allocation when an SLA recovery playbook determines that the current carrier cannot meet the committed window and an alternative carrier is needed, selecting from 160+ active carriers from a broader network of 1,000+ pre-integrated partners.

For delivery exception management, Locus connects the exception detection layer to the playbook execution layer in the same platform. When the visibility layer detects an ETA drift or a first-attempt failure, the relevant playbook activates through the platform.

Locus serves 360+ enterprise customers across e-commerce and retail and FMCG, CPG, and 3PL verticals in 30+ countries, with $320M+ in collective logistics cost savings and 99.5% on-time SLA adherence.

In October 2025, Ingka Investments, the investment arm of Ingka Group, acquired Locus, providing long-term institutional backing to a platform that continues to operate independently.

Questions to Ask Any Vendor

Use these questions to surface implementation depth:

• For re-sequencing: When a new same-day order arrives, does the system evaluate all active vehicles for the optimal insertion point, or only the geographically nearest vehicle? What happens when the best insertion point is on a vehicle that is currently en route to a time-sensitive stop?
• For cancellations: When an order is cancelled, is the freed vehicle capacity automatically surfaced to the order allocation system for new assignments, or does a dispatcher have to manually update the vehicle’s available capacity?
• For SLA playbooks: Can different playbooks be configured for different exception types, or is there one generic alerting workflow for all exceptions? Can the automated response steps and the approval gates be configured separately per exception type?
• For data connection: Are re-sequencing, cancellation management, and SLA playbook execution connected to the same operational data layer, or are they separate modules that require manual synchronization when one function affects another?
• For driver communication: When a route is re-sequenced, how does the updated sequence reach the driver? Is it automatic through the driver app, or does it require a dispatcher to call or message the driver?
• For measurement: Does the platform track the resolution rate for each SLA recovery playbook and report on which playbook configurations produce the highest recovery rates? How is that data used to improve the playbook configuration over time?

Connect Manual and Automated Functions With Dispatch Platforms

The gap between a static route plan and a dynamic delivery operation is filled by three specific functions: re-sequencing when the optimal stop order changes, cancellation management when demand changes mid-route, and SLA recovery playbooks when performance risk emerges before a commitment is breached.

Each function has a manual version and an automated version. The manual version depends on dispatcher availability and attention for every event. The automated version executes the same response consistently, in seconds, for every event of the relevant type.

At enterprise delivery volumes, the accumulated difference between these two versions is measurable in SLA compliance rate, dispatcher capacity, and cost per delivery.

The three functions are most valuable when they share a data layer, so a cancellation that triggers a re-sequencing calculation also triggers an SLA risk check on the re-sequenced route without requiring a separate action.

Schedule a demo to see how re-sequencing, cancellation management, and SLA recovery playbooks work as connected functions in one dispatch platform.

---