Dispatch & the Day of Service

Route Optimization produces a plan. Dispatch is everything that happens to it after that: a person checks it before the day starts, fixes what the solver couldn't know, and then keeps it working while technicians call in sick, stops run long, customers cancel from their driveway and a thunderstorm rolls over half the branch. The optimizer is good at the first draft. The day belongs to people, and the system's job is to make their changes fast, safe and visible to everyone affected, including the customer.

The Role#

Every branch has someone who owns the routes. The title varies (dispatcher, scheduler, route builder, route performance specialist, or the office manager in a small branch), and so does the scope, but the work is the same:

• Before the day: review generated routes, fix what doesn't look right, assign or swap technicians, and lock routes once they're final.
• During the day: absorb changes, rebalance routes, add urgent work, and answer the field ("my 2 p.m. isn't home, what next?").
• After the day: close out routes, chase stops that weren't completed, and make sure missed work goes back into the backlog with a reason.

Two design consequences follow. First, the dispatcher needs the same rules the booking engine and optimizer use. If the board lets a dispatcher drop a termite job on a technician without the termite skill, or a stop in a county where the technician isn't licensed, the system has three sets of rules and they'll disagree. Second, the dispatcher's actions are high-impact and fast, so everything they do needs an audit trail. "Who moved my 9 a.m.?" is a question the system must answer.

A Route's Day#

A route is one technician-day of work for a branch: an ordered set of stops with planned times, assigned to a primary technician (and sometimes a second technician or a trainee), with required skills, a stop cap and a lock. It moves through the day in a clear order, with the lock as a separate switch:

• Built: created by the batch plan or by hand, with stops assigned.
• Optimized: sequenced with planned arrival times.
• Dispatched: final for the day and visible on the technician's app. Customers have their arrival windows.
• In progress: the technician has started work. Started and completed stops are fixed.
• Closed: every stop is completed, cancelled, or released back to the backlog with a reason.

The lock says who may change a route. An unlocked route is fair game for automatic scheduling and the optimizer. A locked route can only be changed by a person, on purpose. Locking is how a dispatcher protects a route they built by hand, and how the system protects routes after a weather stand-down. Keep the lock and the progression separate: a route can be in progress and unlocked (so in-day optimization can still reorder it), or optimized and locked (because a person finalized it the night before).

One more distinction matters: releasing a stop is not cancelling it. Releasing takes an appointment off a route and returns it to the backlog to be placed elsewhere; the customer's appointment still exists. Cancelling ends the appointment. Mixing the two up loses work: a dispatcher clears a route for a sick technician, and twenty customers' appointments disappear instead of moving.

The Dispatch Board#

The dispatch board is the dispatcher's main tool: routes as columns or rows (usually a timeline per technician, plus a map), with stops as cards that can be dragged between routes and times. It's a direct-manipulation UI over the same domain operations the API exposes, and it should be built that way:

• Validate every move with the real rules. Only show drop targets that would be valid: a technician who has every skill the stop needs, is licensed where the property is, has a shift that covers the time and isn't over the stop cap. An invalid drop explains itself ("no termite certification") instead of just bouncing back.
• Optimistic updates, with a server that can say no. The board should feel instant, so apply the move locally and send it. The server checks the same rules plus concurrency: if someone else changed the route since the board loaded it, the move fails and the board reloads that route. Transactions & Concurrency covers the version checks behind it.
• Lock and unlock per route, with a reason.
• Move and swap technicians. Moving a whole route to a different technician (a sick call, a truck breakdown) is one operation, not forty card drags, and it re-validates skills and licensing for every stop on the route. A technician can't be on two overlapping routes.
• Re-optimize a route on demand, after manual changes, respecting pins and what customers were already told.
• History. Every route keeps a history of changes: who, when, what moved and why. Show it on the board.
• Live presence. When two dispatchers have the same branch open, show it. It's cheaper than resolving their conflicting changes.

Whether a stop may move to a route from a different branch is a business decision. Some companies let neighboring branches lend each other technicians; others forbid it because branches are separate profit centers or separately licensed businesses. Make it a rule, not a hard-coded assumption.

Same-Day Changes#

Something changes on almost every route, every day. The common cases, and what each needs:

