Healthcare Customer Support
AI Transformation, Delivery & PMO Plan

The operation

A 250-agent healthcare customer-support centre. Patients call in about their conditions and their care. Every call is handled by a human agent, the interaction is personal, often sensitive, and carries clinical and compliance weight.

The unit of work: where the minutes go

Two pools of mechanical, repetitive effort surround the human conversation: in-call friction (the agent breaks focus to search systems and type) and after-call workflow (the same call generates updates, tasks, routing, and hand-offs, all done by hand). Neither requires clinical judgement. Both are the automation target, anything that gives the agent time back.

The pressure

The team is 250 full-time equivalents (FTE). Leadership wants to reduce headcount by automating as much of the mechanical work as possible, across the whole workflow, not just the note, but the reduction has to be earned by a genuinely lighter human workload, not asserted.

The constraints any solution must respect

What a credible answer must show

A. Operating-model assumptions

B. Baseline parameters: benchmark values, to be replaced by client data

Hover any dotted figure to see its definition and source.

C. Transformation-lever assumptions

The primary lever is the documentation, not the conversation. Ranges below are for modelling; the committed figure is fixed once the solution design (next section) is agreed.

D. What is explicitly NOT assumed: credibility guardrails

E. The client inputs & dependencies that turn every figure real

The design follows one rule at every step: the AI drafts and suggests, the agent reviews and decides, and only then do systems execute, with an audit trail. The generative step is limited to drafting and surfacing information. The patient always speaks to a person, and no patient-facing or consequential action happens without the agent's approval.

The single flow — every call type, every department

What the AI does, and what stays with the agent

Each stage, end to end: the same arc

The same discipline applies at every stage: what the situation is today, what the AI implements, the guardrail on it, what runs automatically, the effort it removes, and how that is measured. Each implementation cell names a real deployment.

The effort figures are the same ones the Number is built from (§04), and every metric reports only alongside the quality scorecard, first-contact resolution, QA and compliance, CSAT, so no stage can be improved by degrading another.

Assistive, not authoritative

The AI's knowledge base will be incomplete, and its suggestions are sometimes wrong; independent studies put agent-AI error rates at 20–30%Peer-reviewed studies of AI-drafted clinical notes found hallucination/inaccuracy rates in this range (e.g. 31% of AI notes vs 20% of human notes; a review of 20 systems found every one carried at least one significant inaccuracy). Source: npj Digital Medicine.. So the agent is always the verifier and the decision-maker, and a wrong suggestion is caught rather than acted on. This is also what keeps the model compliant: the person, not the model, is accountable for every patient-facing word and every record written.

What the agent sees on screen

The copilot runs in a panel beside the agent's normal tools. It reads the live conversation and updates its suggestions as the call moves from one topic to the next. The example below is a pre-authorisation call.

A live call, played out: how fast the loop actually runs

The mock-up above is one frozen moment. Below is the same panel across a whole call, an ongoing audio conversation on the left, what the copilot does in response on the right, and the real, sourced speed of each step in between. The scenario is a routine one: a reschedule plus a coverage question.

All 24 departments — what the AI does and which API it hits

Every call type follows the same 6-step flow. Step 4 varies: the AI fires different APIs depending on the department. Both layers are shown — capability (what it does for the agent) and integration (how it connects, platform-agnostic).

Designing for information at the fingertips

Speed is a design property, not a model property. Five rules keep the answer ahead of the agent's need:

• Pre-fetch, don't fetch. Everything predictable, identity, history, eligibility, is pulled while the phone is still ringing. Mid-call requests are only for what the conversation reveals.
• Push, don't search. The panel updates itself as the topic moves. The agent never types a query during a call.
• Manual never disappears. A persistent deck of one-tap pulls, patient 360, eligibility, prior-auth, billing, medications, fires the same templated lookups on the agent's command, whatever the AI understood. Automation is allowed to degrade; the buttons are not.
• Answer first, evidence underneath. The card leads with the usable line ("covered, $25 copay"); the source and detail sit one click below.
• One action, one click. Every suggested step is a single approval. No forms mid-call.
• Latency is an SLO. Pop with the ring, transcript within ~300 ms, suggestion within a few seconds, and any feature slower than the agent's own memory gets cut, because a tool that is slower than the human loses trust, and lost trust is the adoption collapse described in the Risks section.

Try it: press a caller line, watch the panel react

