Here’s a call that looks like a success.

A patient calls to reschedule. The AI answers on the first ring, verifies her identity, pulls up her upcoming appointment, offers three alternatives, and she takes Thursday at 2 pm. She says thank you. The call ends. Transcript’s clean. Sentiment’s positive. If you’re grading on the conversation, this is an A.

Except Thursday at 2 pm, she shows up, and there’s no appointment in the system.2 pm

This is the failure mode that shaped how we build. Not the AI misunderstanding someone. A good conversation that never became a real appointment. And once you start looking for it, you realize the conversation was never the hard part.

The best way to see why is to watch what a front-office coordinator actually does to book one appointment. It’s two jobs, and the conversation is neither of them.

The first job is getting the constraints right.

Before anyone talks about times, the coordinator has to translate “I need a follow-up” into a visit type — one of dozens, sometimes hundreds, in the practice management system, each with its own duration, provider eligibility, and prep rules.

Then insurance. Not “do you have insurance” — which payer, which plan, which member ID. Provider panels are per-provider, sometimes per-provider-per-location. The patient’s plan determines which providers she can actually see, so collecting the wrong plan doesn’t produce an error message. It produces an appointment with the wrong provider.

Then the plan type opens its own gates. An HMO means checking that a referral is on file. Certain plans and procedures require prior authorization — and practices differ on sequencing: some won’t put the appointment on the schedule until the auth exists, others book it and chase the auth before the visit. Either way, someone has to know which rule applies here.

Then eligibility: is the coverage active today? Real-time eligibility transactions exist (the X12 270/271 exchange), but payer support is uneven enough that verification often still means logging into a payer portal and checking by hand.

All of that happens before slot search even begins — and the slot search is constrained by everything collected upstream.

The second job is getting the transaction right.

The patient says yes to Thursday at 2 pm. Now:
The slot has to still exist. Between offer and write, a coordinator at another location may have taken it for a walk-in. Availability can’t be a snapshot from the start of the call — it has to be re-validated at write time, and the system has to recover mid-conversation gracefully when the answer changes.

The write has to actually land. EHR write-backs fail for ordinary reasons: API timeouts, expired sessions, a record locked because someone at the practice has it open. The naive fix is to retry. Retry carelessly and you double-book the patient. Every write needs to be idempotent — safe to attempt again without creating duplicates — and the system needs to know the difference between “the write failed” and “the write succeeded but the confirmation didn’t come back.”

Then you verify. The last step in our booking flow isn’t sending the write. It’s reading the appointment back out of the EHR and confirming it matches what the patient agreed to: provider, location, time, visit type. If any of those don’t match, the transaction isn’t done.

Here’s the part that took me longest to appreciate: these failures have different latencies. A slot race condition fails Thursday. A wrong visit type fails Thursday morning, when the clinical team discovers a 15-minute slot holding a 45-minute problem. But wrong insurance or a missing authorization fails weeks later — as a patient turned away at check-in, or a denied claim working its way through the revenue cycle. The cheap failures are loud and immediate. The expensive ones are quiet and delayed. If you only measure whether the call went well, you never see them at all.

This is why most voice AI reporting tells you so little. Calls answered, containment rate, handle time — real numbers, worth something. But a practice doesn’t run on handled calls. It runs on a schedule: a specific, unforgiving artifact inside the EHR, shaped by payer contracts and authorization rules, that determines whether a provider’s Thursday is full or empty and whether the visit actually gets paid.

So our internal definition of success is narrow: an appointment exists in the EHR, verified, matching what the patient agreed to, with the constraints respected — right provider for the plan, right visit type, gates checked. Everything upstream of that — speech recognition, dialogue quality, voice naturalness — is necessary. None of it is sufficient.

And patients don’t experience your success rate. They experience the one time it didn’t work — the afternoon off work, the twenty-minute drive, the appointment that doesn’t exist.

The conversation is the demo. The write-back is the product.

When we evaluate our own performance — and when we get paid, since our pricing is tied to booked appointments — the only number that counts is confirmed in the schedule. It’s a harder standard to hit. It’s also the only one that means anything.