Scenario Planning at Operating Speed
A live decision-simulation studio replaces the quarterly scenario-planning workshop, refreshing the network's digital twin against real operating data every night.
The challenge
Network planning ran on a quarterly cadence: a two-day offsite, a stack of spreadsheet models, and a handful of scenarios chosen in advance. By the time the workshop's conclusions reached operations, the network looked nothing like the one modeled. That produced:
- Scenario assumptions that were already stale by the time a plan reached the floor
- Only 4-6 scenarios reviewed per quarter, chosen before anyone knew what would actually go wrong
- Disruption responses (a lost carrier, a port delay, a demand surge) built from scratch under time pressure
- No shared, current view of capacity across the 140 lanes the network actually ran
- Planning cycles measured in weeks against disruptions that unfolded in days
The average time from a network disruption to a modeled response was roughly three weeks — by which point the disruption had usually already resolved itself, one way or the other.
How it works
A digital twin that never goes stale
Instead of modeling the network once a quarter, the network now models itself every night:
- 01
A digital twin built from live TMS and WMS feeds covering all 140 lanes and every warehouse node
- 02
A discrete-event simulation engine layered over the twin to run capacity and flow scenarios
- 03
Twelve standing scenario templates defined with operations leadership: fuel shock, capacity loss, demand surge, port delay, labor disruption, and seven others
- 04
All twelve scenarios re-run nightly against the current network state, not a quarter-old snapshot
- 05
A studio interface letting planners pressure-test a proposed response before committing a lane change
- 06
Automated flagging when a live metric (dwell time, on-time rate, capacity utilization) breaches a scenario's trigger threshold
- 07
A weekly review replacing the quarterly offsite, focused on exceptions the nightly run surfaced rather than a blank-slate workshop
What we built
Key capabilities
Always-current network state
The twin ingests live TMS and WMS data, so every scenario runs against tonight's network, not last quarter's.
Twelve scenarios, every night
Standing scenario templates refresh automatically instead of being chosen and modeled once per quarter.
Pressure-test before you commit
Planners can simulate a proposed response against the live twin before changing a single lane.
Threshold-triggered alerts
The system flags a scenario's own trigger conditions in the live data, instead of waiting for the next planning cycle to notice.
Before vs after
What changed in network planning
- Scenarios reviewed
- ~5 per quarter → 12 per night
- Disruption response time
- ~3 weeks → ~18 hours
- Network data freshness
- Quarterly snapshot → nightly refresh
- Planning cadence
- Quarterly offsite → weekly exception review
Business impact
What it changed
Far greater scenario coverage
Twelve scenarios refreshed every night against live data replace roughly five reviewed once a quarter — over a 90-day quarter, that's about 1,080 scenario-runs versus 5.
Response time cut from weeks to hours
A disruption response that took about three weeks to model now takes about 18 hours, because the twin doesn't need to be rebuilt before it can be used.
A planning cycle that keeps pace with the network
Weekly exception reviews replaced the quarterly offsite, so decisions get made while the disruption is still live, not after it has already resolved.
Technology stack
“The network doesn't wait for a quarter to change. Now neither does the plan for it.”
Keep reading