Control Tower Demo — Talk Track

DPD UK · Hub Dock Planning · Hinckley Hub · Overnight Inbound Wave

1Plan Set — 14:00

What you're showing

Clean Gantt calendar. 34 vehicles across 8 docks. All blocks in their assigned positions. NOW line at 14:00. Vitals show 0/34 Departed, On-Time 100%.

What to say

This is tonight's plan. 34 vehicles from 10 origins — 6 depots and 4 contracted customers — optimally assigned by the constraint solver. Every vehicle has a dock, a time window, and a departure schedule. The hub cutoff is 04:00. Right now everything is green.

Key point

The plan was generated by Shipsy's constraint optimization engine. It's not a heuristic or a spreadsheet — it's mathematically optimal given the constraints.

2Absorb — ~16:30

What you're showing

COV-V3 (Coventry, Vehicle 3) has an +10m amber badge. Not red. The feed says "Absorbed within buffer." No reschedule happened.

What to say

Not every delay needs action. Coventry V3 is 10 minutes late, but the system built a 10-minute turnaround buffer between every vehicle precisely for this. The plan holds. The controller sees a notification but doesn't need to do anything. This is Level 1 — Absorb.

Without Shipsy

Nobody notices. The 10-minute delay compounds silently. By 2am it's a 30-minute problem.

With Shipsy

System detected it, confirmed the buffer absorbs it, and logged it. If it grows past 15 min, it escalates automatically.

Impact: Zero false alarms. Your team isn't chasing every 5-minute variance.

3Cascade — ~21:15 ★ HERO MOMENT

Setup

BHM-V2 (Birmingham, Vehicle 2) was supposed to depart at 20:45. It's now 21:10 and still hasn't left.

What the system already did

At 20:55, the agent detected the late departure and sent an automatic nudge to the driver: "Depart now to meet your 22:50 dock slot at Hinckley." The driver acknowledged but departed 35 minutes late.

What you're showing

  1. BHM-V2's block gets a red pulsing glow — "SLOT BLOWN"
  2. Frosted overlay appears: "Optimizing docks..." with spinner (2.5 seconds)
  3. Ghost block (dashed outline) fades in at the old position on Dock 3
  4. New block slides to Dock 5 at the new time
  5. If cascade: displaced vehicle also shifts with a 200ms stagger
  6. Feed shows the full chain: "BHM-V2: D3 → D5, NOT-V3: shifted 20 min"
  7. On-Time % drops from ~95% to ~88%

What to say

This is the scenario you described, Ben — where today you find out at 1am that it's going to be a bad day. The system detected this at 20:55 — four hours before you would have known. It nudged the driver. When the vehicle finally departed late, it automatically re-optimised the dock assignment in 2.5 seconds. The ghost block shows where it was supposed to be — full audit trail. And because moving BHM-V2 to Dock 5 conflicted with another vehicle, the system resolved that cascade too. Zero phone calls. Zero manual replanning.

Without Shipsy

Controller discovers at 01:00 that Dock 3 has been empty for 2 hours. Makes 4 phone calls. Manually rearranges 3 vehicles. Takes 45 minutes. Other docks back up while they figure it out.

With Shipsy

Detected at 20:55. Nudge sent automatically. Rescheduled in 2.5 seconds. Cascade resolved. All vehicles still complete before cutoff. Controller was never interrupted.

Impact: ~47 min of dock idle time recovered. 2 vehicles kept on schedule. 45 min of manual replanning eliminated. 4 phone calls avoided.
This is the difference between reactive and proactive. The system detected, nudged, rescheduled, and resolved the cascade — all before the hub controller would have known there was a problem.

4In-Transit Congestion — ~22:30

What you're showing

DER-V2 (Derby, Vehicle 2) departed on time but is now moving slower than expected. Toast: "Congestion on A38. ETA revised." The delay badge grows as the ETA drifts.

What to say

This isn't a departure delay — the vehicle left on time. The problem appeared mid-journey. The system is continuously tracking live ETAs, not just departure events. When the ETA drifts beyond the buffer, it re-evaluates the dock slot. If the slot is at risk, it reschedules proactively — before the vehicle even arrives.

