Dynamic Route Optimization: When to Replan Routes and How to Keep Dispatch in Sync

A driver has already left when traffic causes a delay and a new order enters the queue. The original route still exists, but its stop order, delivery commitments, and customer ETAs may no longer describe what can actually happen. Dynamic route optimization can adapt an active plan to new information, but calculation is only one part of the decision. The team must determine what may change, validate the candidate against current execution, and publish one accepted version. This guide provides an engineering workflow for making that choice and keeping dispatch, driver assignments, and customer ETAs aligned.

• Updating an ETA preserves assignments and stop order; replanning may change either and therefore needs stronger operational controls.
• Completed stops and commitments already made to drivers or customers limit the optimizer's freedom.
• Review a candidate together with unassigned and displaced orders, not travel cost alone.
• A calculated candidate is not active until it has been checked, accepted, published, and, where required, acknowledged by the driver app.

Dynamic route optimization may describe building a fresh daily plan or changing an active plan after dispatch. DispatchTrack's overview covers both periodic planning and adjustments based on live inputs. This guide focuses on the second case.

An ETA update preserves the assigned driver and visit sequence. In-day replanning can change either. Navigation may also choose another road between stops without changing the visit plan. Treat these as separate operations.

Mad Devs' work on route monitoring and ETA updates for GoDee illustrates this distinction: Trips Monitor helped operators observe trips, while Pifia refined arrival information. It does not claim automatic delivery replanning.

For the hypothetical operator in this guide, test whether a delayed vehicle can still meet its next commitments. If it can, refresh the ETA without rearranging stops. For a new order, test insertion against cargo, capacity, service time, and promised windows. Otherwise, evaluate another resource or expose an exception.

The following responses are examples, not a universal policy:

A replanning request should represent a specific decision time, not the morning-plan input. Divide the execution snapshot into completed, committed, and changeable areas.

Completed stops are history. Include their outcomes when needed to establish current position or load, but never return them as new driver tasks. Then identify commitments among the remaining stops. A commitment can protect the assigned driver, the next stop, a sequence prefix, or a customer slot. These locks have different meanings and should not be compressed into one locked flag.

Suppose the delayed driver has completed three deliveries, has the cargo for four more, and has already received the next assignment. A new order may fit the vehicle's nominal capacity but still be unsuitable for that route if its goods are at another depot. Likewise, an uncompleted stop should not be considered freely transferable when its cargo is already on that vehicle.

Google's route-plan guidance describes preserving parts of an earlier solution, including fixed routes or shipment assignments. OptimoRoute's planning settings similarly distinguish permitted changes. Platforms may implement locks differently.

The minimum input combines an order snapshot, execution statuses, vehicle or driver positions, availability, current load, time windows, and service time. Record when each source was observed. A fresh GPS position paired with an old completion status can create a plausible but false candidate. Conflicting data should produce a dispatcher-visible exception before automatic application.

Classify constraints explicitly:

• Hard constraints describe outcomes the plan may not violate, such as unavailable cargo or a fixed assignment.
• Preferences express desirable outcomes, such as minimizing reassignment, but may be traded off under an agreed policy.
• Manual overrides record an operational decision and its scope. “Keep this driver” does not necessarily mean “keep this driver's entire stop order.”

For the running example, the request contains the completed prefix, the next stop and cargo-bound assignments as committed, and only the remaining eligible stops plus the new order as changeable. Shift definitions, loading rules, and resource availability must come from the operator's process; an optimizer should not invent them.

The solver's response is a candidate, not a decision. Compare it with the active plan using the constraints and commitments that justified replanning in the first place.

Start with the smallest search space capable of addressing the event. For the new order, first preserve current driver assignments and test insertion among changeable stops. If that fails, allow reordering within the same route. Expand to other available vehicles only when the operational benefit justifies transferring work and when cargo can actually move.

This sequence controls disruption; it does not make narrow optimization mathematically superior. A broader search may lower estimated travel cost but create more driver updates, customer changes, and stale-state risk.

Evaluate every original and new order after the calculation. Identify which remain assigned, which changed owner, which lost an earlier assignment, and which are unassigned with a reason. A shorter route is not an improvement if it silently drops an order or violates a promised window.

OptimoRoute documents that manually scheduled orders may become unscheduled after optimization when constraints prevent their placement. That is a documented behavior of this product, not a universal solver rule, but it demonstrates why unassigned work must be inspected. A solver may legitimately return no feasible insertion. The product then needs an explicit exception: reject the new order, revise a commitment through an authorized process, or assign manual recovery work.

