The most important person in a hundred-location rollout is usually not in the kickoff meeting. She's a front desk coordinator at clinic number sixty-three who has run that phone her way for fifteen years, knows which provider won't take a certain referral type, and has never heard of the project. Whether the deployment works depends more on her than on anything we configure.

That's the part of enterprise AI that doesn't fit neatly into a plan. Integration has a schedule. Configuration has an owner. Change management has neither, and it's where large deployments actually succeed or quietly fail.

I've spent the last few years doing this at scale — first with ambient scribe tools across dozens of specialties, now with voice agents across multi-site specialty groups. Below is what I'd tell anyone about to attempt it.

• 100+ Locations in a single rollout

• 3 Waves before the playbook runs itself

• 40% Of inbound calls resolved with no human

There is no "the team"

Rollout plans use that phrase constantly. "We'll train the team." "The team will need to adjust." Across a large specialty group, it's a fiction. There are a hundred front desks, each with a local authority on how scheduling actually works there, each with a slightly different relationship to the schedule template they're supposedly all following.

An all-staff email does not reach those people in any way that changes behavior. Sequencing does. We group locations by geography, EHR configuration, and operational readiness. Wave one is the clinics most likely to succeed. Wave two learns from wave one's edge cases. By wave three the playbook runs itself — but only because waves one and two produced people inside the organization who can say We did this; here's what broke; here's what we changed.

The sequence carries most of the risk. Put a struggling clinic in wave one, and you've manufactured the story that will follow the project for a year. That judgment isn't a methodology. It's accumulated from having gotten it wrong before.

Put a struggling clinic in wave one, and you've manufactured the story that follows the project for a year.

Somebody's job changes, and nobody writes it down

Before go-live, a front desk coordinator answers something like a hundred calls a day, most of them the same six questions. Are you taking my insurance? Can I move my Thursday? Where do I park? What do I do before a biopsy?

After go-live, the routine volume is gone. In one deployment at a value-based care network, the AI now resolves 40% of inbound calls end to end with no human involved and routes most of the rest. What reaches that same coordinator is the residue: the confused, the upset, the clinically ambiguous, the caller whose situation doesn't fit any of the six questions.

That's a harder job than the one they had. It takes more judgment, not less. And in most rollouts nobody rewrites the job description, nobody adjusts the title, nobody changes how the role is evaluated, and nobody says out loud that the work got more demanding rather than less. The person figures it out from the calls.

When adoption stalls, it gets diagnosed as resistance to AI. It almost never is. It's someone who was handed a new job without being told.

The handoff is an operating decision, not a vendor decision

Every AI system has a threshold where it stops and escalates. Ours does. What happens on the other side of that handoff at 4:47 on a Friday is not ours to decide.

Who picks it up. What the response-time expectation is. Which categories go to a human immediately regardless of confidence. Whether the after-hours path routes to an on-call clinician or a morning queue. Those are staffing and liability decisions, and if operations doesn't make them deliberately, they get made by default — usually by whoever happens to be standing closest to the phone.

The deployments that hold up had someone on the client side who owned that matrix and revised it twice in the first month. The ones that struggled had a matrix that came from us and was never touched.

What the expertise actually consists of

"Change management" is a phrase that usually means a slide with a curve on it. In practice, at this scale, it's four concrete things.

01

Recruit wave one; don't assign it

The first clinics should include people who want to be first. Their word travels further inside the organization than any communication we could write, and their edge cases are the ones you want to find early.

02

Name the role change in writing

A paragraph per affected role describing what the work looks like the week after launch. It doesn't need to be an HR document. It needs to exist before someone experiences the change without warning.

03

Give the escalation path a named owner

Someone on the operations side who owns what happens at the handoff and is expected to revise it in the first thirty days rather than approve it once.

04

Go find the undocumented rules

Which provider declines a certain referral type. Why one location's Tuesday afternoons are effectively blocked despite the template; that knowledge sits with the coordinators, not the project sponsor, and no integration extracts it.

None of that is technology work. All of it determines whether the technology produces anything. The teams that treat it as an afterthought spend month three explaining to a board why adoption is at 40% of plan.

If you're evaluating a patient access platform, the demo will tell you what the technology can do. It won't tell you whether the vendor has done this before at your scale.

So ask a narrower question. Change management at scale isn't a methodology anyone applies — it's knowing which clinic goes third. That's not knowledge you can buy, and it's not knowledge you can fake. It comes from having been wrong about it before.