Recover an Interrupted AI Scheduling Call Without Losing the Request
Handle poor connections, repeated misunderstanding and disconnected calls using observable progress and a staff recovery queue.
The state map and test cases below are original administrative evaluation methods. They do not describe a verified feature of any vendor or set clinical scheduling priorities.
Why interrupted calls are different from ordinary callbacks
A callback queue can carry many kinds of unfinished work. This article focuses on the case where a scheduling transaction may already be partly completed. The caller may have been identified, a provider chosen, a slot offered, or a booking submitted but never read back. If the system cannot tell you which of those happened, your staff face two bad choices: start over and risk a duplicate, or assume the booking exists and risk an empty slot and an annoyed patient.
The Linear Health Operational AI Evaluation Kit frames this as a basic evidence question. Its integration checks ask vendors to demonstrate identity matching, duplicate handling, retries and recovery after a failed write, and its workflow checks ask that completion be defined in observable terms, including the final status and where it is recorded. The kit also flags a demonstration that ends with a message, draft or task instead of a confirmed outcome as a red flag. That standard is the right one for dropped calls. For how callback promises themselves are tracked, see patient callback queue management; this article covers the partial transaction, not the promise.
Separate conversation progress from a completed booking
The first design decision is vocabulary. Progress means the conversation reached a point. Booking confirmed means an appointment record exists in the authoritative scheduling system. Communication confirmed means the agreed confirmation was delivered through the approved route. Keep an unresolved communication task open even when the booking itself exists.
This matters because voice AI can sound confident at every step. A caller who hears "I have you down for Tuesday" before the connection drops may reasonably believe the visit is booked. Your operating model should not rely on what the caller heard. It should rely on what was written. The AHRQ Workflow Assessment for Health IT Toolkit makes the general point that successful health IT implementation depends on recognizing its impact on administrative workflow; the dropped-call path is one of those workflows and deserves to be mapped explicitly rather than left to improvisation.
Record the last confirmed step before interruption
The reusable tool here is an interrupted-conversation state map. The idea is simple: name a short list of states, decide what evidence proves each one, and decide what the safe recovery action is from each. The states below are an editorial proposal. Adapt them to your own workflow and confirm with your vendor which states its system can record and expose.
| State | What is confirmed | Safe recovery action |
|---|---|---|
| S0 Contact only | No scheduling state confirmed | Establish identity under policy, then check for an existing request before proceeding |
| S1 Caller identified | Patient match confirmed against the record | Look up existing appointments before anything else |
| S2 Need captured | Requested administrative visit type recorded | Confirm captured details and current approved scheduling rules |
| S3 Slot offered | Times presented; no acceptance recorded | Recheck availability and any hold before offering again |
| S4 Write outcome unknown | Caller agreed; booking attempt may be pending, failed or committed | Reconcile the attempt status and current record; avoid a competing write while outcome is unknown |
| S5 Booking confirmed, communication open | Appointment exists; confirmation delivery unconfirmed | Confirm the existing appointment through the approved route; do not create a replacement |
| S6 Request resolved | Booking and required communication confirmed | Record closure evidence and retain responsible owner |
The map only works if the system records the state at the moment of interruption and the timestamp. The evaluation kit's request for a timestamped workflow trace and a failure and retry log is what you should ask to see. If a vendor can only tell you that the call ended, record the state as unknown and route it to the approved reconciliation process. Do not infer the booking outcome from the call's end time.
Choose an approved recovery route for the unfinished request
Decide in advance which routes are allowed and who owns each. A reasonable set of options, again as editorial guidance:
- Automated callback with resumed context. The AI calls back and resumes from the recorded state. Suitable where the state is clear and the vendor can demonstrate that context is restored, not re-collected from zero.
- Staff recovery queue. The request lands in a queue with the state, timestamp, patient match and any captured need. A named person works it within a stated time. This is the safe default for S4 and S5 and for any case where the state is ambiguous.
- Patient-initiated return. The patient calls back. The system should recognize the open request and present the recorded state to the AI or to staff, rather than starting a fresh intake.
The evaluation kit's oversight checks ask vendors to show role-based access, escalation paths and the owner for unresolved exceptions, and to demonstrate how a user pauses, corrects or reverses an automated action. Ask exactly that for the recovery queue. An exception queue with ownership is listed as evidence to request; a queue with no owner is the same as no queue.
For any workflow under review, identify what recovery the vendor supports and what remains with staff. The patient engagement platform page describes Linear Health's broader scope. Book a demo with a synthetic interrupted-call case and ask the team to trace the attempted write, current appointment and assigned recovery work.
Check for an existing booking before attempting another action
Treat duplicate prevention as both a record check and an ownership question. Before creating a booking, check the matched patient's relevant appointments and any open booking attempt. Ask how the system prevents staff recovery and an automated retry from committing competing actions after the same lookup.
Three questions to ask your vendor:
- Where does the lookup happen, and against which system? A lookup against an internal cache is not the same as a lookup against the system of record.
- What happens if the write succeeded but the acknowledgement failed? Test this uncertain-write boundary explicitly. An absent acknowledgment must not be treated as proof the write failed.
- How is a duplicate detected after the fact, and who corrects it? The kit asks how every automated action is logged and how an authorized user can correct it.
Integration depth matters here. Linear Health lists athenahealth, eClinicalWorks, NextGen and Greenway Health as established integrations, but field-level write actions and event coverage for your configuration need demonstration, and no specific API behaviour should be inferred from an integration logo. The companion article on AI voice scheduling EHR integration covers that evaluation in more depth.
Test connection failure, misunderstanding and repeated callbacks
Run these cases before go-live. Each uses a test patient and a test schedule, never PHI. Record the state the system reports, what the recovery queue shows, and whether a duplicate appears.
| Case | Setup | Pass condition |
|---|---|---|
| T1 Drop at S1 | End the call after identity is confirmed | Open request shows S1; no slot held; callback or queue entry created |
| T2 Uncertain write | Accept a slot; delay the booking response and end the call | Queue marks outcome unknown; late success is reconciled before another booking action |
| T3 Drop at S5 | Cut the line during read-back | Appointment exists; recovery confirms it; no second booking offered |
| T4 Repeated misunderstanding | Give three unclear answers to the same prompt | System escalates to staff with captured context instead of looping |
| T5 Poor audio | Introduce intermittent noise | System asks for repetition or escalates; it does not record an unverified answer as confirmed |
| T6 Patient calls back twice | Return calls before and after staff recovery | Second contact sees the open or closed request; no duplicate request or booking |
| T7 Staff and AI act together | Staff recovery and automated retry target the same request | No second booking commits; a late conflict is retained for owned correction if prevention fails |
Labelled synthetic example
Suppose a practice runs T2 with a test patient. The caller accepts a 9:40 slot on the following day and the line is cut. The system records S4 at 10:02:14. The recovery queue shows the entry at 10:02:20 with the slot, the patient match and a write status of "not confirmed." The staff member checks both the request's write status and the schedule. In this fictional run, the write is confirmed failed, no retry remains pending and no appointment exists. The owner then books the approved future slot, confirms it with the caller and records S6. In the alternate run, a delayed response reveals the original booking succeeded; the owner confirms that booking instead of creating another. This example is illustrative only. It is not a Linear Health customer result and does not represent measured system behaviour.
Score each case using the kit's scale: not addressed, claimed, demonstrated or verified. Move a case to demonstrated only when you watched it happen, and to verified only when you can see it in production logs. Treat an unowned recovery queue or an unexplained duplicate as a gate, not a point deduction.
Putting it into an evaluation
A short, usable method:
- Agree the state map with your vendor and confirm which states its system records.
- Name the owner and time expectation for the staff recovery queue.
- Write the duplicate lookup rule and confirm which system it queries.
- Run T1 through T7 with test data and record the results in the Operational AI Evaluation Kit worksheet.
- Decide with gates: any unresolved authority, correction or duplicate issue goes to the responsible reviewer before launch.
If you want to run these seven cases against Linear Health, book a demo and bring the table. The goal is to see a recovered request, not a scripted happy path.
Frequently asked questions
What counts as a completed booking on an AI scheduling call?
Should the AI simply call the patient back after a drop?
How do I prevent duplicate bookings on recovery?
How is this different from callback queue management?
Can I use this with any vendor?
Sources
Sources accessed October 30, 2026.
Linear Health publishes educational articles about operational AI for healthcare.