Several Automations, One Front Office: How the Work Divides

The first automation a group buys is always framed as a product. The third one is a management problem. By the time a multi-site front office has something answering phones, something working the schedule, and something chasing eligibility, the question stops being what each tool does and starts being where one stops and the next begins.

Nobody buys three automations on purpose. They arrive one at a time, each solving a real thing, each configured by whoever was in the room that quarter.

The seams are where the work goes missing. A call that should have become a scheduling task instead becomes a closed call. A patient case gets opened by one workflow and sits because the second workflow was only ever told to look at its own queue. Nothing fails loudly. The group just has a slightly worse front office than the sum of what it paid for.

Divide by the work, not by the channel

Most groups draw the lines by channel. Phones over here, portal messages over there, faxes somewhere else. That mapping is convenient and it is wrong, because a patient does not pick a channel based on what kind of work they are creating.

The better split is by what has to happen next. A request that ends in a booked appointment is scheduling work whether it arrived by phone, portal, or web form. A request that ends in a verified benefit is revenue-protection work. A request that ends with somebody in the building making a decision is a handoff, and it should look identical no matter which door it came through.

Practice leaders already sort their front office this way when asked. When MGMA asked where medical groups were focusing AI and automation for the front office and access, scheduling led at 31%, followed by calls at 27%, registration and eligibility at 23%, prior authorization at 16%, and other at 5%. Those are categories of work, not channels.

Drawing the boundary at the work also survives a channel shift. Add two-way texting next year and nothing about the division changes, because texting is a new door onto the same four rooms.

One queue owns each piece of work, and it is written down

The failure mode in a multi-automation front office is not conflict. It is ambiguity. Two systems that both think a task belongs to the other produce a queue that looks clean and a patient who never gets called back.

On athenaOne the fix is unglamorous and concrete. Every kind of work gets one owning queue, and the owning queue is named in a document a human can read. Patient cases carry a class and an assigned recipient. Departments and provider groups define who is even eligible to receive the work. Task assignment is a real field with a real value, not an implicit convention.

Write the map before you turn anything on. Which document classes route to a clinical queue. Which patient case types the automation may close on its own, and which it may only open. Which staff pool receives the ones it cannot finish. That list is short, and a group that cannot write it does not have a division of labour, it has three tools and a hope.

The test is whether a new manager can read the map and predict where a given request will end up. If they cannot, neither can the people already working the queues.

The complication: routing by primary provider does not work

Here is where the tidy map meets the data. Almost every routing rule anyone writes starts with the patient’s primary provider, because that field exists and looks authoritative. In practice it is stale nearly everywhere.

Patients get assigned a provider at registration and the field is rarely revisited. Providers leave. Panels get redistributed after an acquisition and the chart never hears about it. Route on that field across ten sites and a meaningful share of the work lands in the inbox of somebody who has not seen the patient in three years, or who does not work there anymore.

The workable fallback is recent history. Route on who has actually seen this patient recently, in this department, and fall back to the department pool rather than to a named person when the answer is not clear. That is a rule the automation can apply consistently, and it degrades safely: an unclear case lands with a team instead of a ghost.

Then name the handoff. When the automation cannot resolve an owner from recent history, it does not guess and it does not park the item. It assigns to the department pool, flags why it could not resolve, and a human picks the recipient. Routing is mechanical and belongs to the automation. Deciding who should own an ambiguous patient is a judgment call and belongs to a person.

Give the phones the work that is genuinely on the phones

There is a persistent habit of scoping voice automation to the greeting and the booking, then routing everything else to a person. That leaves most of the actual phone burden untouched.

In a March 10, 2026, MGMA Stat poll, practice leaders named eligibility and prior authorization as the most time-intensive phone task at 45%, followed by scheduling at 31%, intake at 9%, prescription refills at 6%, and other at 9%. The largest single block of phone time is the coverage question, not the booking.

So the division that works puts the eligibility check inside the call rather than after it. The caller asks whether their plan is taken, the automation checks the coverage on file against the department and the appointment type being requested, and the answer arrives while the patient is still on the line. What used to be a call, a callback, and a second call becomes one conversation.

What stays with staff is everything that is a negotiation. An unusual plan. A coverage answer the patient disputes. A benefit question that turns into a cost question the practice has a policy about. Those are conversations, and conversations are what your people are for.

Measure the seams, not the pieces

Every automation reports on itself, and every one of those reports looks good. Calls answered. Tasks closed. Slots filled. None of them can see the item that fell between two systems, because from inside each system nothing went wrong.

The numbers worth watching all describe a boundary. Work created by one workflow and not picked up by the next within a day. Patient cases opened and still open at a threshold you set. Requests that arrived, got categorized, and never produced the outcome their category promises. Those are seam metrics, and they are the only ones that find the gap.

Standardize before you compare. Departments have to map cleanly to the sites you actually manage, and a case type has to mean the same thing at every location, or a cross-site comparison is just ten definitions in a row. In a group that grew by acquisition this reconciliation is a real project, and it is worth doing once, deliberately, before any of these numbers gets trusted.

Review the seams monthly. That is also the moment to move a boundary, because the right division of labour is not a permanent fact. It shifts as each automation gets better at its own piece.

Key Takeaways

Split front-office work by the outcome it produces rather than by the channel it arrived on, so a new channel does not force a new map.
Give every kind of work one owning queue on athenaOne, name it in writing, and confirm a new manager can predict where a request lands.
Stop routing on the chart’s primary provider field, because it is stale in most practices, and route on recent visit history instead.
Fall back to a department pool rather than a named person when ownership is unclear, and let a human choose the recipient.
Put the eligibility question inside the call, since coverage is the largest block of phone time and a callback doubles the work.
Track seam metrics such as work created and not picked up within a day, because each automation’s own report cannot see the gap between them.

A multi-site group with three automations and no map does not have an automation problem, it has an org chart problem wearing software. Draw the boundary at the work, put one owning queue behind each piece, route on evidence rather than on a stale field, and name the exact point where a person takes over. Then watch the seams, because that is the only place the whole thing can quietly fail.

Sources