Proposed operational design flow

Translating optimization into real-world execution.

The spreadsheet plans the week. Running the day takes a system — for the dispatcher, the salesperson, and the driver. This is the operating design that sits on top of the optimized schedule.

The gap

Excel handles weekly planning. The day needs a real-time system.

Customer reschedules, traffic delays, no-shows, and instant quotes can't wait for next week's planning cycle. The design below closes that gap.

System architecture
+----------------------------------------------------------+
|                  DELIVERY OPERATIONS                 |
+----------------------------------------------------------+
|                                                          |
|  +----------+      +----------+      +----------+        |
|  | PLANNING |      | DISPATCH |      |  SALES   |        |
|  | (weekly) |----->| (daily)  |<---->| (quote)  |        |
|  +----------+      +----------+      +----------+        |
|       |                 |                  |             |
|       +-----------------+------------------+             |
|                         |                                |
|                         v                                |
|  +--------------------------------------------------+    |
|  | SHARED DATABASE                                  |    |
|  | orders · truck GPS · buffer remaining            |    |
|  | pricing rules · reschedule history               |    |
|  +--------------------------------------------------+    |
+----------------------------------------------------------+
Three tools
1

Sales quoting tool

iPad/POS plugin for instant delivery quotes. Salesperson enters cubic feet — gets the price. No phone calls to operations.

$150 + ($0.25 × volume)

Surcharges: stairs +$50 · expedited +$150 · assembly +$100

2

Dispatch dashboard

Real-time route status and buffer monitoring. When a customer calls to reschedule, the dispatcher sees which days have capacity and moves them with one click.

buffer > 60 · 30–60 · < 30

Live truck locations · one-click reschedule · overtime alerts

3

Driver mobile app

Navigation plus three exception buttons — the driver taps, the system handles the logic.

delay → ETA · no-answer → timer · reschedule → slot

Traffic Delay → updates ETAs · No Answer → starts wait timer · Customer Reschedule → logs & finds slot

Embedded decision rules

Dispatchers don't think — they execute.

Every rule below is embedded in the tools above. The judgment is made once, at design time.

Reschedule logic

1st time → FREE

→ Find a day with buffer > 60 min

2nd time → $75

→ Find a day with buffer > 30 min

3rd+ time → $75

→ Moved to the end of the queue

No-show logic

If driver waited ≥ 15 min and no contact:

→ Mark as no-show

→ Charge $75 fee

→ Log wasted trip: 2 hrs × $104/hr = $208

→ Auto-reschedule to next available window

Overtime prevention

If current time + remaining work > 5:00 PM:

→ Alert dispatch

→ Options: (a) skip last stop and reschedule · (b) authorize OT at 1.5× rate · (c) call customer, reduce scope

Traffic delay cascade

When the driver taps "Traffic Delay":

1. Recalculate ETAs for all remaining stops

2. Check if the new timeline passes 5 PM

3. If yes → trigger overtime prevention

4. Notify affected customers by SMS

Dispatch dashboard — live view

What the dispatcher sees at 10:42 AM.

Today: Day 1 · Truck 1 — active route Refresh1 alert
StopCustomerETAStatusVolumeAction
1CUST24249:30 AM✓ Done1,305—
2CUST250811:15 AMEn route276—
3CUST19461:30 PMPending2,282Reschedule
4CUST73952:45 PMPending406Reschedule
5CUST64464:00 PMPending2,229Reschedule
Buffer remaining: 3 min ⚠ tight — no same-day adds Miles: 24 / 59 completed
Alert · 10:42 AM — CUST2508 requested a reschedule (1st time) → moved to Day 7 (buffer: 99 min) ✓
Disruption playbook

Tight days carry the risk. The playbook absorbs it.

Days 1–3 run on buffers under 30 minutes. When something breaks there, this is the flow.

