Ask anyone who runs a billing office what their call queue is full of and you'll hear the same answer: patients who got a statement they don't understand, calling to ask what it means. Not refusals - questions. And the way most revenue cycle operations are set up, those questions arrive when nobody is there to answer them, wait on hold when someone finally is, and quietly turn into aged receivables when the patient gives up. The problem isn't the patients. It's the machinery around the call.

Why patients actually call

A medical statement is one of the strangest documents a consumer ever receives. It arrives weeks after the visit, quotes procedure codes the patient never chose, and shows adjustments their insurer calculated somewhere else entirely - and the explanation of benefits often doesn't match it. So the patient calls, and the question is almost never "why should I pay this?" It's "what is this, and why does it say I owe it?"

The recurring themes are familiar to every billing manager:

  • "I thought insurance covered this." The patient doesn't understand that a deductible applies before coverage kicks in, or that coinsurance leaves them with a percentage even after it does.
  • "These numbers don't match." The billed amount, the allowed amount, and the patient responsibility are three different figures, and the statement rarely explains how one became the other.
  • "I already paid something." A copay at the front desk, a prior payment, a second statement crossing in the mail - the patient can't reconcile what they've paid against what they still owe.

These are comprehension questions, and they have a property that makes them expensive: an unanswered comprehension question quietly becomes an unpaid balance. The patient who can't get an explanation doesn't refuse to pay - they defer. The statement goes back in the drawer, the balance ages, and a bill that would have been settled in a four-minute conversation drifts toward collections. Much of what ends up in bad debt didn't start as unwillingness. It started as confusion that never got resolved.

The 9-to-5 problem

Now consider when patients actually deal with their bills. They sit down with the mail after dinner. They sort paperwork on Sunday afternoon. They open the portal at 10pm because that's when the house is finally quiet. Medical bills are household administration, and household administration happens on evenings and weekends. Billing offices, meanwhile, answer the phone during weekday business hours - the exact hours the patient is at their own job.

The mismatch would be merely inconvenient if intent were durable. It isn't. There is a moment when a patient is holding the statement, has their questions formed, and is willing to resolve the bill right now - and that moment is perishable. If the call hits a closed-office message, the moment ends. If it hits a hold queue, it ends a few minutes later, with the added sting of having tried. Either way, the patient hangs up telling themselves they'll call back, and a meaningful share never do.

This is why "add more staff to the phones" never quite fixes it. More staff shortens the daytime queue, but the calls that matter most - the ones where a patient has decided, tonight, to sort this out - happen when the office is dark. The fix isn't a bigger daytime team. It's an answer that exists at 9pm.

Verification before anything

Answering at 9pm raises the obvious question: answering with what? A billing call involves protected health information, and the fastest way to disqualify any automation is to have it read a balance to whoever happens to dial in from a patient's number.

The pattern that works is a hard verification gate: the agent confirms identity - name, date of birth, account or statement number, whatever your policy requires - before it discusses a single account detail. Not after the balance is read. Not "for quality purposes" at the end. First. The sequence is strict: verify, then explain, then act. A caller who can't verify gets general information and a path to a human, and nothing else. Every attempt, successful or not, is logged.

This is table stakes for HIPAA-aware phone workflows - and it's worth being precise about that phrase. A well-designed platform enforces the gate mechanically, so the agent structurally cannot reach account data until verification succeeds, and gives you the audit trail to prove it. But compliance decisions belong to your compliance team: what counts as sufficient verification, what may be disclosed by phone, how recordings are retained. Any vendor offering a blanket "HIPAA compliant" stamp as a substitute for that review is overselling. The right posture is workflows built to be governed - rules and scripts your compliance team approves before a single call connects.

The gate is the product: If an automated billing agent can be talked into skipping verification, nothing else about it matters. Evaluate the gate first - can it be bypassed, is every attempt logged, and does your compliance team get final say over the rules it enforces?

Self-service that resolves

Past the gate, the bar is resolution - actually finishing the reason the patient called. That means four things, in roughly this order.

Explain the actual balance. The agent pulls real claim data - billed amount, insurance adjustment, deductible, coinsurance, prior payments - from your system via API and walks the patient through how the number came to be. Never estimated, never guessed: if it can't retrieve the figure, it says so and escalates rather than improvising. For a patient who "thought insurance covered this," hearing that insurance did pay and the remainder is their deductible is frequently the whole call.

Put it in writing. "Can you send me an itemized statement?" is pure fetch-and-send work. The agent emails the itemized statement during the call - no callback, no five-business-day mailing.

Take the payment. A patient who now understands the bill and is willing to pay should be able to - in full, or on a payment plan within the terms you've set: minimum installments, maximum duration, which balances qualify. The agent offers only what policy allows.

Escalate what should be escalated. Some calls belong with your team - suspected billing errors, genuine insurance disputes, hardship cases. A good agent recognizes these and hands them off with full context attached: verified identity, the account, the transcript, what was already explained. The patient never repeats the story. The same logic applies on your portal, where chat agents run the identical verify-explain-act flow in text for patients who would rather type than talk.


Measuring resolution, not deflection

The last piece is measurement, and it's where automation programs fool themselves. "Deflection rate" - the share of calls that never reached a human - is the standard metric, and it's the wrong one. Deflection counts the patient who got their answer and paid, but counts the patient who gave up in frustration exactly the same way. A queue full of abandoned calls deflects beautifully.

Measure resolution instead: did the balance get paid, did a plan get set up, did the question actually get answered? Those outcomes tie directly to the numbers RCM leaders already answer for - days in A/R, collection rate, cost to collect - in a way deflection never does.

Resolution data has a second use. When every call produces a summary and a reason code, you get a structured record of why patients call - which statement line confuses them, which adjustment they don't recognize, which insurer's EOBs never reconcile. That's a to-do list for fixing statements upstream, so next month's confusion never becomes next month's call. It's the standard we'd suggest holding any vendor to, including AI agents for patient billing like ours. Broken billing calls aren't fixed by making them disappear from a dashboard. They're fixed by making them end the way the patient hoped they would when they picked up the phone.

V

Verlingo

AI voice & chat agents, in production

Field notes from the front lines - phone calls and chat windows, collections floors and front desks. We build the agents, run them in production, and write down what works.