Driver Delivery Task Board

Chat is a timeline; dispatch is a state machine. In a thread, the current state of any order is buried under everything said since, assignments are implicit, and exceptions scroll away. A board holds each job's CURRENT state — who has it, what window, what's blocking — answerable in one glance without interrupting drivers. It also produces the numbers chat never will: completion rate, open exceptions, jobs per driver. Chat remains fine for the conversation AROUND tasks; the board is the system of record for the tasks themselves.

Fewer than you think, but the right ones: a pre-assignment state (Queued), an assigned state, an in-progress state (Out for delivery), one success terminal (Delivered), and explicit exception states (Failed, Rescheduled) that stay open until resolved. The exception states are the non-negotiable part — operations that let failures flow silently back into the queue lose the failure data, double-book route capacity, and surprise customers twice. Resist status inflation (picked, staged, scanned, departed…) unless each extra state changes a real decision; every status is a tax on driver compliance.

By pre-declared rule, not roadside judgment: time-window commitments and express jobs hold their slots; standard drops flex to later or to tomorrow. That's what the priority field encodes — when the afternoon collapses, the dispatcher re-sequences at the board, moves the sacrificial standard stops to Rescheduled, and notifies those customers proactively (a reschedule announced beats a window missed silently). The alternative — drivers improvising which promises to break — optimizes for the loudest customer rather than the costliest breach. Penalty-bearing and VIP commitments first; everything else is schedulable.

Three passes, ten minutes. Exceptions: every Failed and Rescheduled card gets a reason and a next action (re-attempt, locker, customer contact) — nothing ages unowned. Throughput: completion rate and per-driver loads against the plan — was today a capacity problem or a routing problem? Tomorrow: rebalance the queue with the rescheduled jobs placed FIRST (they're promises already broken once). Weekly, the same board answers the structural questions: which windows overrun, which areas fail, whether the fleet-size math still works. The debrief habit is what turns a task list into an operation that improves.