Voice agents: the four-question intake before we build

A receptionist at a dermatology clinic in Utrecht picks up the phone for the 41st time before lunch. Two of those calls were the same patient asking when her biopsy result would land. Three more were people trying to book an annual check; she sent two to voicemail because there was a real patient at the counter. By 14:00 the practice manager will email us about a voice agent.

We agree it might help. But we will not quote one until we have worked through four questions with whoever signs the contract. About half the clinics and law firms that ask us about a phone agent do not have a project we can responsibly build, and the four questions surface that in roughly forty minutes.

What the caller actually wants

The instinct is to say "they want to book an appointment." Sometimes true. Often not. At a GP's reception the top call is "is my prescription ready," answered by a one-line lookup against the patient record, no booking involved. At a notary's the top call is "what does it cost to transfer a house," answered by a price grid that has not changed in two years. If we build a booking-shaped agent for either of them, we have solved the wrong problem and charged for it.

We ask the client to pull the last 200 inbound calls from their phone system and tag them by reason. Not 200 from memory. 200 from the call log. If the system cannot export that, we go sit at reception for half a day. Same outcome: a frequency table of why people actually call.

The threshold for building anything: one or two reasons cover 60% of inbound volume. If the long tail dominates, a voice agent that handles the top three intents leaves the receptionist doing the same job with more anxious callers, and we will have charged €18k for ten percent of relief. We say no.

What happens when the phone goes to voicemail

The version of this question that gets a real answer: if no one picks up, what does the caller do five minutes later?

For a dermatology clinic the answer is usually "they call again, or they walk in." That is a cost the clinic absorbs as background radiation, which means the bar for an agent is high. The existing system already kind of works. For a small personal-injury firm taking calls about workplace accidents, the answer is "they call the next firm in the search results." Each missed call is a real client lost. The bar is much lower; the ROI math is obvious.

We need the baseline. Missed-call rate, average answer time, after-hours volume, callback success rate. Anything else is theatre. If the phone provider is KPN, Voys, or 3CX the export takes ten minutes. If you do not know who your phone provider is, that is also useful information.

This is also where we sense-check the client's stated reason for wanting an agent. "We want to reduce reception workload" and "we want to capture more leads" are two different products. They route to different escalation rules, different scripts, different success metrics. If the client cannot tell us which one, the intake stops until they can.

Who owns the system of record

A voice agent that cannot read and write the schedule is a glorified IVR. So we ask, before we draw a single diagram: which system holds the canonical appointment, case, or patient record, and who at your company has the credentials to grant API access?

The bad answer is "we will loop in our IT vendor." That vendor is sometimes a one-person freelancer who built a custom PHP layer over a MySQL database in 2014 and has not returned an email in six weeks. That vendor is sometimes Promedico or HelloDok or a notary case-management SaaS whose API is documented but quota-gated at €600/month for the tier we need. That vendor is sometimes a national health platform with a six-month integration queue and a security review that requires NEN 7510 certification on our side.

Any of those answers can become a yes. None of them is a yes on day one. We need to know which version of the conversation we are about to start.

The other version of this question, for law firms specifically: who decides what the agent is allowed to say about an active case? The moment an agent reads from a case file out loud, the firm has made a representation. We need a partner's name on that decision before any prompt is written.

The failure mode you can live with

This is the one most clients have not thought about. The OWASP Top 10 for LLM Applications reads like a checklist of every way an agent can hurt a business. Every agent fails. The interesting question is what happens when it does.

For a clinic, the failure modes that matter are: the agent books a double appointment, the agent gives a caller the wrong test result, the agent fails to escalate a chest-pain symptom to triage. The first is annoying. The second is a GDPR Article 9 incident with a regulator-facing report attached. The third can kill someone.

For law firms the failure surface is different. The agent must never quote a deadline, a settlement range, or an outcome probability. It books a consult, it confirms the firm received the request, it does not give legal advice. We write that into the system prompt and we test it adversarially before launch, with prompts a real anxious caller would actually try.

The shape of the answer we need from the client: a list of three things the agent must never do, with a named partner or practice manager who signs off on the list. If we cannot get that signature, we do not have a project.

What the four questions are really for

Read them in order and the pattern is obvious. Question one defines the product. Question two defines the ROI. Question three defines the technical floor. Question four defines the liability ceiling. If any one of them returns "we do not know," the project is not ready. If three of them return "we do not know," the client does not need a voice agent yet, they need a week with a consultant and a phone log.

After the four questions land, the build itself is the easy part. Two weeks for the voice path, a week for the integration, a week for staging and load-testing with real call audio. The intake takes longer than people expect; the build takes less.

When we built the inbound voice agent for a dermatology group in Noord-Holland, the question that almost stopped the project was the third one. Their patient records lived in a SaaS whose API access cost more than the agent itself for the first year. We solved it by routing the agent through a thin middleware on the clinic's existing intake server, which already had the credentials and a budget line. That sort of detail is what good voice agent work surfaces in week one, when the intake is honest.

The thing you can do today, before any vendor call: pull last month's call log, tag the top three reasons people called, and write down what happens when nobody answers. Forty minutes. That is the conversation we want to be having.