AI Dispatch Software That Follows Your Dispatching Rules
Dispatching is a judgement call made forty times a day. Who is nearest, who is qualified, who has the part on the van, who the customer had last time, which job can slip and which cannot. Experienced dispatchers hold all of that in their head and are very good at it, which is precisely why most dispatch software disappoints: it automates a simpler version of a decision the person was already making well.
The useful question is not whether software can dispatch for you. It is whether it can hold your rules — the real ones, including the awkward ones — and then take the routine 80% off the dispatcher's desk so they can spend the day on the 20% that actually needs a human.
Running this manually today?
See how Fieldproxy handles it — a walkthrough on your own workflow, not a canned demo.
Book demoWhat dispatch has to account for
The inputs a real assignment decision uses:
- Skills, tickets and certifications, including which engineer is allowed to sign off which work
- Travel time on real roads at the real time of day, not straight-line distance
- What is physically on the van, which decides whether it is a fix or a return visit
- Customer history and the engineer who has been there before
- Contractual response times, and which jobs are close to breaching one
- Which booked jobs can be moved, which cannot, and who has to be told if they are
- Working patterns, overtime rules, standby rotas and who is genuinely available
Why automated dispatch usually gets switched off
Most automated dispatch is optimising for the wrong thing. It minimises drive time, which sounds correct and is only part of the job. A schedule with the lowest total mileage can still send an unqualified engineer, break a contracted response window, or move a customer who has already been moved twice.
When that happens a few times, dispatchers stop trusting the suggestions and go back to doing it by hand, and the software becomes an expensive calendar. The way round it is not a better algorithm. It is an algorithm that is running your rules, with the constraints that actually matter to your business expressed as constraints rather than as preferences.
Software that is told how you dispatch
Fieldproxy is built around your dispatching model rather than a generic one. Your skills matrix, your priority ordering, your response commitments, your rules about who can be moved and who cannot. It is not configured by choosing between a few scheduling modes. It is told how your operation decides, and then it decides that way.
That includes the rules nobody puts in a product spec. One customer who must never be sent a particular engineer. A site that needs two people after dark. A client whose SLA clock starts when they email rather than when you accept. On a fixed product these become exceptions the dispatcher holds in their head; here they are just part of the model.
Things usually fixed elsewhere and yours here:
- The skills and certification matrix, and how strictly it is enforced
- Priority ordering — what outranks what, and when
- Response-time targets per client or contract, with warnings before a breach rather than after
- Which jobs may be auto-moved, which require a human, and who gets notified
- How travel, working patterns and overtime are weighed against each other
- The dispatch board itself — what a dispatcher sees, and in what order
Running a field service team of 5 to 50 people?
Fieldproxy is AI-native field service software built around how your business already works: your job types, your checklists, your approvals. Every plan includes unlimited users. Book a demo and we will walk through it on your own workflow.
Book a demoHow this compares to a fixed product
Two approaches to the same problem
| A fixed product | A configured platform | |
|---|---|---|
| Assignment logic | The vendor's algorithm, with some weighting | Your rules, expressed as rules |
| An awkward exception | Held in the dispatcher's head | Part of the model |
| Response-time commitments | Reported on afterwards | Enforced before the breach |
| When rules change | Wait for the roadmap | Changed in days |
| Best when | Your dispatching is fairly standard | Your rules are specific and you have a lot of them |
What you can run on it
- A live dispatch board and map showing the day as it actually stands
- Assignment suggestions that respect skills, stock, travel and contractual commitments
- Emergency insertion that reshuffles the day and tells everyone affected
- Response-time tracking with warnings before a target is missed, not after
- Engineer mobile app with offline working
- Reporting on utilisation, travel, first-time fix and response performance
When this is the wrong choice
With a handful of engineers and a simple service, a dispatcher and a shared calendar works perfectly well and software is overhead. This approach pays when the rules have become too many to hold reliably in one head, and when getting an assignment wrong has a contractual cost rather than just an inconvenient one.
Common questions
What is field service dispatch software?
It is the system that decides and records who goes to which job, when. At minimum it holds the schedule; the useful versions also account for skills, travel, van stock and contractual response times, and can reshuffle the day when something urgent arrives.
Does it dispatch automatically or does a person still decide?
Both, and the balance is yours to set. In most operations the sensible arrangement is that routine assignments are made automatically against your rules and the dispatcher handles the exceptions. Full automation tends to get switched off when it optimises for drive time at the expense of something that mattered more.
Can it account for what is on the van?
Yes, and it is frequently the difference between a fix and a return visit. Van stock can be a constraint on assignment rather than something discovered on arrival.
How does it handle emergencies?
An emergency is inserted into the existing day rather than appended to it, the affected jobs are moved according to your rules about what may move, and the people affected — engineers and customers — are notified. The moved jobs stay tracked so a repeatedly postponed customer is visible.
Can it warn us before we miss an SLA?
Yes. Response-time targets are held per client or contract and surfaced while there is still time to act, which is the only point at which the information is useful.
How long does it take to set up?
Days rather than months. The longer half is usually writing down your dispatching rules explicitly for the first time, which most operations have never actually done.
See it running your dispatch rules
Bring the awkward cases — the exceptions your dispatcher holds in their head. Those are the fastest way to see whether this fits.
Book a walkthrough