What Building One athenaOne Workflow Actually Involves

Vendor case studies almost always open on a number. Calls handled, hours saved, percentage something. Those numbers are real when they are measured, and they tell you nothing about whether the thing would work at your practice, because they skip the part that decides it: how a workflow gets from a sentence somebody said out loud to something running against your real templates and queues.

This page is the other half. Three anonymized accounts of that middle part, including the stages that stalled. No practice is named. No outcome is claimed that was not measured, and at the end I have said plainly which numbers are deliberately absent and why.

Account one: outbound recall on a specialty cadence

What the practice said. A neurology group had a list of patients with follow-up tasks sitting in athenaOne, some with target dates more than a year out. The office manager put it in one sentence. Nobody has the hours to call all of these, and the ones we do call are usually the wrong ones.

What the data said. The first thing we pulled was not a wish list, it was ninety days of appointments, departments, providers and appointment types, ranked by volume, next to the outstanding follow-up task queue. That comparison is the single most useful view in this whole process, and it usually surprises the practice. Locations do not sit in the middle: one will have a hundred open slots and a dozen patients waiting to be scheduled, another will have three open slots and forty patients waiting.

Counting the outstanding tasks was itself a piece of work nobody had done. It had to be done before anyone could say what the automation was for.

What got built. A workflow that reads the follow-up task, checks the patient is still active, calls at a cadence appropriate to the specialty rather than a generic reminder interval, books against real provider availability, and writes the appointment and the note back to athenaOne. Cases that do not fit the rule route to staff with the reason attached.

Where it stalled, and this is the honest part. It stopped on wording. The practice wanted to approve the exact verbiage the agent would use before a single patient heard it, which is a reasonable thing to want and is not something you can rush. The workflow sat built and paused while that got settled.

How it restarted. Not with a full switch-on. A small batch, starting with two named providers, with the practice listening. That is the correct way to start and it is the way we ask for.

Account two: the appointment catalog that changed overnight

What the practice said. Nothing, initially. That is the point of this one.

A dermatology practice consolidated its entire appointment-type catalog: cosmetic types including injectables, laser, microneedling and chemical peels, two biopsy durations, cryotherapy, and the generic procedure type were all retired in athenaOne and folded into a single follow-up type.

What the data said. The surviving type was fifteen minutes. A forty-five-minute service had nowhere to go. The practice also still wanted the specific service name to appear as the reason for visit on the booked appointment, which the consolidation had just removed the obvious route to.

What got built. A remap, decided with the practice rather than assumed: keep the retired types internally, map them deliberately onto fifteen and thirty-minute equivalents, and carry the original service name through as reason for visit.

The part worth taking from this account. The system flagged the cascade instead of quietly booking a forty-five-minute service into a fifteen-minute slot. Our engineer’s note back to the practice asked for a heads-up next time, because an appointment catalog is a shared dependency and a silent change to it is an outage waiting to happen. Cases that hit an unmapped type during the remap routed to staff with the context attached.

This is the maintenance work that does not appear in any case study and is most of what separates automation that lasts from automation that is quietly switched off in month four.

Account three: turning the phone menu off on purpose

What the practice said. A community health center asked to disable its phone menu entirely during the supervised live-call block.

Their reasoning, which is better than ours would have been. They were worried that patients navigating a menu would be expecting a person at the end of it, reach an automated agent instead, and arrive at the conversation already annoyed. That frustration would then contaminate the test, and they would not be able to tell whether the agent was any good or whether the menu had poisoned the call.

What got built. Nothing, in that session. The value was the design decision. We ran the block without the menu, the practice listened to real calls for half a day, and then filed a written list of changes.

What that list looks like in practice. One practice filed eight issues in a single morning. Three of them were compliments. Every change request in that report became a scoped item. This is the stage where the rules that were never written down anywhere finally get written down, and it is the stage most evaluations skip.

The pattern across all three

Read them together and the same shape shows up.

The practice describes the problem in one sentence. The data corrects it. In a joint working session with an EHR vendor the rough estimate was that around a fifth of the logic a practice hands over is out of date. It is not that anyone is wrong, it is that the written rules and the booking history drift apart, and only one of them reflects what actually happens.

The build is rarely the long pole. Wording approval, a rule two staff members disagree about, an appointment catalog somebody else owns. Those are what set the pace. Production access to 820+ athenaOne APIs is what makes an unusual workflow buildable at all, and once the rule is settled, new workflow scope is measured in days and weeks, not quarters, inside an onboarding window that already runs weeks.

Starting small is not caution, it is method. A half day of supervised real calls with the practice listening produces a better change list than any amount of demo.

The workflow is never finished. Account two is the proof. Something upstream changes, the system surfaces the conflict, and a person on each side agrees the new mapping.

What is deliberately not in this page

This is a case-study page with no outcome metrics in it, which is unusual enough to explain.

We publish aggregate figures across customers: about 60% of calls handled start to finish at the largest deployments, and roughly thirty days to measurable results. Those are customer-reported and your numbers will vary by workflow, staffing, seasonality and call mix.

What we will not do is attach a result to one of the three accounts above. Two reasons. Named customer results, metrics, reporting periods and denominators belong to the customer and get published only with their approval. And an outcome that was not measured against a baseline is not an outcome, it is a guess with a percentage sign on it. The recall workflow in account one restarted with a small batch of patients across two providers. Anyone quoting a lift from that would be making it up.

If you want measured results from a named practice, ask for a reference call. That is the right instrument for it, and it is a better use of your time than a number on a web page.

Two boundaries that do not move

Clinical decisions stay with your care team. Every workflow above is administrative: reading a follow-up task, resolving a slot, booking a visit, routing an exception. Nothing in them assesses a patient or decides what care is appropriate.

A rule nobody can articulate cannot be automated. When two experienced staff handle the same case differently and neither can explain why, that is a decision the practice has to make. We can find it in the booking data and put it in front of you. We cannot make it for you, and neither can anybody else.

If you are evaluating this

Three questions worth asking any vendor, drawn from the three accounts.

1. What do you pull before you scope, and what do you do when it contradicts what we told you? If the answer is a questionnaire rather than our own booking history, the scope will be built on the out-of-date fifth.
2. What happens on the day our appointment types change? Silence here is the answer.
3. Can we listen to real calls before we commit, with our menu configured however we want it? A vendor confident in the work says yes to this immediately. For the full list of what is already running rather than what can be scoped, see the athenaOne workflow catalog.

More on how the scoping path works, stage by stage, is on the custom athenaOne workflow page. If the problem you are looking at is inbound call volume rather than a specific workflow, why practices miss patient calls is the better starting point.