The same loop, in the reader's hands. Each button below is something a caller says; pressing it plays out what the panel does, including the two cases where the automation correctly refuses to guess. Timings shown are the sourced latencies from above.

After the call, in motion

The other half of the saving, animated. The agent reviews the draft and clicks approve once. The mechanical steps then run on their own, each one logged. The sequence loops every 20 seconds.

To see the real thing at real speed, the public vendor demos are worth two minutes each, they show the suggestion cadence honestly, even where their outcome claims are marketing: Google Agent Assist, real-time demo · CCAI Agent Assist preview · Google + Genesys contact-centre demo · building agent-assist on Twilio in 30 minutes. In each, suggestions land one to three seconds after the caller finishes a sentence, consistent with the latency budget above.

The panel, in motion

The same loop as a living screen, the conversation arrives line by line and the panel reacts. The sequence below plays on a ~20-second loop.

Question by question: what fires, and what the agent sees

The spec beneath the panel, per question type: the utterance as callers actually phrase it, what detection must extract, the exact call fired, and the controls that render. Below the confidence threshold nothing renders automatically, no guessed cards. What never disappears is the manual deck: one-tap templated pulls (patient 360, eligibility, prior-auth status, billing, medications) that fire the same workflows on the agent's command.

Defined workflows: what the copilot triggers as it reads the call

Behind the panel, the copilot carries a set of defined workflows. As it reads the live conversation it detects the topic, and each detected topic can fire a specific integration, an EHR lookup, an insurance eligibility check, a scheduling query, so the answer is on the agent's screen by the time it is needed. The trigger loop is documented platform machinery, not speculation: live transcription → intent and sentiment detection → a rule fires → a function calls the back-end API → the result renders to the agent (in Amazon Connect this is literally a Contact Lens rule → EventBridge → LambdaA Contact Lens real-time rule (keyword, phrase or sentiment match) publishes an event; a Lambda function fires and calls back-end APIs, updates contact attributes, or triggers routing. Amazon Q in Connect rides the same real-time stream for suggestions. Source: AWS Contact Lens documentation.; Google CCAI Agent Assist "proactively provides search suggestions based on the conversation context"; Talkdesk documents an intent-to-Epic screen mapping in its support KB). Each workflow below is anchored to a real deployment or a documented integration.

Worked example flows: from what the patient says to what runs automatically

Three traces of the same pattern end to end. The copilot hears the situation, pulls from several systems at once, combines the results into a picture that exists in no single system, and suggests the steps. The agent approves; the mechanical steps then run on their own. The first flow is the same scenario shown on the screen mock-up above.

The pattern generalises: any recurring situation can be captured as a defined flow, hear it, pull from the systems, synthesise, suggest numbered steps, and automate the mechanical ones on approval. Which flows to build first comes out of the discovery workstream: the baseline data shows which situations are frequent and expensive, and those get flows first.

The issue space: every family of solvable issue

The three flows above are examples from a finite, mappable space. A healthcare support call falls into one of roughly eleven issue families; each family crosses with an urgency level (P0–P4) and a stage (before, during, after) to give the full set of permutations. The matrix below covers the families, what the copilot does at each stage, the risk profile, and a named implementation of the same pattern. The complete cross-product for this client is generated in discovery from its own call-mix data, ranked by frequency × cost.

Training the system to make the right call

The copilot is not smart on day one. It gets smart the same way a good agent does, by learning this centre's actual calls, and being corrected. Five mechanisms, in order:

The after-call workflow: what it can take care of

The after-call step is not just a note. From the call it has just captured, the copilot can prepare, and on the agent's approval carry out, the full set of downstream work the call generates. The agent reviews and approves; deterministic steps then run under an audit trail, and anything patient-facing needs an explicit click.

Handling the full urgency range (P0–P4)

Calls run from a medical emergency to a request for opening hours. The copilot helps differently at each level. At the urgent end its job is safety and speed of routing, not time saved; at the routine end it genuinely reduces effort.

The full framework: definitions, response targets, canonical examples

Each level has a one-line definition, a hard response target, and canonical utterances. The P0 list doubles as red-team test cases: the system must catch these phrasings, including vague versions, before launch.

The full question bank, ten per level. These are the calibration set for the urgency classifier and the training drills.

Three dependencies