Day 1
3
min buffer
CRITICAL
Day 2
23
min buffer
CRITICAL
Day 3
10
min buffer
CRITICAL
Day 4
47
min buffer
TIGHT
Day 5
99
min buffer
ABSORB
Day 6
105
min buffer
ABSORB
Day 7
99
min buffer
ABSORB
Decision flow for disruption
DISRUPTION OCCURS (customer not home, traffic, access issue)
                    |
                    v
         +----------------------+
         |  Can we still        |
         |  finish by 5 PM?     |
         +----------+-----------+
                    |
           +-------+-------+
           |               |
          YES              NO
           |               |
           v               v
       Continue     +---------------------+
       route        |  Skip this stop     |
                    |  Reschedule to      |
                    |  SAME-CLUSTER day   |
                    |  with buffer        |
                    +----------+----------+
                               |
                               v
                    +---------------------+
                    |  Notify customer    |
                    |  via SMS (auto)     |
                    |  within 2 minutes   |
                    +---------------------+
Live scenario

No-show on Day 1, resolved by 1:47 PM.

Situation: CUST1946 (Alameda, 2,282 cu ft) isn't home at 1:30 PM on Day 1. Buffer is only 3 minutes. The crew is already behind.

StepWhoActionTime
1DriverTaps "No Answer" in the app, waits 15 min1:30 PM
2SystemStarts timer, alerts dispatchAuto
3DriverTaps "Customer Unreachable" after the wait1:45 PM
4DispatchSees the alert, checks buffer days1:46 PM
5SystemAuto-identifies Day 6 (105 min buffer)Auto
6DispatchConfirms the reschedule with one click1:47 PM
7SystemSends SMS + email to the customerAuto

Why Day 6 for the Alameda reschedule?

DayBufferCluster fitDecision
Day 447 minNo (Sausalito)Wrong cluster, +20 mi
Day 599 minNo (Sausalito / Berkeley)Wrong cluster
Day 6105 minYes (Berkeley nearby)Best fit — +3 mi only
Day 799 minNo (South SF / SF Core)Wrong direction
Key logic: we don't just pick the day with the most buffer — we pick the day where the customer fits the existing route, to avoid adding unnecessary miles.

Customer notification (auto-SMS)

SMS from the delivery team

"Hi — we attempted your delivery today but couldn't reach you. We've rescheduled you to Day 6, 1:00–3:00 PM. Reply YES to confirm, or call us to pick another time."

Cost impact

A reschedule costs $4. A wasted trip costs $244.

At the case-documented $104/hr crew rate and $1.21/mile. That's why we match clusters, not just buffer.

Hourly rate
$104
Cost / mile
$1.21
OT multiplier
1.5×
Avg service time
1.5 hrs

Same-cluster day

Extra miles to existing route: ~3 mi

Fuel: 3 × $1.21$3.63

Extra labor$0 (already working)

Total+$4–6

Different cluster

Detour miles: ~12 mi

Fuel: 12 × $1.21$14.52

Extra time: 0.25 hrs × $104$26.00

Total+$41

Standalone trip (worst case)

Round trip: ~30 mi

Fuel: 30 × $1.21$36.30

Labor: 2 hrs × $104$208.00

Total+$244

Authorize overtime

Regular rate$104/hr

OT rate: $104 × 1.5$156.00/hr

Incremental cost per OT hour$52.00

Per OT hour+$52/hr
Implementation roadmap

Operational in a week. Scaled when the pricing is proven.

PhaseTimelineDeliverableCostStatus
Phase 1Week 1Sales quoting spreadsheetFreeSTART HERE
Phase 2Weeks 2–3Dispatch dashboard (spreadsheet + manual updates)FreeNEXT
Phase 3Month 2Driver mobile app (route software)$150–300/moLATER
Phase 4Month 3+Integrated system (custom build)$5–20kSCALE
Key point: start with a spreadsheet — operational in a week. Scale to real software once the pricing model is validated.