The 6:40 PM Call
It is 6:40 on a Tuesday evening. A homeowner watches a brown stain spread across her living room ceiling, pulls up her phone, and taps the first roofing company in the results. Four rings, then a voicemail greeting recorded three years ago by somebody who no longer works there. She hangs up without leaving a message and taps the second company. Somebody answers. That job — a $14,000 tear-off and re-roof — now belongs to the second company, and the first company will never know it existed.
I ran a field-services business for sixteen years before I wrote software for a living, so this is not a thought experiment to me. The calls you miss do not show up in any report. There is no line item on the P&L labeled "revenue that dialed us and gave up." The owner has no idea the money was ever in the room, which is why the problem survives for years in otherwise well-run companies.
What an Answered Call Is Actually Worth
You do not have to guess at the value. The answering-service market has been pricing it for decades, and the numbers are public. PATLive runs about $235 for 75 minutes — roughly $2.65 a minute. Ruby Receptionists is around $245 for 50 minutes, close to $4.90 a minute. Smith.ai's entry plan is $300 for 30 calls, with overage at $11.50 per call.
Read that again: businesses have been voluntarily paying eleven dollars and fifty cents to have a stranger take a message. They do it because the arithmetic works. If a contractor closes one in four leads at an average ticket of $8,000, a single answered call carries an expected value in the hundreds of dollars. Against that, eleven dollars is a rounding error.
The trouble is that human answering services have a hard floor. A person has to be awake, trained, and paid, and the good ones are expensive because good ones are rare. Most small contractors look at $300 a month for thirty calls, decide voicemail is free, and quietly go on losing jobs they never counted.
What I Built, and What It Actually Does
Over the past several months I built AwakeDesk, an AI receptionist that answers a real phone number — not a chat bubble on a website that nobody clicks. It picks up on the first ring at any hour, speaks in a normal voice, asks the qualifying questions the owner would ask, checks the owner's actual Google Calendar for free and busy time, books the appointment on the calendar, texts the caller a confirmation, and texts the owner that it happened.
The important part of that sentence is "actual Google Calendar." A demo that pretends to book is a weekend project. A system that writes to the calendar a business already runs on, with the owner's real availability and real drive-time buffers between jobs, is a different animal entirely — and every hard lesson I am about to describe came from that gap between the demo and the real thing.
Four Things That Broke
The product carries 427 automated tests today. Most of them exist because something surprised me. These four are the ones worth your time, whether you are building something like this or buying it from somebody else.
- The confirmation text arrived before the agent asked permission. The booking flow collects text-message consent, and a booking made with consent immediately fires the confirmation. Reasonable design — except the language model was passing the consent flag along with a booking for a question it had not actually asked out loud yet. The caller's phone buzzed with a confirmation before the receptionist offered to text them. The lesson generalizes: a model will happily report that a step happened because the step is in its instructions, not because it performed it. If consent matters legally, the code has to enforce the ordering. You cannot ask the model nicely.
- "Sent" does not mean delivered, and carriers do not tell you why. Owner alert texts were vanishing. Twilio reported them as accepted; the phones never buzzed. It turned out to be carrier-level filtering — error 30007, message filtered — and after a controlled A/B I found the trigger: an email address in the body of the SMS. Same message, same sender, same recipient. With the address, filtered. Without it, delivered. Nobody publishes these rules and no dashboard warns you. If you are evaluating any product that promises to text you, ask the vendor what their delivery rate is, not their send rate. Those are different numbers and only one of them matters.
- Every promise in the privacy policy has to be executable code. Our policy said disconnecting the calendar revokes our access. What the code actually did was delete our copy of the refresh token and stop — which left the grant standing on the owner's Google account. The policy was a sentence; the revocation was not a function call. Google's verification reviewers could have disproved that claim in thirty seconds, and they would have been right to. It now posts the token to Google's revoke endpoint first and clears the row either way, because an outage must never leave behind a credential you told somebody you deleted. The same applied to the retention promise: "we delete transcripts after ninety days" meant nothing until there was a nightly job that did it.
- A call that never finishes looks exactly like a call whose report got lost. Thirteen calls sat unfinalized, which meant they had never been billed. My first assumption was leaked revenue. The real answer was that all thirteen were my own webhook simulations, which create a call record and never send an end-of-call report — every genuine call had finalized and billed correctly, sixteen out of sixteen. But a genuinely lost report is indistinguishable from that, so now a scheduled sweep finds calls stuck past a threshold and asks the telephony vendor directly what happened to each one. When you depend on somebody else's webhook, assume it will go missing and build the reconciliation loop up front.
The Questions to Ask Before You Buy One
AI receptionists are being sold hard right now, and the demos are all impressive because demos are the easy part. Four questions separate a product from a prototype:
Does it write to my calendar, or does it email me a request? Plenty of them collect a name and a preferred time and dump it in your inbox. That is a voicemail with extra steps. Ask to watch it create an event on a live calendar, then move it when the caller changes their mind.
What happens when the caller corrects themselves? Real callers say "Thursday at two — no wait, make it Friday morning." That single utterance broke my reschedule flow in two separate places. It is the most common thing a human being does on a booking call and where thin implementations fall apart.
How do I find out it is working? If the only way to know your receptionist booked a job is to log into a dashboard and look, you will not look. The owner needs a text on their phone when something is booked, moved, or canceled. Push, not pull.
Who verified the calendar integration? Google puts apps that touch calendar data through a security review before they will let them serve the public. Ask whether the vendor has passed it. It is slow and unglamorous, and a reasonable proxy for whether anybody has audited how your data is handled.
Build vs. Buy
For most small service businesses, this is a buy. The telephony, model orchestration, consent handling, carrier quirks, and calendar reconciliation add up to far more engineering than the problem justifies for one company.
Building makes sense in one situation: your booking rules are genuinely unusual and no product will bend to them. Multi-technician routing with skill matching, capacity that depends on equipment rather than people, jobs that legally require a licensed human to qualify the caller. In those cases the phone agent is the easy half and the scheduling engine underneath it is the actual project. That is worth scoping honestly before anybody writes code — the same test as my off-the-shelf versus custom decision framework.
Hear It Yourself
The fastest way to judge any of this is to call one. AwakeDesk runs a live demo line that answers as a roofing company: (903) 476-6062. Ask it for a Thursday afternoon, then change your mind mid-sentence and listen to what it does. That is the test I care about, and the one most demos quietly avoid.
If your booking rules are the unusual kind — multi-crew routing, capacity tied to equipment rather than people, work that legally requires a licensed human to qualify the caller — that is a custom build, not a subscription. Tell me what is breaking and I will tell you honestly which one you need. I have talked plenty of people out of software they did not require.