Call and request intake
The intake conversation is where a dispatch call succeeds or fails, so evaluate it before you look at routing logic or dashboards. Listen to how the system handles a live caller: does it capture the request as structured data — name, pickup or service location, timing, what’s needed, callback number, special instructions — or does it just produce a transcript someone still has to read and re-type? Structured capture is what lets a booking flow onto your dispatch board without a person copying details between screens.
Confirmation matters as much as capture. A good system reads the critical details back — the address, the time, the callback number — and gives the caller a natural chance to correct them. In smaller centres this is harder than it sounds. Callers describe locations by landmark rather than street address, give rural addresses or land locations, and often change their mind halfway through the call. Ask the vendor to demonstrate exactly those cases, not a scripted happy path.
A practical test is to bring your own worst calls to the demo or pilot:
- A caller who changes the time or the address partway through the call
- A rural or landmark-based location instead of a clean street address
- Background noise, a weak cell connection, or hurried speech
- Two requests in one call, or a pricing question in the middle of a booking
If the system handles those gracefully — or recognizes that it can’t and hands off cleanly — intake is doing its job.
Operational context
A generic phone bot can take a message. Dispatch is harder, because a good recommendation is a constraint problem: who is available right now, where they are, what equipment is on the truck, what they’re qualified to do, and what the customer’s account requires. Software that ignores those constraints produces bookings that sound fine on the phone and fall apart on the road — the wrong crew, the wrong gear, or a slot nobody can actually cover.
Geography deserves particular attention for prairie operators. Distances between jobs can be long, a “quick run” to an acreage or a neighbouring town can consume half a shift, and winter conditions change what’s realistic by the hour. Ask whether the system reasons about travel time rather than straight-line distance, and whether a dispatcher can adjust its assumptions when weather or road conditions shift. A recommendation engine that assumes city density will consistently overbook a rural service area.
Finally, ask where operational context lives and who keeps it current. If crew schedules, equipment lists, and customer rules have to be maintained by hand in a separate admin panel, they will drift out of date and the recommendations will quietly get worse. The best answer is that context flows from records you already maintain — schedules, job history, customer accounts — so the software is reasoning from the same facts your dispatcher would.
Integration requirements
An AI assistant that can’t write into your systems creates a new job: transcribing the AI. Every booking it takes has to land somewhere a dispatcher already works — the dispatch board, the job management tool, the calendar — with no re-keying. When you evaluate a product, trace one booking end to end and count the manual touches. Anything above zero should have a clear justification.
Integration questions worth asking directly:
- Telephony — does it work with your existing business number, and what do callers experience if the AI service is down?
- Dispatch and scheduling — does a completed intake create a job automatically, and can a dispatcher edit it afterwards?
- Messaging — can it send confirmations and updates by text, and log them against the customer record?
- Reporting — can you get your own data out, in a format you can open without the vendor’s help?
Many small operations run on a spreadsheet, a whiteboard, and a phone — and that’s fine. A good vendor meets that reality with a simple, readable handoff, such as a clean daily booking list, rather than demanding you adopt an entire new operations platform before the AI becomes useful. Be wary of tools that only shine after a rip-and-replace; the cost of that replacement belongs in your evaluation, not in the fine print.
Exception handling
Routine calls are the easy part; the buying decision should turn on exceptions. Real callers change details mid-call, describe addresses no map recognizes, mention something that sounds like a safety issue, or ask for things outside normal policy. The question is not whether the AI can handle all of that — it can’t, and no honest vendor claims otherwise. The question is whether it reliably recognizes those moments and moves them to a person quickly.
A good escalation is a warm one. The dispatcher who picks up should see who is calling, what has been captured so far, and why the system escalated — not start from zero while the caller repeats everything. Ask to watch an escalation from the dispatcher’s side, not just the caller’s, and ask how escalations surface after hours when nobody is sitting at a screen. Escalation to an empty office is not escalation.
Insist on explicit, configurable triggers: safety-related language, repeated misunderstandings, obvious caller frustration, requests that touch pricing exceptions or account disputes, and anything the system itself scores as low confidence. Then check the failure posture. When the software is unsure, does it guess, or does it hand off? In dispatch, guessing is the expensive option — a truck sent to the wrong place costs more than a thirty-second transfer ever will.
Performance measurement
Before you buy anything, establish a baseline, because “it feels better” is not a result. For a week or two, count what actually happens today: calls missed or sent to voicemail, time dispatchers spend on routine intake, bookings that needed a correction or a callback. These numbers are usually easy to gather with a tally sheet and the phone log, and they are what makes the after-picture honest.
Once a system is running, watch a small set of numbers that reflect outcomes rather than activity:
- Missed-call reduction — calls answered that would previously have gone to voicemail
- Booking accuracy — jobs created without a correction or a callback
- Escalation rate — how often calls route to a person, and for what reasons
- Dispatcher workload — hours shifted from repetitive intake to judgment work
- Customer signals — complaints, repeat corrections, and whatever satisfaction feedback you already collect
Be wary of vanity metrics. “Calls answered” means little if half of those calls end in a wrong booking, and a high “automation rate” means little if it’s achieved by never escalating. Escalation rate should trend down as the system is tuned to your operation, but it should never reach zero — zero means exceptions are being handled by software that shouldn’t be handling them. A short weekly review of these numbers is enough for most small operations; this does not require a reporting department.
Running an oilfield service company?
We wrote a dedicated oilfield dispatch software buyer's guide for Alberta & Saskatchewan — callouts, field tickets, crew and unit eligibility, and why spring breakup is the right time to switch systems.