The Front Desk Work That Is Not the Phone

There is a category of front-desk work that nobody demos, nobody markets, and nobody in this industry writes about, because it is not the part that produces a satisfying before-and-after. It is the administrative transaction layer: checking whether a patient is covered, getting something approved, and chasing what happened to a claim.

It matters here for one specific reason. A practice evaluating phone automation is usually comparing it against the total cost of a front desk, and a large share of that total is work the product cannot reach. Getting the comparison right means knowing which part of the job is in scope and which is not.

Unusually for this field, the administrative layer has published, measured, per-transaction costs. You can multiply them by your own volumes in about 20 minutes and get a number that is more solid than anything on the phone side.

What the front desk day actually contains#

The job is at least four different jobs sharing one chair. There is inbound communication, which is the phone and the messages. There is patient-facing work at the desk: arrivals, checkouts, payments, forms. There is scheduling and the diary. And there is the administrative transaction layer that sits behind all of it.

Ask three people at a practice to describe the front desk job and you will usually get three different jobs back, weighted by whichever one bothers the speaker most. That is not confusion, it is an accurate description of a role that genuinely does four unrelated things, and the four have almost nothing in common operationally.

Those four have different costs, different failure modes, and crucially different automation stories. Treating them as one job called "reception" is what produces the comparison error this article is about, because a product that addresses one of the four gets weighed against the cost of all four.

The transaction layer is the one people forget when they list the job, and it is frequently the one consuming the most uninterrupted time. It is also the one with the best available data, which makes it the easiest to size honestly.

Reception is four jobs sharing one chair. A product that fixes one of them gets compared against the cost of all four.

The transactions with a published price#

The CAQH Index measures the cost of standard administrative transactions in US healthcare and reports them per transaction, split by whether the transaction was done manually, partially electronically, or fully electronically. It is the rare case in this field of a real denominator behind a real number.

For medical providers, a manual eligibility and benefit verification costs $7.97 per transaction against $2.18 fully electronic, and a manual prior authorisation costs $10.97 against $5.79 fully electronic [1]. Those are provider costs specifically, not the industry total, which is the figure you want when you are modelling your own practice.

The time figures are the ones that land hardest for a practice owner. The report puts the average per-transaction time saving available on eligibility verification at 16 minutes for medical providers and 9 minutes for dental providers [1]. Sixteen minutes, on a transaction most practices perform many times a day.

Multiply that out with your own volume rather than accepting the shape of it. A practice running 30 eligibility checks a day at manual cost is looking at roughly $239 a day in provider cost on that transaction alone, before anybody has answered a telephone.

The point is not that the numbers are alarming. It is that they exist, they are measured, and they are more defensible than any figure in the missed-call literature, and yet almost nobody in a practice has multiplied them by their own volumes.

It is worth being clear about what these figures are and are not. They are national averages across a wide range of provider types and sizes, so your practice will sit somewhere around them rather than exactly on them. What transfers reliably is the ratio: eligibility runs roughly 3 times more expensive manually than electronically, and prior authorisation close to 2 times. Ratios survive differences in local wage and payer mix far better than absolute dollars do.

Why phone automation does not touch this#

An AI front office answers calls, captures requests, and routes what it cannot handle. None of those actions is an eligibility check. The transaction layer runs against payer systems and portals, on a different schedule, usually while nobody is on the phone at all.

That is not a criticism of the category, including our own product. It is a scoping fact, and a vendor who lets you believe otherwise is selling against a total they cannot deliver on. The honest claim is narrower: phone automation addresses inbound communication and some of the interruption cost, and leaves the transaction layer exactly where it was.

Where the two do connect is worth stating precisely, because it is a real second-order effect rather than a claimed one. Transaction work is the work most damaged by interruption. It requires a portal, a patient record, and continuous attention, and a phone ringing every 4 minutes is the specific thing that makes a 16 minute task take 25.

So the defensible version of the claim is about protected time rather than about the transactions themselves. Removing 30 interruptions a day does not make an eligibility check cheaper per transaction. It makes the block of time in which those checks happen less fragmented, and fragmentation is what turns a manageable afternoon into an impossible one.

That is a smaller claim than the industry usually makes and it is one you can actually verify afterwards, by timing the same task before and after.