In the example, the candidate is acceptable only if the new insertion remains feasible, committed stops stay protected, and no original order disappears unnoticed. Its calculated travel advantage should remain distinct from what vehicles eventually achieve on the road.

An accepted route must become one operational version across the dispatch dashboard, driver task list, and customer communication. An API response only confirms that a calculation completed.

Use a short lifecycle: execution snapshot → calculated candidate → freshness check → acceptance → publication → delivery status. Give each version an identifier, owner, and status. While the calculation runs, a driver may complete the next stop or a dispatcher may change an assignment. Before acceptance, compare the candidate's source version with the current active state. A stale response must not overwrite a newer decision.

After acceptance, publish the route change and derived ETAs from the same version. Driver acknowledgement is optional only when the operating process says confirmation is unnecessary; the system should still know whether the update reached the device. Google's route-plan lifecycle separates planning from integration and dispatch, which supports this distinction without prescribing one universal versioning protocol.

The GoDee case connects management, driver, and passenger interfaces in one transport service. The version, freshness, and acknowledgement controls proposed here are editorial engineering recommendations for the delivery scenario, not a reconstruction of GoDee's architecture.

Route events may arrive twice, out of order, or after a newer status. Give an event a stable identity or another idempotency mechanism so a retry cannot create a second assignment. If the architecture uses event streams between operational systems, preserve route and plan identifiers in those events rather than assuming arrival order establishes truth.

Model publication failures directly. The dashboard may accept a new plan while one driver's device is offline; another update may reach the app while the customer notification service is delayed. Show these mismatches to dispatch and route them to an owner. Do not send customer ETAs for every candidate: calculate communication from the accepted, applicable plan and sufficiently fresh execution data.

Returning to an older route is not a safe generic recovery. A cancellation, completed delivery, unavailable vehicle, or transferred package can make an earlier version impossible. Recovery should start from current execution, even when it reuses unaffected commitments from an older plan.

The workflow determines what to buy or build. Test the existing platform against the exact scenario before adding another solver.

A platform may already support route locks, allowed changes, manual edits, driver updates, and visible exceptions. Demonstrate the running case with completed stops and transmitted assignments. Verify each lock, unassigned-order handling, and driver delivery. If the behavior fits, configuration and clearer ownership are a smaller scope than another calculation component.

This decision may sit inside a broader review of choosing transportation management software, but a route-change gap alone does not automatically justify replacing the TMS.

When using a route optimization API or a custom solver, scope the system around the calculation: constraint modeling, fresh state sources, dispatcher approval, versioned application, driver delivery, ETA propagation, and outcome checks. Custom integration does not necessarily require a new routing algorithm.

An external example shows why this boundary matters. DataArt describes a UK online grocer that commissioned route calculation together with a transport management interface for route corrections after its earlier process required lengthy calculation and manual planner changes. The case study confirms a real combined calculation-and-operations engagement, but it does not establish that the project used the post-dispatch protocol proposed in this article.

Test the decision boundary and propagation path, not only solver quality. A replay should expose only information available at decision time.

Use the same operator scenario to replay a delay that requires only an ETA update, a new order with locked stops, and an impossible insertion. Add a manual override, a calculation that returns after another stop is completed, and a driver device without connectivity. For each case, retain the original event, source plan version, candidate, acceptance record, published payload, and observed delivery state.

Replay can reveal unstable rules and integration defects, but it does not prove future savings. Begin a pilot with one bounded event type and dispatcher review.

Measure hard-constraint violations and unassigned orders first. Then measure changes to published assignments and near-term tasks, time from event to acceptance, time to driver delivery, and exception handling. Keep the ETA calculated at decision time separate from error measured against actual arrival. Each operator must set its own thresholds for automatic acceptance based on commitments and risk.

Mad Devs can help integrate routing into your transport product when the test exposes gaps between calculation, dispatch, driver tasks, and ETA delivery. The scope should follow the route-change cases and evidence, rather than an assumed platform replacement.

Choose one recurring change and name the person or policy that may approve each response. Replay the path from execution snapshot through candidate review to the driver's assignment and customer ETA. When committed work stays protected, exceptions remain visible, and one accepted version reaches every interface, the team has a defensible basis for expanding automation.