The Front-Office Metrics to Pull Before Any Platform Change

Front-office metrics are the cheapest thing an MSO can pull before it prices a platform change, and they are almost never pulled first. The conversation usually starts at the other end: a demo, a proposal, a migration estimate, and then a scramble to justify it against numbers nobody had ready. By then the arithmetic is being done to defend a decision rather than to make one.

The trouble with evaluating a platform in the abstract is that most of what an operations leader is unhappy about is not the platform. It is configuration, staffing, and process that accumulated across acquisitions and never got reconciled.

From the executive chair those symptoms look identical. Calls get dropped, slots go unfilled, authorizations arrive late, and the natural conclusion is that the system is the constraint. Sometimes it is. Often the same symptoms are produced by two sites defining an appointment type differently, or by one location running a template nobody has looked at since it was inherited.

A baseline separates them. Pull the numbers first, per site, in units that mean the same thing everywhere, and the decision changes character. Some of the gap turns out to be fixable this quarter without changing anything structural. What is left is the honest case for or against a bigger move.

Reconcile what a site is before you compare sites

The first number is not a number. It is a mapping, and skipping it makes everything downstream wrong in a way that is hard to see.

In athenaOne the department is the operational unit, and in a group that grew by acquisition the departments rarely line up cleanly with the buildings an MSO actually manages. One site may carry three departments left over from a prior structure. Two locations may share one. Until that is reconciled deliberately, a cross-site comparison is comparing definitions rather than performance.

Do the same for appointment types. The same label at two sites can mean different durations, different provider eligibility, and different prep requirements. That is the single most common reason a rate that looks alarming at one location turns out to be a naming difference.

This is a half-day of work, once, and it is the difference between a baseline and a set of numbers that argue with each other.

The five numbers worth having before any conversation

Keep the list short enough that every site can produce it the same way.

First, appointments booked and appointments changed per site over a fixed window, which is the volume denominator everything else divides into. Second, calls that ended without a booking, by site and by hour, which is the access number closest to lost revenue. Third, open cases in the front-office work queues and their age, since a case count without an age tells you nothing about whether the queue is moving. Fourth, the share of visits where coverage was verified before the patient arrived. Fifth, third-next-available by provider and department, which is the access number a referring office experiences.

All five are pullable from athenaOne reporting and change feeds without a project. What makes them useful is the fixed window and the identical definition across sites, not the sophistication of the metric.

Resist adding a sixth. The failure mode of MSO measurement is a scorecard nobody reads, and five numbers per site that everyone trusts beat twenty that get argued about.

Look at the front end before you conclude the platform is the problem

When leaders are asked where money actually escapes, the answer points more at process than at software.

A January 6, 2026, MGMA Stat poll of 288 applicable responses asked practices where the biggest revenue cycle leaks are today. Denials and appeals led at 48%, followed by front end issues at 23%, billing and collections at 14%, coding at 13%, and charge posting at 2%.

Nearly a quarter of the identified leakage sits in the front end, which is registration, eligibility, and the work that happens before a claim exists. That work is configuration and staffing far more than it is platform. It is also the part an MSO can move inside a quarter.

So the sequencing matters. Fix what the front end is doing, remeasure, and then see how much of the original complaint survives. A platform decision made on top of an unfixed front end is priced against a problem the platform was never going to solve.

Know where the staff hours are going before you model the savings

Most migration cases are built on projected labor savings, and most of them are built on a guess about where the labor currently goes.

A March 10, 2026, MGMA Stat poll of 294 applicable responses asking practice leaders which phone tasks consume the most staff time put eligibility and prior authorization at 45%, ahead of scheduling at 31%, intake at 9%, and prescription refills at 6%. If your model assumes scheduling is the bulk of the burden, it is aimed at a third of it.

Get your own version of that split before running any numbers. Sample a week of front-office time by task, per site, and put it next to the poll. Where your group diverges from the sector is the interesting part, and it usually points at a specific site or a specific payer relationship rather than at the system.

When you do build the cost case, show the arithmetic and state the assumptions in the same place as the numbers, so a reader can tell a worked example from a measured result. Your figures will vary by site, payer mix, and season, and a model that hides that reads as more certain than it is.

Then measure the thing patients and referrers actually feel

A platform change is ultimately justified by access, so the access number belongs in the baseline rather than in the business case written afterward.

A July 14, 2026, MGMA Stat poll of 197 applicable responses found 46% of medical groups reported new-patient appointment wait times unchanged year to date, while 28% said they were longer and 22% said shorter. Most of the market is flat, which means a group moving that number is doing something visible.

Pull third-next-available per provider and department, and pull it again ninety days later after the front-end fixes have run. The delta is the most honest input you will get. If access moved materially without a platform change, the case for one is smaller than it looked. If it did not move at all, you now have evidence rather than a feeling.

Either way the measurement outlives the decision. A group that can produce comparable per-site access numbers on demand negotiates better with every vendor it talks to afterward, including the one it already has.

Key Takeaways

Reconcile athenaOne departments and appointment-type definitions to the sites you actually manage before comparing any numbers across locations.
Hold the baseline to five per-site numbers with identical definitions and a fixed window, and refuse the sixth.
Pull open work-queue cases with their age, because a count without an age says nothing about whether the queue is moving.
Sample your own front-office time by task instead of assuming scheduling is the bulk of the burden.
Fix the front end, remeasure at ninety days, and see how much of the original complaint survives before pricing anything structural.
Label any cost model as a worked example with its assumptions next to the arithmetic, since per-site figures vary by payer mix and season.

The numbers to pull before pricing a platform change are unglamorous and mostly already sitting in athenaOne. Reconcile the departments, define five metrics the same way everywhere, and remeasure after the front-end work. What is left after that is the real decision, and it will be a smaller and clearer one than the version you started with.

Sources