Change	What the system does
Technician out	Move or split their route across others, revalidating skills and licensing; release whatever doesn't fit back to the backlog
Stop runs long	Recalculate the rest of the route's arrival times; warn about any stop that will now miss its window
Customer cancels or isn't home	Record the reason, release or cancel the stop, close the gap with in-day re-optimization
Urgent work added	Find the routes that can absorb it within windows; let the dispatcher choose
Arrival time moves	Notify the customer, once, with the new time

The last row is where customers feel dispatch. A customer whose arrival time moves needs to hear about it, and a customer whose appointment was cancelled must not get the reminder that was queued for it. Both are event-driven: route changes emit events (appointment rescheduled, cancelled, same-day adjusted), and Customer Communications turns those into messages, retracts any queued reminders that no longer apply, and applies consent and quiet-hours rules. Two rules keep it civil:

• Notify on meaningful change only. A stop moving ten minutes inside its window isn't news. A stop moving out of its window, or to a different day, is.
• Coalesce. A dispatcher rebuilding a route makes many changes in a few minutes. Send one message per customer about the final result, not one per drag.

Weather Stand-Downs#

Outdoor work stops for weather, and in some trades the rule isn't just comfort. Pesticide labels are legal documents, and EPA works with registrants to put conditions such as minimum and maximum wind speeds on them, so an exterior application in the wrong wind may not be permitted at all. Lightning, flooding, snow, extreme heat and cold, wildfire smoke and high winds all stop work across a whole area at once.

A stand-down is a branch-level decision: no outdoor work in this area today (or this afternoon). It touches every route and every customer in the area, so it must be one operation, not a dispatcher spending the morning dragging cards:

1. Declare the incident for a branch (or set of areas) and a time range, with a type: thunderstorm, flood, snow, strong wind, extreme heat, extreme cold, fire, other.
2. Move the affected routes to the next working day that isn't excluded, keeping the route intact where possible. A route that can't move whole (a stop with a fixed date, a commercial contract) is split: the movable stops go, the rest stay.
3. Lock what's left on the stand-down date, so automatic scheduling and the optimizer don't refill it.
4. Notify customers with a weather-specific message and the new date.
5. Block rebooking onto the stand-down date: the date becomes an exclusion in scheduling until the incident is lifted.

Do steps 2 to 5 in one transaction, or as one idempotent job that can resume, and make the incident a record you can lift or extend. An incident that ends early should let the dispatcher reopen the afternoon without undoing the morning's moves by hand.

Weather data helps detect and justify stand-downs. The US National Weather Service API is free (with a required User-Agent header and unpublished rate limits) and provides active alerts by state and by forecast zone, plus gridpoint forecasts for any latitude and longitude. A system can flag branches with active severe-weather alerts for the dispatcher to decide on. Keep the decision with a person, because whether work is safe or allowed depends on the trade, the product and the local conditions.

Record the weather at each service, too, where regulation asks for it; Proof of Service covers which records go on the service slip.

Where the Trucks Are#

Telematics devices in vehicles report location, speed and driving behavior. Dispatch uses them in three ways.

Location

Vehicle location answers "where is everyone right now" on the dispatch map, and feeds better ETAs than the plan alone. Telematics providers expose it as an API: Samsara, for example, offers a latest-location snapshot, a historical range, and a cursor-based feed that returns only updates since the last cursor, so a client recovers from a dropped connection without missing points. Its guidance is to wait at least 5 seconds between feed requests once caught up. Store positions as a time series, keyed by vehicle, and join to technicians through the route assignment, not through a fixed vehicle-to-person mapping, because people swap trucks.

ETAs and "On My Way"

An arrival estimate is drive time from the technician's current position (from telematics or the app's GPS) to the next stop, via the routing engine, plus the remaining time on the current stop. Customers value it far more than an arrival window alone. Two messages carry it:

• On my way, sent when the technician leaves the previous stop or taps a button, with the estimate and ideally a live tracking link.
• Running late, sent automatically when the estimate falls outside the customer's window, before the customer has to call.

Both are transactional messages tied to an appointment, subject to the consent and timing rules in Customer Communications. A tracking link should expire when the stop completes and show the technician's position only while they're on the way to that customer.

Driving Behavior