There is a second-order effect running the other way that deserves a mention, because it cuts against the product rather than for it. Moving inbound calls to a system that captures requests creates a queue somebody has to work through, and that queue competes for the same protected block the transaction work needs. A practice that removes 30 interruptions and adds 20 captures to review has not straightforwardly bought itself quiet, and whether it has depends entirely on how long a capture takes to action.

What the transaction layer responds to instead#

If the transaction layer is your real cost, the interventions that address it are different and mostly unglamorous. The published gap between manual and electronic is the whole story: the saving comes from moving transactions from manual to electronic, not from making manual ones faster.

The first two rows are where the measured money is, and both depend on your practice management system and your payer mix rather than on anything sold by this industry. Checking whether your system already supports electronic eligibility, and whether it is switched on, is a genuinely common finding and costs one conversation.

Row four is not a product at all, and it is the one practices under-rate. A block of 2 uninterrupted hours is worth more than the sum of 8 interrupted 15 minute stretches for this kind of work, because each interruption costs the re-entry as well as the interruption itself. Protecting that block is a rota decision, and it is free.

Row three is the cheapest operational change on the list. Running eligibility as a batch the day before, rather than one at a time at the desk while a patient waits, removes the interruption from both sides of the transaction and needs no new software.

How to size your own load#

Twenty minutes with your own numbers beats any benchmark here, and the inputs are things a practice manager can produce from memory or from a single report. Nothing in this calculation requires a consultant, a vendor, or a data extract that somebody has to build for you first.

Count your daily volume of each transaction type: eligibility checks, prior authorisations, claim status inquiries. Then establish, honestly, what share of each is done manually today, which usually means through a payer portal or on the telephone rather than through your practice management system.

Multiply the manual share by the published manual cost and the electronic share by the electronic cost, and you have a monthly figure. Then repeat the calculation as if everything were electronic. The gap between the two is your available saving, and it is the number worth taking to whoever administers your practice management system.

If your practice cannot produce transaction counts, the wage side gets you close enough to decide. At the O*NET median of $22.08 an hour for medical secretaries and administrative assistants [2], every 15 minutes a day spent in payer portals is roughly $1,400 a year in staff time, before a single transaction fee is counted.

Be honest about the manual share, because this is where the estimate usually goes wrong and it goes wrong in one direction. Staff describe a transaction as electronic if the system has the feature, and work it through a payer portal out of habit for the payers where the feature is unreliable. The share that matters is what actually happened last week, not what the system is capable of, and the two are commonly 20 or 30 percentage points apart.

Do the time version too, since it is the one that changes behaviour. Volume times the per-transaction time saving gives you hours per month, and hours are what a practice owner recognises. At 16 minutes per eligibility check and 30 checks a day, the arithmetic gets attention faster than the dollar figure does.

The wider discipline this belongs to, and where these numbers should live once you have them, is covered in read your front office numbers.

Some of this is being taken out of your hands rather than chosen. CMS-0057-F, finalised in January 2024, requires affected payers to stand up prior authorisation APIs, with the main API requirements taking effect on 1 January 2027 [3]. That does nothing for you this quarter and it does not reach every payer you deal with. It does mean the manual share of prior authorisation is a shrinking problem for reasons unconnected to anything you buy, which is worth knowing before you buy something to solve it.

What to do with the answer#

The most likely outcome is that you find two separate problems rather than one, and that they need different solutions bought from different people. That is a better position than the one most practices evaluate from, where a single vendor is asked to explain a single total.

Both numbers being smaller than expected is also a legitimate finding and a fairly common one at low volumes. A practice running 6 eligibility checks a day has an administrative layer that costs real money and not enough of it to justify a project, and knowing that is worth the 20 minutes because it stops the question resurfacing every quarter.

If the transaction layer is your larger cost, deal with it first and independently. It has measured savings, the fix is usually configuration rather than a new subscription, and none of it depends on what you decide about the phone.

The transaction layer has measured savings and usually needs configuration rather than a subscription. Deal with it separately.

If the inbound layer is your larger cost, the arithmetic in what a front desk actually costs is the right frame, and the honest scope of what a phone product does is set out in what "the AI books the appointment" actually means.

Either way, the thing to avoid is the comparison that started this article: weighing a product that addresses one of four jobs against the cost of all four, and then being disappointed when three of them are unchanged.