The dispatch stack for high-mix service teams

Dispatch AI fails when it optimizes the route but ignores the promise the dispatcher made before the day started.

A field-service memo on choosing the first dispatch workflow to instrument before adding optimization software.

The hidden constraint

Most dispatch tools show the clean part of the operation. They show jobs, locations, routes, and technician capacity.

The expensive constraints sit one layer below the schedule. They live in notes, callbacks, parts uncertainty, customer promises, and the dispatcher's memory.

A customer window was promised before the job was fully scoped.

A part is technically available but sitting in the wrong truck.

A technician is certified for the asset but weak on the failure mode.

A callback looks routine until the same site appears three times in two weeks.

What to automate first

Do not start with full schedule control. Start with the exception list the dispatcher already builds mentally.

The first AI surface should flag jobs that deserve human review before the route is locked.

Jobs with missing parts confidence.

Jobs with customer commitments that conflict with travel reality.

Repeat sites with unresolved root cause.

Technician assignments that match skill broadly but not specifically.

The metric that matters

Route efficiency is a weak first metric because it hides rework. A plan can look efficient at 7:00 a.m. and collapse by 10:30 a.m.

Measure whether the system reduces changes after the schedule is committed.

Changed-once rate after daily release.

Callbacks flagged before assignment.

Jobs moved because of missing information.

Dispatcher review minutes per exception.

Decision rule

The system sees job context, technician constraints, customer commitments, and unresolved exceptions.

The dispatcher can override every recommendation with a reason code.

The team tracks fewer same-day changes, not just prettier routes.