A dispatch agent that reads every service request before the office opens

Business context

Northgate Climate Services runs residential heating and cooling across a metro area with 22 field technicians and a four-person office team. Demand is spiky: a heat wave can triple inbound volume in a single morning.

The bottleneck

Every service request arrived in one of three places: the office inbox, a web form, or a voicemail box that only two people could access. Someone had to listen to each voicemail, retype the details, decide whether it was an emergency, and then find a technician.

During peak weeks the queue reached 200 unread requests. Customers who called a competitor got a callback first, and Northgate never knew which jobs it lost.

What existed before

• Three intake channels with no shared queue
• A dispatcher manually transcribing voicemail during the busiest hours
• No record of which requests were urgent versus routine
• No way to tell whether a slow response cost them the job

Solution architecture

The system watches all three channels and normalizes them into one request record. Each record is enriched with the customer's service history, property type, and equipment age.

A reasoning step then extracts the structured fields a dispatcher actually needs: address, unit type, symptom, urgency signals, access instructions, and preferred window. Those fields are written to a staging table before anything reaches the dispatch board, so the office team can see exactly what the agent inferred and correct it in one click.

Requests that match a known fault pattern route straight to the dispatch queue. Anything ambiguous, missing a service address, or describing a safety concern routes to a person with a short summary of what was unclear.

Agent behaviour

The agent has three jobs and no others:

1. Read unstructured text and produce the structured fields listed above.
2. Decide whether the request matches a known pattern confidently enough to dispatch.
3. Write back a plain-language summary so a human can audit any decision.

It cannot message a customer, change a price, or cancel a job. Those remain human actions by design.

Rollout

• Week 1 to 2: Mapping every intake path, including the voicemail box nobody wanted to admit they used.
• Week 3 to 5: Building the extraction and routing pipeline against a backlog of 1,400 historical requests.
• Week 6 to 7: Running in parallel with the manual process. The dispatcher kept working as before while the agent produced the same records in the background.
• Week 8 to 9: Turning on the dispatch board for matched requests and keeping the human queue for everything else.

Before and after

Step	Before	After
First contact	Callback within a day	Acknowledgement in minutes
Triage	Manual transcription	Structured record created automatically
Routing	Dispatcher decides on the fly	Pattern match, with a human queue for edge cases
Visibility	No queue reporting	Volume, response time, and escalation rate tracked

Business result

During the pilot the median first response fell from nine hours to eleven minutes. The office team recovered roughly fourteen hours a week that used to go into transcription, and the same lead volume produced 38% more booked jobs.

The more useful number was the escalation rate: 21% of requests still ended with a person, which is where it should be for work that involves someone's home.

Lessons learned

• Voicemail was the real bottleneck, not email. Nobody had measured it.
• Extraction quality matters more than routing logic. If the fields are wrong, the dispatcher stops trusting the whole system.
• The parallel run was worth the extra two weeks. It turned a risky launch into a boring one.