Case Study — Contact Center as a Service
Rebuilding patient access on Amazon Connect and Dialogflow CX
How we'd turn a 22-location dental and specialty group's phone lines from a cost centre into a growth channel.
This is a worked example, not a delivered engagement — the architecture, flows, phasing and guardrails are real and how we'd actually build it; the client profile is illustrative.
What CCaaS actually is
A contact centre used to be a room full of hardware — a PBX, licensed seats, sized for your busiest hour of the busiest week, paid for every day including the quiet ones. Changing an IVR menu meant a ticket and a four-week wait. Contact Center as a Service moves that to cloud infrastructure you rent by usage. No PBX, no seat licences, no capacity you don't use — you change a call flow yourself, in an afternoon. That's the smaller half of the story. The bigger half: once routing, transcription and intent detection are all software, you can put automation and AI on top of them, which is where most of the value now sits.
The economics inverted
Legacy contact centre licensing charges for provisioned capacity. Consumption pricing charges for actual use. AWS states Amazon Connect can cut contact centre costs by up to 80% versus on-premises systems.
Speech tech crossed a usability threshold
Old IVR was press-1-press-2 until it gives up. Modern conversational IVR handles the multi-turn conversation that follows a caller saying what they want in their own words.
Staffing got harder and more expensive
Contact centre turnover is structurally high. The repetitive work removable by automation is also the work that burns agents out fastest.
What the published results say
Worth reading with one caveat, stated plainly: most public CCaaS case studies are vendor or partner marketing. Treat them as directional, not as benchmarks you'll hit — the pattern across them is more informative than any single figure.
| Organisation | Sector | Reported outcome |
|---|---|---|
| ChartSpan | Healthcare management | 80.5% cost decrease; 12% increase in clinical staff utilisation; migrated in under six weeks |
| AAMC | Motor claims assessment (AU) | 54% cost reduction; new call centre standed up in an hour for event spikes |
| One NZ | Telecom | 1M+ calls, 2.4M chats/yr; 35% better first-time resolution; ~$2M cost reduction |
| Emssanar | Healthcare & insurance | 45% cost reduction; 35% increase in first-call resolution |
| Spokeo | Consumer data | 75 agents migrated in two weeks; 70% cost reduction |
| ANA X | Airline services | 58% reduction in monthly operating costs; provisioning from weeks to instant |
| Forrester TEI (5 orgs) | Composite study | 342% ROI; $78.7M NPV; payback under six months |
Sources: AWS Amazon Connect customer pages, AWS case studies, a Forrester Total Economic Impact study commissioned by AWS, and partner-published client stories. None are independent research — cited here as reported outcomes, not benchmarks a new deployment will hit.
The metric almost everyone gets wrong
Deflection rate counts calls that didn't reach a human. Containment rate counts calls where the customer reached the end of the automated interaction without escalating. Neither tells you whether the customer's problem was solved. A caller who gets a generic answer and hangs up in frustration is logged as contained.
Industry analysis of this pattern finds CSAT and containment move together up to roughly 55–65% containment, then decouple — past about 70% they invert, because the bot starts intercepting cases it shouldn't handle.
We measure contained resolution, not deflection.
The interaction was handled end to end by automation and the customer did not contact again about the same issue within seven days — and we set targets per intent, not across the portfolio. Appointment rescheduling should contain at a very high rate. Clinical triage should contain at zero, by design.
The client
A dental and specialty group operating 22 locations across the US Midwest — general dentistry plus orthodontics, endodontics and oral surgery, around 180 clinical and support staff, roughly 48,000 inbound calls a year. No contact centre — every call landed at the front desk of whichever location the patient dialled.
Front desk staff doing two jobs badly at once
A patient at the counter and a ringing phone. One of them gets a worse experience, every time. Usually both.
Calls lost at volume
During Monday mornings and the post-lunch peak, calls went to voicemail or were abandoned. Twenty-two phone systems meant twenty-two blind spots — nobody had a single view of demand.
After-hours was a voicemail box
A patient with a cracked filling calling at 7pm got a recording. A meaningful share called a competitor the next morning — lost revenue that never appeared in any report.
No-shows ran at roughly 14%
Reminders were manual and inconsistent across locations. An empty chair is fixed cost with zero revenue against it — the single most expensive recurring waste in a dental group.
Cancelled slots stayed empty
When a patient cancelled at 24 hours' notice, that slot was almost never refilled. Nobody had time to work a waitlist.
Where the calls were actually going
A two-week call-reason analysis before any design work — recording, transcribing and classifying real calls rather than asking staff what they thought was happening.
| Call reason | Share | Automatable? |
|---|---|---|
| Book, reschedule or cancel an appointment | ~55% | Yes — high confidence |
| Insurance and billing questions | ~20% | Partly — eligibility yes, disputes no |
| Clinical questions and triage | ~10% | No — never |
| Prescription and records requests | ~8% | Routing yes, fulfilment no |
| Everything else | ~7% | Case by case |
That table is the entire business case. Fifty-five percent of all calls were scheduling — structured, bounded, highly repetitive, and handled better by a well-built conversational flow than by an interrupted receptionist, at 2am.
What we built
Amazon Connect is the contact centre — telephony, queues, routing, the agent workspace, Contact Lens for transcription and sentiment. Consumption-priced, no seat licences, flows editable by the client's own operations lead.
Connect has Amazon Lex built in, and native is usually right — we use Lex by default for simple, single-purpose interactions. Dialogflow CX earned its place here for three reasons: scheduling is a genuine state machine, not a single intent; one NLU serves the phone line, web chat and patient portal from a single place; and the client's data estate was already on Google Cloud.
We say no to Dialogflow CX more often than we say yes. If a client is AWS-throughout and their flows are simple, adding a second cloud vendor adds latency, cost and an operational seam for no benefit. The right answer is whichever reduces total complexity.
The Amazon Connect contact flow
The entry flow does five things before any conversation starts: sets logging and recording, checks hours of operation, attempts caller identification against Customer Profiles using ANI, sets language, then branches. The branch that matters most is the first one — an explicit, early check for clinical urgency. Yes routes straight to a human, or the on-call clinical line out of hours. No menu to navigate, no automation in the path.
The Dialogflow CX flow
Scheduling as a state machine — pages for identification, appointment type, provider preference, slot offer, confirmation. Three decisions took the longest and matter the most:
- Identification without spelling names — date of birth plus a surname confirmation, matched against ANI where available.
- Generous, early escalation — two consecutive no-matches routes to a human, not five.
- Confirmation by SMS, always — every booking sends a text with a one-tap reschedule link.
Where the growth came from
The cost story is real but it isn't the interesting one. Four things here generate revenue rather than saving it.
After-hours booking
The flow runs 24/7. A patient calling at 9pm now books an appointment instead of leaving a voicemail. Published comparables put after-hours capture in the mid-single digits of total bookings — one comparable automation reported a 7% increase in after-hours bookings alongside a wait-time drop from eight minutes to 45 seconds.
Automated waitlist fill
The best feature in the build, and the one the client didn't ask for. When a patient cancels, the system identifies waitlisted patients matching that appointment type and provider and texts them the open slot, first-come basis. Slots that would have stayed empty get filled within minutes, no human involvement.
No-show reduction
Automated multi-channel reminders on a consistent schedule — the task every location dropped when the waiting room filled up. Each reminder carries a one-tap reschedule link, feeding the waitlist engine when a patient can't make it.
Recall and reactivation
Patients overdue for a hygiene visit are identified from the practice management system and worked as an outbound campaign. Previously a task that existed on paper and never happened — pure incremental revenue from patients already in the database.
The one that doesn't show up in a spreadsheet: front desk staff stopped being interrupted. The person standing at the counter now gets the receptionist's attention. It won't appear in any report, and the practice managers named it first when asked what had changed.
Guardrails
No clinical judgment, ever.
Triage is never automated — any mention of pain, swelling, bleeding, trauma or a knocked-out tooth routes immediately to a human, before any self-service option is offered
The system does not give clinical advice, does not assess urgency beyond routing
Escalation is always one utterance away — "speak to someone" works at every point in every flow
PHI handling: encryption in transit and at rest, scoped IAM roles, retention policy, redaction in Contact Lens output — a signed BAA with AWS (and the Google Cloud equivalent if Dialogflow CX touches PHI) is mandatory before any live patient call
Full audit trail — every automated action logged and reviewable
Failure is loud — integration failures surface immediately and route the caller to a human
How we ran it
Phase 3 is the one clients push back on and the one we hold firm on — launching on voice first means debugging your intent model in the most expensive, least forgiving channel, in front of patients.
| Phase | Duration | What happens |
|---|---|---|
| 1. Call reason analysis | 2 weeks | Record, transcribe and classify real calls. Build the intent taxonomy from evidence, not a workshop. |
| 2. Foundation | 3 weeks | Amazon Connect instance, number porting, queues, routing, hours of operation, agent workspace. Agents are live on Connect before any automation exists. |
| 3. Chat first | 3 weeks | Launch the scheduling flow on web chat. Tuning intents is an order of magnitude cheaper in text than voice. |
| 4. Voice | 4 weeks | Port the tuned flow to voice. Soft launch on one location, then two, then all 22. |
| 5. Outbound | 3 weeks | Reminders, waitlist fill, recall campaigns. The revenue phase, and it comes after inbound is stable. |
| 6. Optimisation | Ongoing | Weekly review of contained resolution by intent, no-match analysis, flow iteration. |
What was hard
Case studies that only contain wins are advertisements.
Practice management system integration was the schedule risk, as it always is
Dental PMS platforms vary enormously in API maturity — some are excellent, some expect you to work against a database or a file drop. Everything else in a CCaaS build is predictable; this is the variable, and it's where contingency belongs.
Speech recognition on a real patient population
Older patients, strong regional accents, hearing aids, background noise, speakerphone. The response was to reduce what the caller has to say rather than chase model accuracy — date of birth instead of spelled names, confirmations instead of open questions, early escalation when it isn't working.
Agents were sceptical, correctly
Every contact centre agent has seen a deflection project that filtered out the easy calls and left only the hard ones. We involved them in the call-reason analysis: the flows take the repetitive scheduling work, agents keep the conversations that need a person.
Twenty-two phone numbers, twenty-two habits
Locations had developed their own conventions over years. Consolidating routing meant changing how people worked — change management, not engineering, and it took longer than the technical work.
Where it started
0
Contact centres — every call landed at a front desk
~14%
No-show rate, manual and inconsistent reminders
~0
Cancelled slots refilled per month
0
After-hours bookings — a recording instead
Why GetDev
AWS and Google sell the platforms. Neither builds your call flows, and the gap between "we bought Amazon Connect" and "our contact centre works better" is the entire project.
We start with evidence, not a workshop
Two weeks of call classification before any design. Most implementations skip it and automate the intents someone remembered in a meeting.
We're platform-honest
Amazon Connect plus Lex is often the right answer and we'll say so. Adding Dialogflow CX when a client is AWS-native adds a vendor, a seam and latency for no benefit.
Integration is the hard part and it's the part we do
Practice management systems, CRMs, insurance eligibility APIs, legacy middleware. The flow design is a fortnight; the integration is the project.
We build for the client to own
Amazon Connect flows are editable by a trained operations lead. A contact centre nobody can adjust without raising a ticket is the problem you were trying to escape.
We measure contained resolution, not deflection
And we set targets per intent — a single blanket target across all call types is a number, not an outcome.
If your phone lines are a cost centre nobody's measured properly, and the calls themselves are telling you where the revenue is — that's the conversation we like having.
Ready to Get Started?
Book a free discovery call and let's explore how Dev can accelerate your business with AI-first solutions.
🍪 We use cookies
We use cookies to analyze site traffic and improve your experience. No personal data is sold.