The whole solution rests on three things being true. First, the telephony platform must expose call audio, APIs and CRM write-back; without that, none of the real-time capture works, so it is the first item to verify (see RAID). Second, system access is gated and must be secured early: Epic's useful APIs require Vendor Services membership and the client filing an "Interested Organization" request in Epic Showroom, and payer/clearinghouse access needs its own credentials, these are procurement lead-times, not formalities. Third, the compliance setup: PHI redaction before data leaves the boundary, a signed Business Associate Agreement, patient consent, and an audit trail on everything the AI touches.

340B and compliance capture

The after-call workflow can also carry domain-specific compliance capture. The clearest example is 340B, the federal drug-pricing program under which eligible providers capture 25–50% discounts, but only when eligibility and the audit trail are documented correctly. When a call touches pharmacy, prescriptions or patient financial assistance, the copilot can show the agent the eligibility rules, capture the data a 340B audit needs, and route the case into the compliance workflow. A missed-eligible script or a broken audit trail is lost discount and audit exposure, so part of the value here is protecting 340B capture rather than only cutting labour.

Three examples of how this shows up on real calls:

This is a scope item to validate in discovery, not a committed number. It depends on whether this centre's calls actually touch pharmacy or eligibility, and 340B itself is in legal flux following the 2026 rebate-model litigation. It is logged in Scope Discovery, not the outcome.

One formula governs every scenario on this page: Required FTE = (Monthly volume × AHT) ÷ (Productive hours/month × Occupancy). It must first reproduce current state before projecting futures — calibration: 100k × 14.5 ÷ (7,200 × 80%) = 252 ≈ 250 ✓. Per-tier AHT reductions — up to 55% for P4 informational calls when the AI handles all backend work, zero for P0 protected calls — are the only mechanism. Three adoption depths produce three scenarios. Zero deflection in any of them. The peer-reviewed baseline for human-in-the-loop assist (no deflection) is the NBER/QJE study (+14% throughput); vendor "25–30% AHT" figures include deflection and do not transfer here.

How the minutes are calculated

Baseline: about 100,000 calls a month at ~14.5 minutes each is roughly 24,000 human-hours a month. The reduction comes from three things the copilot does. Each one maps to a KPI that can be measured. The patient conversation itself is not touched.

One formula governs all three scenarios: Required FTE = (Monthly volume × AHT) ÷ (Productive hours/month × Occupancy). Calibration: 100,000 × 14.5 ÷ (7,200 × 80%) = 252 ≈ 250 ✓. From there, per-tier AHT reduction (P4 up to 55%, P0 = 0%) yields a weighted 12–37% reduction depending on adoption depth and schedule optimisation, landing at ~222 → ~200 → ~148 FTE. Every figure is confirmed by pilot before any workforce action. Full derivation in the Workforce section.

One KPI gates all of the above: adoption. If agents do not use the tool, the savings do not appear; in the largest independent study, ~15% never used it. Target adoption is ≥90% of eligible calls.

Illustrative handling-hours burn-down — Scenario 3 pathway

The metrics the number is held to

The board-facing metric is FTE capacity released, and cost per resolved contact. The operational metric is human minutes per resolved contact, held at or above baseline quality. Raw AHT is not used on its own: pushing it down rewards agents for rushing and skipping documentation, which raises repeat contacts and can increase total cost per resolved issue. AHT and FTE are published only alongside first-contact resolution, quality and compliance scores, and CSAT, so that no single metric can be improved by degrading another.

The North Star method

One metric sits at the centre of the programme: quality-adjusted human minutes per resolved contact. Everything the programme does is either an input that moves it or a guardrail that protects it, and everything the business wants falls out of it. The method is simple. Drivers are managed weekly. The North Star is reviewed at steering. The outcomes are never targeted directly, because targeting them directly is how numbers get gamed.

Why this metric and not raw AHT or FTE: minutes per resolved contact cannot be improved by rushing, because a rushed call that generates a repeat contact raises the denominator. FTE released is the consequence the board sees; it is read off the capacity model, not chased. This is the same logic the NBER study used when it measured issues resolved per hour rather than talk time.

Method: FTE as an output

The graded deployment evidence is in Section 05. The failure modes that could undermine the number, and the guardrail against each, are in Section 06. All three scenarios are worked through in Section 11 — one formula, three adoption depths, all human on every call.

The tiers are: peer-reviewed or independent; named client, vendor-published, not audited; and vendor self-reported. Only the top tier should be read as fact. Magnitudes below it are directional.

Peer-reviewed and independent

Named-client case studies (vendor-published, directional)

Red-team scenarios the system must pass before launch

