Measuring Recall Conversion, Not Just Calls Attempted

Recall conversion is the only recall number worth putting on a dashboard, and it is the one most practices cannot produce. They can tell you how many calls went out last month. Ask what share of due patients ended up in a chair and the room goes quiet.

The gap is not effort. The outreach system and the schedule are different systems, and nothing joins them.

So the report gets built from what is easy to count. Calls attempted. Messages sent. Contact rate. Every one of those numbers goes up when you work harder and none of them go up only when you work better, which makes them useless for deciding what to change.

Meanwhile the spend is real. A September 2025 MGMA Stat poll found 68% of medical groups added or expanded AI tools during 2025, concentrated in exactly this kind of high-volume front-office work. A practice that adds capacity to an outreach program and measures it by activity has bought something it cannot evaluate.

A better dashboard does not fix this. Deciding what the denominator is, in advance and in writing, does.

The denominator is an eligibility date, not a list somebody pulled

Every honest conversion number starts with a population you can defend. In preventative work, a clock defines it.

Medicare states it plainly for the annual wellness visit: billable once in a 12-month period, one code for the first visit and another for subsequent ones, and not within 12 months of the initial preventive physical exam for the same patient. Claims that ignore the interval come back saying the benefit maximum for the period was reached. That interval is the denominator. A patient enters it on the day they become eligible and leaves it when a visit happens.

Defining it this way has an unglamorous benefit: nobody can improve the number by pulling a friendlier list. A list-based denominator drifts every time someone re-runs the query with different filters, and the conversion rate moves for reasons that have nothing to do with the work.

Write the rule down once. Patients who crossed their eligibility date in month N, measured for a booked and kept visit within a defined window. Everything else on the report is a breakdown of that.

Close reasons are the categorical data you already have

The most useful field in an outreach program is the one nobody bothers to configure: why the item closed.

In athenaOne, patient cases carry close reasons from a defined reference list, and changed cases can be pulled as a feed rather than re-scanned in full. That gives you two things at once. A running record of what happened to each outreach item, and a categorical breakdown that separates the patient declining from the patient being unreachable from the item being closed by a staff member for some other reason. Those three look identical in a contact-rate report and they demand completely different responses.

The catch is that close reasons only mean something if the list is short and the practice agrees on it. Twenty options with overlapping meanings produce a chart nobody trusts. Six options, each with a decision attached, produce a chart somebody acts on.

There is a second catch that shows up in live rollouts. Staff move items between queues by hand. On one program an item that belonged in one bucket kept getting moved into the bucket the automation reads from, which quietly changed the population being worked. If people can move the work, the measurement has to account for people moving the work.

Attributing the booked visit is where the number gets honest

A booked appointment is easy to see. Which contact caused it is the part that gets fudged.

Booked appointments are readable in athenaOne, so the join is mechanical: patient, appointment type, and a booking timestamp that falls inside a defined window after the outreach. Pick the window in advance and defend it. A seven-day attribution window and a ninety-day one produce different programs, and the ninety-day version will eventually take credit for patients who would have come in anyway.

The duplicate-contact problem inflates this quietly. When an open order and a follow-up task are both live on the same patient, working one does not necessarily close the other, so the patient gets contacted twice and both contacts can claim the same booking. Deduplicate at the patient level before counting anything, or the conversion rate will be a function of how disorganized the queues are.

The last piece is the kept visit. A booking that no-shows is not a converted recall, and counting it as one is the most common way an outreach report flatters itself. Measure booked, then measured kept, and report both. The distance between them is a different problem with a different fix.

Numbers tell you what changed, recordings tell you why

A conversion rate that dropped four points does not explain itself, and the explanation is never in the aggregate.

This is what per-call review is for. Pull the calls behind a specific close reason, listen to a handful, and the cause is usually obvious within twenty minutes: an objection nobody scripted, a cost question the outreach cannot answer, a scheduling constraint that makes the offered slots useless. Reviewing every call is possible when scoring is automated, which changes review from a sample of five into a property of the whole program.

Patient experience is worth measuring alongside it rather than after a complaint. The standardized ambulatory survey instruments maintained by AHRQ exist precisely so that access and communication can be tracked with questions that mean the same thing every quarter, instead of with a survey a vendor wrote last month.

The reporting habit that matters most is putting the funnel on one page. Eligible, contacted, booked, kept, with close reasons underneath and the queue age next to it. Anyone can read that in ten seconds and tell you which stage is broken.

Where the person takes over

The automation works the queue, records what happened, sets the close reason, joins the booking, and produces the funnel without anyone assembling a spreadsheet on the last Friday of the month.

What it does not do is decide what the number should be, or which patients matter more. Priority order, attribution window, close reason list, and the definition of a kept visit are practice decisions, and they should be argued about once by people and then left alone. A metric that gets redefined every quarter is not a metric.

It also stops at the clinical line, the same as every other outreach workflow. Anything a patient raises that is about their health rather than their calendar goes to clinical staff with the context attached, and it never becomes a data point about conversion.

The reason to run it this way is not the dashboard. It is that an operator can finally answer the question they get asked, which is whether the outreach program is working, with a number that would survive somebody checking it.

Key Takeaways

Define the denominator as patients who crossed their own eligibility date in a month, not as whatever list was pulled that week.
Anchor preventative denominators to the payer’s interval, since the Medicare annual wellness visit is billable once in a 12-month period.
Configure a short list of case close reasons with a decision attached to each, and pull changed cases as a feed rather than rescanning.
Separate declined, unreachable and staff-closed in reporting, because contact rate hides all three inside one number.
Pick an attribution window in advance and defend it, since a long window takes credit for patients who were coming anyway.
Deduplicate at the patient level before counting, because a live order and a live task on the same patient produce two contacts and one booking.
Report booked and kept as separate numbers, and treat the gap between them as its own problem.
Put eligible, contacted, booked and kept on one page with close reasons and queue age, then review the calls behind the stage that moved.

Recall conversion is a definition problem long before it is a reporting problem. Fix the denominator, agree on close reasons, set the attribution window, and separate booked from kept. Then go listen to the calls behind whichever stage is leaking, because the aggregate will never tell you why.

Sources