Custom Software With an AI Voice Agent That Books Jobs: Feasibility, Cost, and the Parts Nobody Quotes

What this really involves once real callers touch it

A voice agent that books jobs is a distributed write path running under a hard 800 millisecond conversational deadline, driven by an unreliable narrator (the caller), over an 8 kHz phone line, into a calendar that other humans are editing at the same time.

Here is the exact failure we have cleaned up more than once. Friday 4:50pm. The agent is on the phone, the caller accepts the last Tuesday 2pm slot, and the agent fires book_job into the field service CRM (Customer Relationship Management). The CRM takes 9 seconds because Friday afternoon is its peak. The HTTP client times out at 8 seconds and retries. Both writes land. The agent says "you're all set for Tuesday at 2." Monday morning dispatch sees two jobs, same address, same slot, two different job IDs, and sends two trucks. The caller gets two confirmation texts and calls back angry, which the voice agent answers, and it has no idea either job exists because it reads availability, not duplicates.

Nothing in that chain is exotic. It is a missing idempotency key and a tool timeout that nobody budgeted for. That is the shape of every real problem in this build: the language model works fine, the systems engineering around it is where the money goes.

The latency budget, and why your demo sounds better than production

Callers tolerate roughly 800 milliseconds of silence before they think the line dropped and start talking again. That budget has to cover endpointing (waiting to be sure the caller stopped talking, typically 300 to 700ms of trailing silence), the final speech-to-text result, model time to first token (300 to 600ms), text-to-speech time to first byte (75ms on ElevenLabs Flash, higher elsewhere), and network. You are already over budget before a single database query.

Competent builds attack it in specific places. Stream everything, and start TTS on the first sentence boundary rather than waiting for the model to finish. Tune endpointing per intent: an address needs a longer silence window than a yes or no, because callers pause mid address. Configure barge-in so the caller can interrupt, then handle the thing that ruins naive barge-in, which is backchannel. When the caller says "mhm" or "yeah" while the agent is speaking, a plain voice activity detector treats it as an interrupt and stops the agent mid word. You need a short classifier or a minimum-duration plus confidence gate before you cancel the response and flush the audio queue.

The one that surprises everyone: your demo ran at 24 kHz over WebRTC from a laptop microphone. Production runs over PSTN as G.711 mulaw at 8 kHz, narrowband, with carrier compression. Street names, unit numbers, and postcodes degrade badly. "Fifteen" and "fifty" become a coin flip. The fixes are keyword boosting on your actual local street list and service catalog, a numeric readback confirmation before any write, and a DTMF fallback so the caller can key the house number on the keypad. If a vendor has not mentioned mulaw to you, they have only ever demoed this.

Booking is a write, not a conversation

The single most important architectural rule: the language model never computes availability, never quotes a price, and never decides a slot. It calls a scheduler that owns those decisions, and it speaks the scheduler's answer. The moment availability logic lives in the prompt, you are one model update away from confidently invented appointments.

What that scheduler owes you:

• Soft holds. Before the agent says the words "Tuesday at 2," write a hold row with a 90 to 120 second expiry. Two callers racing for the last slot is not a rare event on a Monday after a storm, it is a weekly one. A unique constraint on (technician_id, slot_start) plus a row lock is the difference between a real system and a demo.
• Idempotency keys. One key per call leg plus intent hash, honored by your own API and passed to the CRM where supported. This is what would have prevented the two-truck scene above.
• At-least-once webhooks. ServiceTitan, Jobber, and Housecall Pro all deliver webhooks with retries and without ordering guarantees. Reconcile on job ID and updated timestamp, never on arrival order, and expect to receive the same event twice.
• Real constraints. Drive time between the previous job and this address, technician skill matrix, parts availability, and business unit capacity. If your slot logic ignores drive time, dispatch will override every booking the agent makes and the project quietly dies within a month.

Then there is the tool call clock. You have about 1.5 seconds before the silence is audible. Competent builds stream a filler line ("let me check the calendar for that") the instant the tool fires, set a hard 4 second deadline, and on breach fall back to a human transfer or a callback promise rather than dead air. Warm transfer means SIP REFER to a real queue with the transcript pushed ahead of the call, not "please hold" followed by a ring into nothing.

Telephony and compliance, the line item nobody quotes

This is where fixed-price quotes from generalist shops go wrong, because none of it is visible from the product spec.

STIR/SHAKEN. Outbound callbacks and confirmations need proper attestation, or carrier analytics engines label your number "Spam Likely" and answer rates collapse. You register the numbers, you keep the attestation level at A, and you monitor reputation.

A2P 10DLC. Confirmation texts from a local number require brand and campaign registration with The Campaign Registry through your carrier. Vetting takes days to weeks and gates your throughput tier. Start it in week one, not the week before launch, because it is the most common cause of a slipped go-live date on this capability.

