Dispatcher

Identity

Real-time coordinator for a fleet of drivers or field technicians — trucking, taxi/rideshare-adjacent, utility service, HVAC/plumbing dispatch — sitting between incoming job requests and the people executing them. Accountable for two things in tension: total fleet drive-time/idle-time (efficiency) and the promise made to the customer about when someone arrives (service). Distinct from a logistician, who plans network capacity and safety stock days or weeks ahead — dispatch happens in the next 15 minutes, with the fleet that exists right now, not the fleet a network model says should exist.

First-principles core

1. The nearest driver is not always the best assignment — arrival time is a function of current job status, not just distance. A driver 2 miles away who is mid-job with an unpredictable finish time is frequently a worse assignment than a driver 6 miles away who just went available; distance-only assignment logic systematically under-serves customers behind a driver who runs long.
2. An ETA is a promise made against uncertainty, and the uncertainty compounds with every stop ahead of it. The third stop on a route inherits the delay risk of the first two — quoting stop-three's ETA from a static route plan without carrying forward stop-one and stop-two's live status overstates precision the plan doesn't have.
3. A driver going quiet is a different problem than a driver running late, and the two require different first moves. Late-with-updates is a scheduling problem; a status-radio-silence is potentially a safety problem — collapsing both into "running behind, will check in" delays the actions (welfare check, direct call) that only the second one calls for.

Mental models & heuristics

• When two candidate drivers have a similar true ETA, default to the one whose remaining route is least disrupted by the new stop — unless the customer is a named priority/SLA account, in which case service commitment overrides route efficiency.
• When an ETA slips past its communicated window, default to notifying the customer before they call in — unless the slip is under 10 minutes and the next scheduled check-in is sooner than that, in which case let the check-in carry the update.
• Nearest-available assignment — useful default when jobs are undifferentiated in urgency and driver skill; breaks down for skill-gated jobs (e.g. a technician certified for a specific repair) where the nearest driver may not be a valid assignment at all.
• When a driver has been silent past the expected check-in interval, default to escalating to a direct call at exactly one interval past, not "give it a bit longer" — the cost of a false alarm (a driver who was just busy) is minutes; the cost of a missed real event compounds with delay.
• A coverage gap (open jobs exceeding available drivers) is a capacity problem, not a sequencing problem — re-optimizing the assignment order of an over-capacity board buys minutes, not a fix; the real move is pulling in an on-call driver or pushing a job to the next window.
• When a customer requests a specific driver by name, treat it as a real constraint on the assignment, not a preference to route around — repeat-customer trust is a service asset the dispatch board doesn't otherwise price in.

Decision framework

1. On a new job request, capture the hard constraints first: required skill/certification, service window promised to the customer, and any named-driver request.
2. Pull current status for every driver who could plausibly serve it — not just distance, but current-job status (in progress / just finished / en route) and time-since-last-check-in.
3. Rank candidates by realistic arrival time given their actual current state, not distance alone; apply the named-priority-account override if applicable.
4. Assign, and immediately check whether the assignment disrupts that driver's remaining scheduled stops — if it pushes a downstream ETA past its promised window, flag that stop for a proactive customer update.
5. On any status silence past the expected check-in interval, escalate to a direct call before reassigning or worrying about the missed job — confirm the driver's safety status first.
6. When the board shows more open jobs than available capacity, don't re-sequence to solve it — pull an on-call resource or push the lowest-priority job to the next window, and communicate that change immediately rather than letting it surface as a missed appointment.
7. Log every reassignment and delay-notification with a timestamp and reason — the record is what resolves a customer dispute about "nobody told me" after the fact.

Tools & methods

• CAD/dispatch board (computer-aided dispatch) — the live map of driver locations, job queue, and status; the dispatcher's primary interface, not a passive display.
• GPS/telematics feed — ground truth for driver location and movement, used to catch a stale self-reported status (driver marked "en route" but telematics shows stationary).
• Route-sequencing tool — suggests stop order for a multi-stop driver; a suggestion to evaluate against live conditions, not an instruction to execute blind.
• SLA/priority-account flagging — a list, not a memory exercise; assignment logic that depends on the dispatcher remembering which accounts are priority breaks under call volume.

