Case studyCase 01
24/7 voice intake for a multi-site urgent care group
- Multi-site urgent care
- Voice intake
- 200+ calls a day
Results
What changed, and what each number rests on.
200+
Calls answered a day
Basis: Production volume across the group's sites
< 1 sec
Time to answer
Basis: Measured on live calls, operating baseline versus after
4.5 / 5
Patient satisfaction
Basis: Post-call ratings in production
~$50K
A year in staffing savings
Basis: Operating baseline versus after
Around the clock
Coverage at every site
Basis: By design
Clinical boundary
Every clinical question waits for a person
Basis: By design
Company profile
- Company
- A multi-site urgent care group
- Stack
- Twilio SIP phone lines, the group's scheduling system, and the clinic SOPs for hours, locations, and walk-in rules
- Operating need
- Answer every patient call, day and night, at every site, without adding front-desk staff.
The challenge
Where the work was stuck.
The front desk at each site was answering the phone between patients. During the day, callers asking about wait times, hours, locations, and appointments went to hold. After hours, they went to voicemail, and most of them did not leave one. The legacy phone system, when it did answer, took several seconds to respond, which callers read as a dead line.
The group had tried a call center and a phone tree. Both moved the problem instead of removing it. What the group needed was a layer that could answer instantly, in the group's own voice, book the visit into the real schedule, and know exactly when to stop and get a person.
The audit
Six systemic patterns.
- Calls arrived in bursts the front desk could not absorb, so hold and voicemail were the default, not the exception.
- The same four questions made up most of the volume: hours, location, wait time, and how to book.
- After-hours callers had no path at all; the group only learned about them when they showed up somewhere else.
- Booking lived in one system and the answers lived in staff memory, so every call depended on who picked up.
- Clinical questions and administrative questions came in on the same line with no way to separate them.
- Nothing about the phone was measured, so nobody could say how many calls were missed or what they cost.
The front desk was not the problem. The group was missing the layer that answers, books, and escalates on its own.
The architecture
Five components, installed in order.
- 01TelephonyTwilio SIP carries every call from the group's existing numbers into LiveKit Agents, so no number changed and no line was ported.
- 02SpeechDeepgram for speech to text, ElevenLabs for the voice, and voice activity detection with turn detection so the system answers in under a second and does not talk over the caller.
- 03ContextRetrieval over the group's SOPs: hours, locations, walk-in rules, and what each site can treat. The system answers from the group's documents, not from general knowledge.
- 04ActionsBooking, confirmation, walk-in wait estimates, and directions, written into the group's scheduling system as one record per patient.
- 05ControlsA clinical boundary that routes symptoms and medical questions to staff, an audit log of every call, and encryption in transit and at rest to the group's security requirements.
Anonymization
The group asked that its name stay off the site. Everything else here is as it ran.
- Names withheld: the group, its sites, and its staff are not identified.
- Numbers from the operating baseline: every figure is measured against how the phones ran before, not projected.
- Uncertain records go to a person: anything the system could not place with confidence went to staff, and still does.
Implementation
Four stages, one set price.
| Stage | Focus | Key results |
|---|---|---|
| Map | Call volume by site and hour, the questions that made up most of it, the booking path, and where clinical questions had to stop. | An operating map, a baseline of missed calls, and a written scope with one set price. |
| Build and review mode | Telephony, speech, retrieval over the SOPs, and booking, running against real calls with staff reviewing every booking before it stood. | Sub-second answers on live calls, with staff approving each booking. |
| Controls | The clinical boundary, escalation rules, the audit log, and the actions the system could take on its own. | Named permissions for booking and confirmation. Clinical questions always to a person. |
| Launch and run | Every site live around the clock, monitored in production, reported weekly. | 200+ calls a day answered in under a second, 4.5 out of 5 satisfaction, about $50K a year in staffing savings. |
Ownership
What the client keeps.
- Every outcome: the bookings, the answered calls, and the savings belong to the group.
- The data: call records, transcripts, and ratings stay in the group's environment.
- The documentation: the SOPs the system reads, the escalation rules, and the runbook.
- The named owner: the operations lead who reads the weekly report and owns the escalation queue.
The next phase
What this makes possible next.
The planned next phase is Follow-up on the same layer: appointment reminders, no-show rebooking, and post-visit follow-up over text, with the same clinical boundary and the same audit trail. Identity and context are already shared, so it is an addition, not a second build.
Related analysis
AI for urgent care and walk-in clinicsThe group's identity is withheld at its request. The numbers are from the system running in production.
Your first department
Bring the process you still run by hand.
One mapping call. You leave with the system design, the price in writing, and the date it goes live.
How it works
From the first call to a system in production.
The six steps every installation follows, with the output and the control at each one, and the 90-day shape.
See the process