Recording consent. Two-party consent states including California, Illinois, Florida, Pennsylvania, Massachusetts, and Washington require disclosure before recording, which means the disclosure has to be in the recording, spoken by the agent, before anything else. Your consent state logic keys off the caller's number, and you need a policy for numbers that do not resolve.

AI disclosure and TCPA. Synthetic voice on outbound calls falls under artificial voice rules, and several states now require the agent to identify itself as AI. Build the disclosure into the first turn and keep it configurable per jurisdiction. Also tune answering machine detection: false positives hang up on live humans, and the default settings are tuned for dialers, not for a booking agent.

Grounding and the evaluation harness you cannot skip

Prompt changes are code changes with no compiler. The only thing that catches a regression is a fixture set of real recorded calls, replayed through the actual pipeline including the mulaw path, asserting on the tool calls made rather than on transcript wording. We build 150 to 300 fixtures for a production agent: accents, background noise, a barking dog, a caller who changes the address halfway through, a caller who asks for a price the agent must not give, and a caller who says "actually never mind."

Pin model versions explicitly. Voice and language model endpoints get deprecated on the provider's schedule, not yours, and an auto-upgraded model that changes its tool-calling behavior will find out in production if you did not.

Observability for voice is its own build. You need one timeline per call with audio, transcript, tool calls, latency per turn, and the scheduler decision, all aligned. Without it, "the agent messed up my booking" is unfalsifiable and you will spend weeks guessing.

Cost and timeline, from Digital Heroes delivery experience

Across 2,000+ projects, this capability lands in three bands.

$15,000 to $60,000, 5 to 9 weeks: adding the voice agent to a product that already has a working scheduler, a job model, and an API. You are building the voice layer, the tool contract, holds and idempotency, the eval harness, and the compliance path.

$50,000 to $130,000, 10 to 16 weeks: voice agent as part of a first release, where the scheduling engine, dispatch view, and CRM integration are being built alongside it.

$150,000 to $350,000, 6 to 12 months: a multi-tenant platform where each customer has their own catalog, pricing rules, technicians, phone numbers, and compliance profile.

What specifically drives this capability's number up, in order of impact: the number of downstream systems the agent writes to (each CRM is its own auth model, rate limit, and duplicate behavior, and the second integration costs almost as much as the first); real dispatch constraints like drive time and skills matrices; multi-language, since Spanish plus English roughly doubles the eval corpus and the prompt surface; regulated outbound calling; and the size of the fixture set you are willing to fund. Run cost is separate and small by comparison: all in, telephony plus speech-to-text plus model plus text-to-speech typically lands around $0.10 to $0.25 per minute at public list prices, so a shop taking 400 calls a month at 3 minutes each is spending roughly $120 to $300 a month on inference and minutes.

When you should not build this

If you are a single-location trades business under about 150 calls a week, running a stock Jobber, Housecall Pro, or ServiceTitan setup, do not build this. Buy Rosie, Goodcall, Slang.ai, or Avoca at roughly $50 to $500 a month, spend a day on the configuration, and put the $40,000 into a second van. Those products already carry the 10DLC registration, the consent handling, and the carrier reputation work, and their booking logic is good enough when your scheduling rules are "any tech, any slot."

Build custom in exactly three situations. One: your scheduling logic is a real constraint solver that no off-the-shelf agent can reach, involving drive time, part inventory, certifications, or SLA windows. Two: you are the software vendor and the voice agent is a feature you resell to your own customers, which makes multi-tenancy and margin per minute your problem by definition. Three: your CRM is homegrown or heavily customized, so no vendor integration exists and you would be paying them to build one anyway.

The middle case, a growing operator with 200 to 500 calls a week on a standard CRM, should start with the managed product for 90 days, measure the booking rate and the containment rate, and only then decide. That data makes the custom build brief itself.

How to brief and vet a developer for this

Brief them with numbers, not adjectives: calls per week, peak hour concentration, average handle time, which CRM and which API version, the states you operate in, the constraints a booking must respect, and what happens today when a booking is wrong. Then ask these, and listen for specifics rather than reassurance:

• What is your p95 turn latency target, and what is in it? Anyone who cannot break the number into endpointing, model, and TTS has not measured it.
• How do you tell barge-in from backchannel? "We use VAD" is the wrong answer.
• Two callers want the last 2pm slot at the same second. Walk me through the writes.
• The CRM booking call times out at 8 seconds. What does the caller hear, and how many jobs exist afterward?
• How does 8 kHz mulaw change your address capture, and what do you do about it?
• Show me your evaluation set. How many fixtures, and do they assert on tool calls or on text?
• Who owns the 10DLC registration and when does it start?
• How does the agent handle a price question it must not answer?

A developer who has shipped this will get animated on at least three of those and will have a story attached to each. A developer who has not will talk about the model. The model is the easy part.