Without Shipsy

The driver is stuck on the A38. Nobody at the hub knows. The dock sits reserved but empty. The next vehicle queues behind it.

With Shipsy

Live ETA tracking detected the slowdown mid-transit. Hub controller sees the revised time. If the slot is blown, the system reschedules before the vehicle arrives.

Impact: Real-time visibility turns a surprise at midnight into a known problem at 22:30 — 90 minutes of lead time to act.

Switch to Map View here

Toggle to Map view. Show the vehicle dots — DER-V2 is the one with the red/amber indicator. All other dots are green and converging on Hinckley. "This is what fleet visibility looks like. Every vehicle, every ETA, live."

5Cutoff Risk — ~03:30

What you're showing

Cutoff countdown card turns RED and pulses (< 30 min remaining). A vehicle that accumulated delays is at risk of completing after 04:00. Red toast: "CUTOFF RISK — controller decision required."

What to say

This is Level 3 — Escalate. The system doesn't silently push a vehicle past cutoff. It stops and presents three options: extend dock hours by 30 minutes, redirect the vehicle to Oldbury hub — 22 miles, 28 minutes — or accept a late completion. The system provides the data and the options. The controller makes the call.

Without Shipsy

At 03:45 someone realises a trailer is still being unloaded. Panic. Phone calls to the night shift manager. No data on alternatives. Rushed decision.

With Shipsy

At 03:30 the controller has the alert, three costed options, and 30 minutes to decide calmly.

Impact: The difference between a crisis at 03:45 and an informed decision at 03:30.

Summary — The Narrative Arc

SceneLevelSystem ActionHuman ActionDetection Lead
① Plan SetSetupOptimised by solverNone—
② AbsorbLevel 1Buffer absorbs itNone neededInstant
③ CascadeLevel 2Auto-reslot + cascadeNone needed4 hours before impact
④ CongestionLevel 2Live ETA revisionNone needed90 min before arrival
⑤ Cutoff RiskLevel 3Escalate with optionsController decides30 min before cutoff

The closing line

The system resolves 80% of disruptions autonomously — absorbing minor delays, rescheduling blown slots, resolving cascades. For the other 20%, it presents the right information at the right time so your hub controller makes a fast, informed decision. That's the difference between finding out at 1am that it's going to be a bad day, and preventing the bad day from happening.

If Ben Asks...

"Is your solution always going to just push everything later?"

No. Four-level response: Absorb (buffer handles it, no move), Reslot (find minimum-disruption move including pulling early vehicles forward), Escalate (present options to controller, no auto-decision), Disrupt mode (freeze auto-scheduling for systemic events). The goal is minimum disruption, not just "push later."

"What if we have way more vehicles than planned?"

Surge vehicles get auto-inserted if hub utilization is below the configured threshold (default 85%). Above that, they queue in the yard with a wait time estimate. If yard wait exceeds 45 minutes, the system recommends redirecting to an alternate hub. Priority hierarchy is always enforced — a surge vehicle won't bump a contracted customer slot.

"What about the contracted customers — Nike, Amazon?"

Tier 0 (Contracted) vehicles are immovable during cascade. The solver gives them 160,000x weight — meaning a single Nike slot is worth more than all depot vehicles combined. During live rescheduling, the cascade protection rule ensures contracted vehicles never get displaced. This is configurable in Setup → Rules & Priority.

"Can you integrate with our existing systems?"

The dock plan pushes to hub ops, transport teams, and drivers via API. GPS/telematics feed into the live ETA engine. The solver takes forecast data from your booking system. All standard REST APIs — same integration pattern as Shipsy's existing TMS deployments.

"How long does the optimisation take?"

Baseline planning: ~5-10 seconds for 34 vehicles across 8 docks. Live rescheduling: instant (< 100ms). Batch re-solve for systemic disruptions: 5-15 seconds.

Demo files: dpd-hub-planner.html (planner) · dpd-control-tower.html (control tower)

Folder: ~/Desktop/DPD UK/demo/v3-calendar-first/

Server: python3 server.py (port 5050, optional — JS fallback works without it)