Field service dispatch
Dispatch begins before anyone assigns a technician. The caller has to explain what happened, where service is needed, which asset is affected, whether the site is accessible, and how urgent the situation appears. If those details arrive as an incomplete voicemail, a dispatcher spends the next conversation reconstructing the request.
An AI phone agent can run the intake consistently and follow routing rules written by the service organization. It can collect and confirm the job details, query or update an approved system through an integration, and send a covered urgent call to a person. It should not diagnose equipment or invent a priority. The operating team remains responsible for safety policy, triage rules, and the final dispatch decision.
A concrete dispatch call
Consider a caller reporting water near a commercial unit's electrical equipment.
Agent: I can collect the service request and follow the dispatch team's escalation rules. Is anyone in immediate danger, and is there active fire, smoke, or sparking?
Caller: There is no fire, but water is spreading toward an electrical panel.
Agent: Do not touch the panel or enter an unsafe area. If conditions become immediately dangerous, contact local emergency services. I will mark the exact condition you reported and try the on-call dispatcher. What is the service address and the safest callback number?
Caller: It is the loading entrance at our north building. The gate is locked after hours.
Agent: I have noted the loading entrance and locked gate. Is there an on-site contact who can provide access?
The agent confirms the address, affected area, observed condition, access instructions, and callback details. It creates or updates the service record through the configured system and attempts the approved escalation. With an eligible production number, an attended warm transfer can place the caller on hold while the agent privately briefs the dispatcher. If the dispatcher declines, does not answer, or reaches voicemail, the agent returns to the caller and follows the fallback in the prompt.
The same function can support repair companies, facilities teams, rental operations, and mobile service providers without turning this page into an industry script. See the industry examples for context-specific needs.
How to configure the workflow on ThunderPhone
Write the prompt around the dispatch record your team actually needs. Define the required fields: caller and callback details, service location, affected asset, observed symptoms, access constraints, customer or contract reference, and the caller's own description of urgency. Tell the agent to repeat critical details and distinguish observation from inference. “The caller reports smoke” is usable; “the motor is failing” may be an unsupported diagnosis.
Add an explicit decision table for escalation. List the conditions that trigger an immediate transfer, the transfer target, operating-hour behavior, and the fallback when nobody accepts. Keep the table aligned with your organization's safety policy. A broad instruction to prioritize serious calls is too subjective to test.
Use an inbound demo U.S. number while testing, with the understanding that demo numbers are inbound-only and not intended for production. A live dispatch line should use an eligible production number brought through a supported direct connection or manual SIP configuration. Warm transfer requires a production number that can place an outbound SIP leg; demo numbers and browser calls are limited to cold transfer.
Connect only the systems needed for the decision and handoff:
- Use Salesforce or HubSpot when the service request belongs with an existing customer or case record.
- Use a REST integration or signed webhook for a dispatch platform, work-order system, or custom customer database.
- Use Google Sheets for a controlled intake queue when a spreadsheet is the actual operational record.
- Use Slack to alert the on-call team when an approved trigger is met.
- Use Google Calendar or Cal.com only when dispatch depends on bookable appointment availability.
- Use Zapier MCP for approved actions exposed by the connected server.
The integration should return a clear success or failure result. The prompt must not tell the caller that a technician is assigned unless the authoritative system confirms it. If the call only creates an intake record, say so plainly. For adjacent flows, urgent-call routing focuses on escalation, while phone intake forms covers structured collection without dispatch logic.
Test common jobs, ambiguous symptoms, duplicate requests, missing addresses, locked sites, unavailable dispatchers, and integration timeouts. ThunderPhone supports browser mic tests, reusable simulations, graded call logs, regression suites with minimum pass-rate gates, and live-traffic A/B experiments. Simulated calls are billable real calls, with the charge shown before a run.
What to measure
Measure dispatch readiness: the share of service records containing every field a dispatcher needs to act. Pair it with correction rate, duplicate-request rate, integration failure rate, transfer acceptance rate, and the share of jobs whose priority a human changes after review. A low handle time is not useful if dispatchers still have to call back for an address or access code.
Review urgent and non-urgent paths separately. Sample calls against the written decision table and check whether the agent captured the caller's words accurately. Track how often callers request a person and whether the call routing fallback reaches the right destination.
Honest limits
An agent cannot inspect the site, verify physical danger, diagnose equipment, estimate an arrival without authoritative availability, or replace a trained dispatcher during a complex incident. Emergency instructions must come from the organization's approved policy, and callers facing immediate danger should be directed to local emergency services.
Humans should handle uncertain safety conditions, priority conflicts, high-value authorization, technician reassignment, and any promise involving scope, price, or arrival time that the connected system cannot confirm. The best automation produces a cleaner decision point; it does not remove operational judgment.