How AI dispatch decides which technician goes where

What does AI dispatch actually decide?#

AI dispatch decides three things together: which technician takes a job, the order of that technician's stops, and the arrival window the customer is promised. A dispatcher makes the same decisions on a board every morning; the software tries to make them faster and to re-plan when the day changes.

Simple auto-assign rules, such as sending the closest available technician, are not the same thing. AI dispatch weighs many factors at once and keeps re-scoring as jobs run long, emergencies come in or a truck breaks down. A sensible start is suggestion mode, where the system proposes assignments and dispatchers keep the final say.

The inputs AI dispatch weighs#

AI dispatch weighs inputs drawn from your field service system, your telematics and your technician records. Each input fails in a predictable way when it is missing or stale, and the table shows where each one usually comes from.

Not every input carries the same weight. Skills, certifications and the promised window usually act as hard limits that a suggestion may not break, while drive time, workload balance and customer priority are traded against each other. Decide which inputs are hard limits in your business before turning anything on, because that choice shapes every suggestion the system makes.

How the decision gets made, step by step#

The decision runs as a filter followed by a ranking. Hard limits remove technicians who cannot take the job at all, then the remaining options are scored on the trade-offs a dispatcher would weigh by instinct.

• 1Filter: drop technicians without the skill, certification or license level the job type requires.
• 2Estimate: predict how long the job will take for each remaining technician, based on similar past jobs.
• 3Route: calculate drive time from where each technician will be when the current job ends.
• 4Score: weigh arrival window risk, customer priority, workload balance and the chance of a first-visit fix.
• 5Propose: show the top assignment and route to a dispatcher, or assign automatically for routine work.
• 6Re-plan: repeat the scoring when a job runs long, an emergency is booked or a technician goes off schedule.

Why your historical records make dispatch smarter#

Historical records make dispatch smarter because every prediction in the loop is learned from what happened before. A vendor's default duration for a furnace tune-up is a guess; your own completed jobs show how long that tune-up takes on the equipment your customers actually own.

Callbacks matter for the same reason. A return visit soon after the first one often means the first technician lacked a skill, a part or enough time, and that pattern can teach the system which matches to avoid. It only works if the callback is booked against the original job rather than as a fresh service call.

Where dispatch history usually breaks down#

Dispatch history breaks down most often at the timestamp. When technicians tap on my way, start and complete in a batch at the end of the day, durations look identical and the system learns nothing. Short training and a quick weekly spot check fix more than any new setting.

Generic job types are the second problem. If half of all work is booked as a service call, the system cannot tell a thermostat swap from a heat exchanger inspection. Splitting the most common types into specific ones pays off quickly.

The third is lost history. Overrides made by phone leave no reason in the record, skills matrices go stale when people earn new certifications, and a software migration can leave years of completed jobs behind. Export and keep the old history even after you switch systems.

Illustrative: a mechanical contractor tests dispatch suggestions#

Illustrative: a fictional HVAC and plumbing contractor runs its board with two dispatchers who know every technician by heart. Its COO trials a dispatch optimization tool in suggestion mode and compares the tool's picks with the dispatchers' choices for a full heating season.

The suggestions are good for maintenance visits and weak for older boilers, where real jobs run far longer than the defaults. The team splits boiler work into its own job types, adds a reason field for every override, and updates the skills matrix after a round of certifications.

By the end of the season, dispatchers accept most suggestions for routine work and keep manual control of emergencies and complex diagnostics. The override reasons become the most useful part of the record, because they explain decisions the old board never captured.

How SourceX looks at dispatch records#

SourceX sees dispatch history as a record of real planning decisions under constraints, with outcomes attached. AI developers building scheduling and planning agents look for that pattern: a request, the options, the choice made and what happened next.

The SourceX Enterprise Data Value Framework weighs how well dispatch, job and callback records link together, how much history survives and how cleanly technician and customer details can be removed. Any license moves through the SourceX five-step transaction, Supply, Rights, Preparation, Approval and Delivery, with the company approving each step. Records are licensed, not sold.

Preparation for dispatch records is specific. Technician names become stable pseudonymous IDs so patterns survive without identifying anyone, customer addresses are reduced to a coarse service area, and free-text override reasons are reviewed for names and phone numbers before anything leaves the company.