What an MSO Needs Before a Multi-Site Front-Office Rollout

A multi-site front-office rollout almost never fails on the automation. It fails on the thirty pieces of configuration nobody inventoried, discovered one site at a time, after the go-live date was announced to forty practice managers.

The premise of an MSO is that the practices are similar enough to run one way. The configuration says otherwise.

Refill requests route to a different queue at each site. Open orders and follow-up tasks live under department names that were set up by whoever opened the location. Document classes for inbound records were configured by three different people over six years. The provider list in the system does not match the provider list on the practice website.

None of that is a problem when a human at each site is absorbing it. All of it becomes a problem the moment a single automation is expected to work everywhere.

The rollouts that go badly are the ones that treated this as an implementation detail to be handled during deployment. The rollouts that go well treated it as the deliverable that comes first.

Start with the shape of the organization, because there is no standard shape

The first surprise is usually structural, and it changes the project plan rather than the configuration.

One management group operates as a single account with several separate tablespaces underneath it, each needing its own access authorization submitted and approved separately, and each potentially carrying different appointment types. Another has every practice hanging off one enterprise with completely different configurations per practice. A third combined all its practices and distinguished them with provider-level department groups separated by a name prefix. There is no single answer to what does this organization look like.

Locations can also be separate billing entities inside the same system, which changes what a phrase like the patient’s last appointment even means: last medication visit, last procedure, or last follow-up, potentially under different entities.

So the first artifact is a read of GET /practiceinfo, GET /departments, and GET /providers across every entity in scope, reconciled into one table. Not an org chart from the corporate deck. The structure as the system actually holds it.

Expect that read to disagree with what people believe. Providers listed as active on a practice website turn out not to be active in the system, and the reverse. Reconciling who actually works here and takes appointments is step one, before any routing rule can be written.

Access takes longer than the build, and it is sequential

The schedule risk in these projects is almost entirely administrative.

An access authorization form runs a few business days on its own, but the layered approvals stretch it. A vendor request goes to the platform, then to the management company, and at some MSOs waits on a weekly manual approval meeting. Multiply that by the number of separate entities and the calendar moves by months rather than weeks.

Sandbox environments have to be requested separately and have real gaps. In one working session, document retrieval and certain write operations were disabled in preview but expected to work in production, which means some behavior cannot be verified before go-live. Some practices have no test department at all.

User permissions are a separate stumbling block from access itself. Two pilots in the same week were blocked on the customer being unable to configure the right user permissions for the vendor login. Being authorized at the account level is not the same as being able to see what the staff see.

The planning implication is straightforward. Start every access request the week the contract is signed, in parallel across entities, and treat the approval chain as the critical path it is. The build can be finished and idle for a month waiting on a form.

The complication: written rules and actual behavior disagree

This is the finding that reorders most rollout plans, and it is worth planning for rather than discovering.

When a practice hands over its operating rules, a meaningful share of them are out of date. In one joint session with the platform vendor, both sides put the figure at roughly a fifth of the logic handed over being outdated, and agreed that the booking data is what corrects it. The rules that matter are a mix of what is written down, what is not written down, what is in the system, and what is not.

So the standard opening move is to pull the last ninety days of appointments, departments, providers, and appointment types, rank by volume, and set the pilot scope from that rather than from the interview.

The same gap shows up inside work queues. Follow-up tasks and open orders can both be live on the same patient at the same time, and working the task does not necessarily close the order, so the order stays open and someone contacts the patient again. Staff also move items between queues by hand, which means an item that belongs in one bucket keeps appearing in the bucket the automation reads from.

Document routing has a department trap that is easy to miss entirely. At one practice a fax pipeline was only processing documents whose department was the main office, so anything filed under another department sat unprocessed, and a large share of new-patient referrals were in those other departments. The system would not allow pulling all departments at once, so the sweep had to walk them sequentially and the cycle time stretched from fifteen minutes to hourly.

Every one of those is invisible in a demo and obvious in production. The handoff rule that covers all of them: when the automation finds a conflict between two work items on the same patient, it presents both to a named human queue with the history attached rather than picking one.

Standardize the routing, not the practices

The instinct at rollout is to normalize everything. It is usually the wrong instinct and it is what stalls these programs.

Practices have real reasons for their differences. A site with one physician and a shared medical assistant cannot run the queue structure of a twelve-provider location. Forcing a single queue design across forty sites means forty change-management conversations before any automation ships.

The workable pattern is to standardize the interface and let the destinations vary. Define one set of request categories the automation produces, refill request, open-order outreach, records request, results callback booking, and then map each category to whatever queue that site already uses. Sites keep their structure. The automation sees one vocabulary.

That mapping is also the artifact that makes site two through forty fast. The first site takes weeks because the categories are being defined. The rest take days because only the mapping changes.

AI governance belongs in the same document. A Jan. 20, 2026, MGMA Stat poll found 42% of leaders said their organization has, or is developing, AI governance or a formal AI-use policy. For an MSO that policy has to name which categories the automation may complete on its own, which require staff confirmation, and who at the site level can change the answer.

Decide what success means before site one

Most rollouts measure adoption because it is easy, and adoption tells you almost nothing.

A June 2, 2026, MGMA Stat poll of 260 applicable responses found 68% of practice leaders say their organization has not redesigned a role or adjusted staffing with the help of AI in the past year, while 26% say they have. The groups in that 26% mostly describe small, practical moves concentrated in the front office, revenue cycle, and call center rather than eliminated roles. That is the realistic outcome shape, and it is worth stating internally before the project starts so nobody is measuring against a fantasy.

The numbers worth committing to are per-workflow and per-site. Refill requests routed without a human touch. Open orders converted to booked appointments. Records requests closed inside the target window. Time from document arrival to the correct queue.

Report them by site from the first week, because variance between sites is the signal. A site performing far below the others usually has a configuration difference nobody documented, and finding it in week two is much cheaper than finding it at site thirty.

None of these workflows ask the automation to decide anything about a patient’s care. A refill request is captured and routed to the staff who handle it. An open order becomes an outbound call to get the patient scheduled. A results callback is a booking. The clinicians decide the medicine; the automation moves the paperwork and the appointments around it.

Key Takeaways

Read practice info, departments, and providers across every entity in scope and reconcile them into one table before designing any routing rule.
Expect the system roster to disagree with the practice website. Reconciling who actually works there and takes appointments is step one.
Treat access authorization as the critical path. Layered approvals across multiple entities move the calendar by months, not weeks.
Verify what the sandbox cannot do. Some operations are disabled in preview but expected to work in production, so parts of the flow cannot be tested before go-live.
Assume roughly a fifth of the written rules a practice hands over are outdated, and correct them against ninety days of booking data.
Check whether document sweeps cover every department. Items filed under an unswept department are not late, they are invisible.
Standardize the request vocabulary, not the queue structure. Map one set of categories to whatever queues each site already uses.
Report per-workflow metrics by site from week one. Variance between sites is usually an undocumented configuration difference.

The difference between an MSO rollout that reaches forty sites and one that stalls at four is almost never the quality of the automation. It is whether the configuration inventory, the access chain, and the queue mapping were treated as the first deliverable or as something to sort out during deployment. An AI team working inside athenaOne can do that discovery against the live configuration rather than an interview, hold a different queue map for every site behind one shared vocabulary, and surface the conflicts between work items to a named human queue instead of guessing at them.

Sources