Telematics also detects risky driving. Samsara's safety events, for example, include harsh acceleration, braking and turning, speeding and crashes from the vehicle gateway, plus rolling stops, following distance and distracted driving from dash cameras, each with links to footage. These feed fleet safety and coaching (Fleet, Inventory & Safety) more than dispatch, but a crash event is a dispatch event: the technician's day is over, and their route needs redistributing.

Tracking People Is Regulated

Tracking a vehicle is tracking the person driving it, and some states regulate it. New Jersey, for example, makes an employer who knowingly uses a tracking device in a vehicle used by an employee without giving written notice subject to civil penalties of up to $1,000 for a first violation and $2,500 for each one after; the law applies whether or not the employer provides the vehicle, and excludes devices used only for expense reimbursement. Give written notice everywhere as a baseline, check each state you operate in, and limit what dispatch shows to working hours: a technician who takes the truck home isn't on the map at 9 p.m.

The Live Board#

Branches, regions and headquarters want to see the day as it happens: stops started, completed, sales signed, how each branch is doing against its plan. A live operations board on a wall screen is cheap to build from domain events and good for morale, with a few rules:

• Built from events, not queries. Subscribe to appointment started and completed, route changes and sales events, aggregate in memory or a cache, and push to screens over server-sent events or WebSockets. Polling the operational database from every wall screen in the company is a self-inflicted load test.
• No customer data. Screens sit in offices, break rooms and lobbies. Show technician first names, branch and city, never customer names, addresses or phone numbers. Design the event payloads the board consumes so they can't leak it, rather than filtering in the UI.
• A defined day. "Today" must reset at a defined local midnight. For a company spanning time zones, choose per branch (each branch's own day) or one company day, and say which on the screen. Time & Date Formats covers why that choice has to be explicit.
• Verified sources. If the board accepts webhooks, verify signatures and reject stale deliveries, like any webhook consumer (Webhooks).

Handoffs Between the Field and the Office#

Some problems found in the field can't be solved there: a customer dispute, a damaged property, a billing question, a request the technician can't handle. Some problems reported to the contact center need someone in the field. Either way, the work crosses teams, and it gets lost unless it's tracked as a case with an owner:

• A case has a type, the account and appointment it concerns, who raised it, who owns it now, and a state: open, investigating, waiting on the customer, resolved, closed.
• A service level sets how fast each step must happen, counted in business hours for the team that owns it. My default is acknowledgment within a few business hours and resolution within one business day for routine field-to-office handoffs, with faster targets for safety and damage cases.
• Escalation is automatic. A case that breaches its acknowledgment or resolution target moves up a level (branch manager, then regional manager) without anyone having to notice.
• The customer's record shows it. The contact center, the dispatcher and the technician's app should all see open cases on the account, so nobody promises something the other team already refused.

Cases are also where field feedback reaches the office: a technician flagging an aggressive dog, a locked gate, or a customer who wants to cancel. Route that last one to retention immediately (Collections & Retention); a cancellation request that sits in a queue for two days becomes a cancellation.

What This Means for the System You Build#

• One set of assignment rules shared by booking, optimization and the dispatch board.
• Routes with a progression and an independent lock, and release distinct from cancel.
• A dispatch board on top of the domain API, with validated drop targets, optimistic updates, concurrency checks, route-level moves and swaps, and history.
• Same-day changes as events, with coalesced customer notifications and retracted reminders.
• Weather stand-downs as one atomic operation: move, split, lock, notify and block rebooking, with a lift.
• Telematics as a time series joined through route assignments, with written notice and working-hours limits on tracking.
• ETAs and on-my-way messages from current position and the routing engine, with expiring tracking links.
• A live board built from events, with no customer data and an explicit definition of today.
• Cases with owners, business-hour SLAs and automatic escalation for every field-to-office handoff.

References#

Specifications

• New Jersey P.L.2021, c.449 (A3950), written notice before using a tracking device in a vehicle used by an employee, and its civil penalties

Reference

• EPA: Improving Labels to Reduce Pesticide Drift, label language on drift factors including minimum and maximum wind speeds
• NPIC: Pesticide Labels, labels as legal documents, and use inconsistent with labeling as a violation of federal law
• National Weather Service: API Web Service, free alerts by state and zone, gridpoint forecasts, and the required User-Agent header
• Samsara: Vehicle Locations, snapshot, history and cursor-based feed, and the 5-second wait between feed requests
• Samsara: Driver Behavior, safety events from vehicle gateways and dash cameras