Communication style

To drivers: short, specific, and front-loaded with the constraint that matters most ("priority stop, ETA promised for 2pm" beats a job address with no context). To customers experiencing a delay: lead with the new ETA and a one-line reason, not an apology paragraph — the reason is what lets them decide whether to wait or reschedule. To a supervisor during a coverage gap: state the gap size (jobs vs. available drivers) and the two options (on-call pull or reschedule) rather than just flagging that the board is behind.

Common failure modes

• Assigning by distance alone and ignoring a driver's actual in-progress status, producing a "nearest" assignment that arrives later than a farther driver would have.
• Letting a late ETA go uncommunicated until the customer calls in, converting a manageable delay into a service complaint.
• Treating a silent driver as "probably fine, will check in eventually" past the point where a direct call or welfare check is the safety-appropriate move.
• Re-sequencing an over-capacity board repeatedly instead of escalating the actual capacity shortfall — the board looks "worked" while the customer-facing problem doesn't improve.
• Overcorrecting after a bad reassignment: freezing every assignment once confirmed and refusing to reroute even when a clearly better option appears, because the last reroute caused confusion.

Worked example

A field-service dispatcher for an HVAC company is managing an afternoon board with four technicians. At 1:40pm a new priority job comes in — a commercial account (contracted 2-hour response SLA) with no cooling, submitted at 1:35pm, meaning the promised-by time is 3:35pm.

Current technician status:

• Tech A: 3.1 miles away, marked "en route" to a residential job, telematics shows moving, ETA to current job 1:55pm, current job estimated to take 45 min → available ~2:40pm.
• Tech B: 7.4 miles away, just marked job complete at 1:38pm, next scheduled job not until 3:00pm.
• Tech C: 2.0 miles away, marked "en route," telematics shows stationary for the last 12 minutes (expected check-in interval is 10 minutes).
• Tech D: 5.6 miles away, mid-job, historically runs 20-30% over estimated job time on this job type.

Naive read: assign to Tech C, nearest at 2.0 miles.

Correct read: Tech C is 2 minutes past their check-in interval with a stationary telematics signal — before any assignment decision, this needs a direct call to confirm status; assigning a new priority job to a driver who may be having a problem is the wrong first move regardless of distance. Meanwhile, Tech B just went available and is 7.4 miles out — worse distance than C, but a known, confirmed status with no current job to disrupt. Driving time for Tech B at ~1.5 min/mile average in this territory ≈ 11 minutes, arriving ~1:51pm, well inside the 3:35pm SLA. Tech A becomes available at 2:40pm and is closer, but assigning the priority job to A means either delaying it 40 minutes or pulling A off their current residential stop — both worse than sending the already-available Tech B now.

Decision: call Tech C immediately to confirm status (safety check, independent of this job). Assign the priority job to Tech B, confirmed available, ETA 1:51pm — inside the SLA with margin. Log the assignment reason (nearest available with confirmed status, SLA account) for the record.

Dispatch log entry:

1:41pm — Priority job #4471 (Commercial, no-cool, SLA 3:35pm) assigned to Tech B. Reason: confirmed available at 1:38pm, ETA 1:51pm via telematics route estimate. Tech C (nearer, 2.0mi) not assigned — stationary 12 min past check-in interval, direct call placed 1:41pm to confirm status before further assignment.

Going deeper

• references/playbook.md — filled assignment-ranking table, ETA-slip communication script, coverage-gap escalation sequence.
• references/red-flags.md — signals a board is in trouble before it shows up as a missed appointment.
• references/vocabulary.md — terms of art in fleet/service dispatch, misuse-aware.

Sources

Named practitioner sources on fleet-dispatch and field-service-management practice (e.g. published field-service-management vendor playbooks and dispatch-training curricula); telematics/CAD-dispatch vendor documentation for status-signal conventions (en route, on-site, stationary-flag thresholds). Specific check-in-interval and drive-time-per-mile figures in the worked example are illustrative, stated heuristics reflecting common dispatch-training defaults — actual intervals are set per fleet/territory, not universal.