Industry context
HVAC, plumbing, pest control, and broader home services.
Flagship Case Study
Deploying AI voice agents into live home-service operations
Production voice agents that answer inbound calls, qualify the job, and book appointments directly into CRM and dispatch systems.
Home-service businesses lose revenue every time a call rings out. This case study covers the full forward-deployed path: mapping how each business qualifies and books work, designing a voice agent around those rules, integrating telephony with CRM and dispatch platforms, and operating the system in production against real call traffic.
606 calls handled
83 booked end-to-end
$50K+ completed revenue traced downstream
ServiceTitan & FieldRoutes integrations
On This Page
Context
v
On This Page
Context
Context
Where the revenue actually enters the business
For HVAC, plumbing, and pest-control operators, the phone is the top of the funnel. Every inbound call is a job that will either be booked, deferred, or lost — and the operational machinery behind that decision spans scheduling, dispatch, service-area rules, CRM records, and callback workflows.
Operational setting
Inbound call handling, qualification, appointment scheduling, dispatch, and callback workflows.
My role
Co-Founder & Technical Lead at Playmaker — customer discovery, solution architecture, implementation, production deployment, and post-launch optimization.
What was at stake
Missed-call revenue, booking quality, dispatch efficiency, and whether the business can answer 24/7 without staffing phones 24/7.
Problem
Calls the business could not answer were jobs it could not book
The failure mode is simple and expensive: a customer with a real problem calls, nobody answers, and the first competitor to pick up wins the job. The operational reality behind it is harder — coverage, qualification, and booking each depend on people being available and making consistent decisions under pressure.
01
After-hours and weekend calls went to voicemail
Service businesses cannot staff phones around the clock. Outside business hours, callers reached voicemail — and callers with urgent problems rarely leave one. They call the next company on the list.
02
Peak-demand overflow outran the front desk
During seasonal spikes, more calls arrived than the team could answer. Overflow was invisible: the business never knew which calls it lost or what they were worth.
03
Qualification depended on who picked up
Urgency, service-area fit, membership status, and job value were assessed differently by different people. Similar calls produced different outcomes.
04
The path from call to booked job was manual
Even answered calls required a human to check availability, create or find the customer record, and book the job in the CRM. Every manual step added delay and dropped detail before dispatch.
The business did not need a phone bot that could chat. It needed a system that could carry a call all the way to a correctly booked job inside its real scheduling and dispatch workflow — or hand it to a human with full context when it should not proceed alone.
Discovery
Learning the operation before automating it
The agent's behavior had to come from how the business actually works — not from generic call scripts. Discovery meant embedding with the people who run intake and dispatch and converting their judgment into explicit, testable rules.
PHASE 01
Sit with CSRs and dispatchers
Shadowed live call handling to capture what actually gets asked, booked, deferred, and escalated — including the exceptions no script covers.
Outcome
The gap between documented process and real behavior is where deployments fail; this is where the real requirements came from.
PHASE 02
Extract the business rules
Captured service areas, urgency tiers, membership handling, pricing boundaries, and scheduling constraints from stakeholders — most of it undocumented tribal knowledge.
Outcome
These rules became the agent's qualification and booking logic, encoded per customer rather than hard-coded into the product.
PHASE 03
Draw the autonomy boundary
Defined explicitly what the agent may do on its own — book standard jobs, schedule callbacks — and what must escalate to a human, such as emergencies and out-of-policy requests.
Outcome
A conservative boundary earned operator trust first; autonomy expanded only as production behavior proved out.
PHASE 04
Agree on the success metrics
Aligned with owners on how the system would be judged: answered-call coverage, booking outcomes, and revenue from appointments the agent booked.
Outcome
Defining the metric up front kept the deployment accountable to a business outcome, not to demo quality.
Architecture
From ringing phone to booked appointment
The system is organized as a pipeline from telephony to operational outcome. Each layer has one responsibility, and every call ends in an explicit, recorded state: a booked appointment, a scheduled callback, or a human handoff with context.
Caller
Inbound call — after-hours, overflow, or front-line coverage.
Telephony
Twilio
Call routing and bidirectional audio streaming into the voice runtime.
Voice AI runtime
OpenAIElevenLabs
Understands the caller, reasons over the customer's business rules, and responds in a natural voice.
Agent orchestration
FastAPIRedis
Conversation state, qualification logic, tool invocation, and escalation decisions.
CRM, dispatch & scheduling tools
ServiceTitanFieldRoutesREST APIsWebhooks
Availability lookup, customer records, appointment booking, and callback creation.
Outcome
Booked appointment, scheduled callback, or human handoff with full context.
Records & reporting
PostgreSQLDashboard
Every call logged with its outcome for review, diagnosis, and optimization.
Telephony is handled by Twilio — call routing and bidirectional audio streaming into the voice runtime.
The voice runtime combines speech recognition, OpenAI reasoning over the customer's business rules, and ElevenLabs voice synthesis for natural responses.
FastAPI services orchestrate the conversation: state in Redis, qualification logic, tool invocation, and escalation decisions.
Operational tools connect to ServiceTitan and FieldRoutes over REST APIs and webhooks — availability lookup, customer records, appointment creation, and callbacks.
Every call and outcome is recorded in PostgreSQL and surfaced in a dashboard for review, so failures are found by inspection rather than by customer complaint.
Integrations
The integration layer is the product
A voice agent that cannot write into the business's systems is an answering machine. Most of the engineering effort lived in the integration layer — making third-party platforms behave reliably inside a real-time conversation.
01
Twilio
Inbound call routing, media streaming, and the telephony edge of the system.
02
OpenAI
Conversational reasoning, qualification against business rules, and tool-call orchestration.
03
ElevenLabs
Natural voice synthesis — the difference between a caller staying on the line and hanging up.
04
ServiceTitan
CRM and dispatch integration: customer records, job types, technician availability, and appointment booking.
05
FieldRoutes
CRM integration for pest-control operations — the same booking outcomes against a different platform's data model.
06
REST APIs & webhooks
Synchronous lookups during the call; asynchronous confirmation and follow-up events after it.
Deployment
Shipped and operated as production infrastructure
The system runs as containerized services with the same delivery discipline as any production platform — versioned, tested, and deployed through CI/CD rather than by hand.
FastAPI services packaged in Docker and deployed on AWS.
PostgreSQL for call records, outcomes, and configuration; Redis for conversation state.
A TypeScript / React (Next.js) dashboard for call review and operational visibility.
GitHub Actions CI/CD for automated build, test, and deployment.
Per-customer configuration — service areas, rules, and integrations — kept out of code so new deployments are configuration work, not forks. This pipeline cut new-tenant deployment time by 80%.
Operational Challenges
What production call traffic actually required
Live phone calls are an unforgiving runtime. The engineering that made the system trustworthy was almost entirely about failure modes, timing, and handoffs — not about the happy path.
01
Latency is a product feature
Conversational turn-taking collapses if responses lag. Response generation and speech synthesis are streamed so the caller hears the agent begin speaking without dead air.
02
Callers interrupt
Real callers talk over the agent, change their minds mid-sentence, and answer questions out of order. The conversation logic had to handle interruption and correction rather than assume a scripted flow.
03
Identity resolution against the CRM
Matching a caller to an existing customer record — without creating duplicates and without interrogating the caller — required careful lookup logic against each CRM's data model.
04
Third-party tools fail mid-call
CRM APIs time out and scheduling lookups fail while a customer is on the line. Every tool call has a fallback path, degrading to callback capture instead of a dead end.
05
Real calendars, real constraints
Booking means honoring technician availability, service areas, and job-type rules — not inventing a slot. Scheduling constraints came directly from the dispatch workflow.
06
Escalation must carry context
When a call needs a human, the handoff includes what the caller said and what the agent did — so the customer never starts over.
07
Monitoring by inspection
Calls, transcripts, and outcomes are logged and reviewed in the dashboard. Post-launch optimization is a scheduled discipline: review conversations, diagnose failures, tighten rules, and expand autonomy.
Evaluation
The system was measured, not assumed to work
A voice agent that sounds good in a demo can quietly fail in production — booking the wrong job type, mishandling an edge case, or regressing after a rule change nobody re-tested. Because every call already ends in an explicit recorded state, those states became the substrate for evaluation: the system's real behavior was measured against operational outcomes, not vibes, and regressions were caught by inspection before customers felt them.
01
Booking conversion is the number that matters
The headline metric is how often answered calls became correctly booked jobs. Grounding qualification in each business's real rules and closing gaps found in production review moved booking conversion from roughly 85% to 90% — a change measured against recorded call outcomes, not estimated from demos.
02
Outcomes are labeled, not guessed
Every call resolves to booked, callback, or human handoff, and each is recorded with its transcript. That gives a ground-truth outcome for every interaction to evaluate against, instead of sampling opinions about whether a call 'went well.'
03
Task completion and routing correctness
Beyond conversion, calls were reviewed for whether the agent captured the right job type, honored service-area and availability constraints, and escalated exactly the calls that should not proceed autonomously. Booking a job is only correct if it's the right job on a valid slot.
04
Latency treated as a measured quality dimension
Conversational turn-taking degrades if responses lag, so response and speech-synthesis timing were monitored as a first-class quality signal — a slow turn is a defect, not just a slow response.
05
Regression detection before customers feel it
Business rules, prompts, and integrations change constantly. Prior call scenarios were re-checked after changes so a fix in one area — a new pricing rule, a tightened escalation boundary — didn't silently degrade qualification or booking elsewhere.
06
The loop closes on production behavior
Review findings feed rule, prompt, and configuration changes, which are then re-measured against the same recorded outcomes. Improvement is a scheduled discipline against real traffic, not a one-time launch.
This is the difference between a demo and production infrastructure: the system earns wider autonomy because its behavior is observable, measurable, and defended against regression — not because it sounded convincing once.
Results
Measured in booked work and reconciled revenue
The deployment is judged by what lands on the schedule and what the schedule turns into. These outcomes come from two related views of the same production system — the operational dashboard the agent writes to, and the downstream ServiceTitan reconciliation — reported separately, because they answer different questions and do not share one denominator.
606 calls handled — inbound customer calls answered end-to-end by the production voice agent.
83 appointments booked end-to-end — calls where the agent completed the booking workflow directly — including 71 after-hours appointments captured while the business was closed.
~$51K in attributed booked job value, of which ~$25K was after-hours — the value of jobs tied to AI-created appointments in the operational dashboard.
Downstream in ServiceTitan: 128 jobs booked, 66 completed, and $50,283 in completed revenue reconciled back to jobs the AI booked — an average completed job value of $762.
Booked jobs land directly in the CRM and dispatch workflow with structured details, replacing manual record creation; calls the agent should not handle autonomously reach humans as clean handoffs with context, not cold transfers.
Two things matter about these numbers. First, the chain is explicit end to end — customer call → AI conversation → appointment created → job created in ServiceTitan → job completed → revenue reconciled back to the original booking — so revenue is traced, not modeled. Second, this is attribution, not incrementality: the system can prove the AI handled the call and booked the job, but not that every dollar was revenue the business would otherwise have lost. Building the instrumentation that makes that distinction honest is itself part of the work.
What This Demonstrates
The forward-deployed pattern, end to end
This deployment is the full FDE loop in one engagement: ambiguous customer environment in, measurable operational outcome out.
01
Entering a live operation, extracting how it actually works, and converting that into deployable system behavior.
02
Owning the entire path — discovery, architecture, integration, production deployment, and post-launch optimization — rather than one slice of it.
03
Integration depth across telephony, LLM orchestration, voice synthesis, CRM, dispatch, and scheduling under real-world failure modes.