Shipsy’s dynamic rerouting engine reoptimizes a live trip within 30–90 seconds of a disruption — traffic, hub delay, consignee reschedule, new high-priority pickup, or driver absence. It does not simply skip a stop. It recomputes the full affected task stack, updates the driver app, refreshes consignee ETAs, and locks in the decision before the driver has parked their vehicle. In networks where mid-day disruptions are the norm, this mechanism converts “plan-then-pray” execution into a closed feedback loop.
Why we built this
A morning plan is a guess about the world. In reality, 15–30% of operational hours are disrupted — traffic incidents, new pickup requests, consignee “not available now, come at 4pm” messages, vehicle breakdowns, hub sortation overruns, and surge events in quick-commerce networks. Legacy TMS systems acknowledge the disruption but leave the response to human dispatchers — who make locally reasonable but globally suboptimal choices.
We built dynamic rerouting so the response to disruption is algorithmic, fast, and cheap. When the world changes, the plan changes, and the driver’s phone reflects the new plan within seconds.
How it works
The engine has four layers:
Layer 1 — Trigger detection. Shipsy’s control tower and execution signals continuously watch for rerouting triggers: GPS deviation beyond threshold, elapsed-dwell exceeding expected service time, incoming pickup/reschedule events, slot reschedules, hub exception alerts, carrier reassignment events, or explicit dispatcher intervention. Triggers are typed (soft, hard, critical) and carry a recommended replan scope.
Layer 2 — Scope resolution. The engine decides how much of the plan to replan. Options range from local (re-sequence the remaining task stack of one driver) to regional (re-allocate tasks across three adjacent drivers) to network (re-plan the full remaining shift for a depot). The default heuristic: replan the smallest scope that resolves the trigger, unless the cost function shows a larger replan produces meaningfully better outcomes.
Layer 3 — Constrained reoptimization. Astra’s column-generation router runs on the selected scope, respecting all active constraints — driver fatigue windows, SLA commitments, vehicle capacity, consignee slot windows, ePOD state of already-completed tasks. Already-delivered stops are frozen. In-flight drivers keep their current stop unless the replan explicitly diverts them (with a consignee-notified reason). The cost function balances the disruption cost against the stability cost — a replan that saves 10 minutes but reshuffles 40 stops is usually rejected in favor of a smaller replan.
Layer 4 — Publication and confirmation. The new plan is pushed to the affected driver apps as a task-stack update with a change log. Drivers see what changed and why (“Stop 7 moved to after Stop 9 — customer rescheduled”). Consignees whose ETAs materially changed receive a Clara-driven proactive message. The dispatcher console logs the replan with its reasoning trace for audit.
The engine is stability-biased by default — it treats the morning plan as the prior, and replans are proposed only when their expected outcome beats the plan-plus-disruption cost by a threshold. This prevents thrashing.
Here’s the state flow at a glance:
Early results
Enterprises deploying dynamic rerouting typically report, within 60 days:
- Replan latency of 30–90 seconds for typical metro scopes of a few hundred stops.
- 10–20% improvement in SLA adherence on disrupted shifts versus static-plan baselines.
- 3–5% incremental cost savings per replan event versus “dispatcher plus judgment” baselines, compounded across hundreds of disruptions per day.
- Lower driver frustration because the new plan is algorithmically reasonable and the driver app explains what changed.
A global parcel leader spanning 65+ countries uses dynamic rerouting to absorb daily network surprises without degrading SLA on 18,000+ driver routes.
What’s next
Three upgrades: predictive replanning (the engine replans before the trigger fires, when it forecasts high trigger probability), multi-driver collaborative replans (handoff-aware, so drivers close to each other can swap tasks mid-shift), and weather and event-feed triggers (replans that preempt known disruptions like roadworks and stadium events).