Before any rollout, the copilot is tested against the cases most likely to cause harm. Failing any of these blocks launch.

Breaking it on purpose: the caller simulation

Before trusting the system, it is attacked with the callers most likely to defeat it. Each simulated persona below maps to a documented failure mode, and each row states what actually appears on the agent's screen when it fails. The design rule under test: the panel fails to the manual deck, never to confident nonsense, and the agent never waits on it.

The technical stress test: capability limits, stated before anyone asks

Will it last? The persona test

A system like this is not killed by its model. It is killed by one of the people who live with it deciding, quietly, that it works against them. Testing the design against each persona:

Training the human agents

The tool changes what a good agent looks like, so the training changes too. The curriculum is built around one uncomfortable fact: the copilot is sometimes wrong, and the agent has to be the one who catches it.

Two deliberate asymmetries. New agents get the most training investment, because the evidence says they gain the most (+34% in the NBER study). Veterans get an opt-in path and a lighter panel, because forcing the tool on the people it helps least is how the Alibaba experiment produced its worst result, top performers getting worse.

Candidate Optimisation Levers: Surfaced, Not Assumed

Risks & Mitigations

Assumptions & Validation

Issues & Resolution Plan

Dependencies

One Formula. One Calculation. Three Scenarios.

Every interaction stays human in all three scenarios. The formula is the same throughout; only the inputs change. The model must reproduce today's 250 before it earns the right to predict anything else.

Phase 2 & 3: Post 90-Day Expansion

RACI Model

Each row has exactly one Accountable owner. R Responsible, does the work · A Accountable, owns the outcome · C Consulted before the decision · I Informed after it.

AI Kill Switch: Activation Framework

Business Metrics

Operational Metrics

AI Performance Metrics

Patient Safety Metrics: Non-Negotiable Monitoring

Top 10 Actions to Start Next Week

1. Extract 12 months of contact data from the call platform (ACD) and the CRM Build contact reason taxonomy. Measure volume, AHT, FCR, escalation rate, and channel distribution. This is the bedrock of every other decision. Do not proceed without real data.
2. Conduct a full SOP inventory and quality-score every document Score each SOP for AI-eligibility; only high-scoring, low-compliance-risk SOPs are used by the copilot. Estimate: 4–8 weeks with a team of 3.
3. Appoint a Clinical Safety Officer as AI governance co-owner immediately No AI in healthcare goes to production without a clinical safety owner. This is not a technology decision, it is a patient safety and regulatory requirement. Hire or designate from existing clinical staff in Week 1.
4. Map all system integrations required for the AI layer EHR, CRM, scheduling, claims, billing, pharmacy, insurance APIs. Identify: API availability, authentication method, data format (FHIR?), latency, uptime SLA. Integration delays kill AI timelines, start now.
5. Define and document the P0–P4 urgency rules with clinical team input The urgency classifier rules must be validated by clinicians, not written by engineers alone. Convene a clinical safety working group this week. Produce a signed-off urgency decision document before any AI build begins.
6. Select contact centre platform and confirm AI extensibility If replacing: issue RFP this week with healthcare-specific requirements. If keeping existing: validate AI webhook/API capabilities, copilot integration options, and data export for RAG pipeline.
7. Engage 2–3 LLM vendors and request healthcare BAAs and data processing agreements Anthropic Claude, Azure OpenAI, and Google are the primary candidates. Business Associate Agreement (BAA) negotiation takes 4–8 weeks. Start immediately, this is the critical-path blocker.
8. Identify the first pilot cohort: 5 contact reason types Use the issue-space matrix in the Solution section. Select 5 high-volume, low-risk, fully automatable query types. Appointment booking and status checks should be in every pilot. Exclude anything clinical.
9. Establish the AI governance committee with RACI sign-off First meeting this week. Attendees: AI Owner, CS Head, Clinical Safety Officer, Compliance, CTO, one PE board observer. Agree on: kill switch authority, deployment approval process, and incident escalation path.
10. Communicate the transformation to the 250-person team, before rumours do Workforce transformation anxiety destroys productivity. Brief the team: AI is a copilot, not a replacement on day one. Share the redeployment pathway. Identify internal candidates for new AI roles (conversation designers, knowledge managers). Silence creates attrition of the best people first.

Data needed immediately

Recommended first pilot

Technology stack: coordinated by the PMO, chosen with engineering

CEO-Ready One-Page Transformation Summary