AI Phone Transfers: Give Staff the Request and the Work Already Done

The state map and checklist below are original administrative design templates. They apply to scheduling, referral status and similar practice-approved tasks. Existing clinical escalation rules remain separate.

When a transfer should happen

Start with two groups of administrative handoff triggers, then document what happens when neither covers the situation.

Caller-requested. The caller asks for a person. Acknowledge the request and offer the approved route to a person. If live staff are unavailable, explain that limitation and offer the practice-approved alternative. Collect only context needed for the handoff; a caller should not have to complete an automated questionnaire before requesting staff.

Practice-approved. Your team pre-approves specific situations where the agent should hand off, for example a request outside the agent's configured scope, a caller who cannot be matched to a record, or a question the agent is not permitted to answer. Keep this list written and short. The public Operational AI Evaluation Kit asks vendors for a written in-scope and out-of-scope list and an exception queue with ownership; your practice-approved transfer list is the operational version of that document.

Define a fallback for unrecognized situations instead of assuming the agent should continue. The practice decides when that means a live handoff, an assigned administrative task or another approved path. Do not make a callback promise unless the destination team has accepted that responsibility.

AHRQ's workflow assessment guidance for ambulatory health IT makes the broader point: implementation success depends on recognizing the impact on administrative workflow, not just clinical workflow (AHRQ Workflow Assessment for Health IT Toolkit). A transfer rule that looks fine on a flowchart can still land badly on the person answering the second line.

What the receiving staff member needs

A transfer without context pushes the caller to repeat themselves and pushes staff to rebuild the request from scratch. The proposed minimum context packet is below. Treat it as a draft to adapt, not a standard.

How this packet reaches staff depends on your phone system and your record system. Do not assume a vendor writes any of these fields into your EHR; the evaluation kit explicitly asks for a field-level read and write map and a production integration architecture before scoring an integration above "claimed." Test whether the intended staff member can access the context through the approved channel. If it arrives late or fails, show that state and let staff take over; do not silently present the handoff as complete.

Transfer-state map: track waiting, answered and incomplete separately

The proposed map separates connection events from request ownership. Confirm how your vendor's event names map to these operational meanings.

An answered connection is not a resolved request. A callback attempt is also not resolution. Keep request outcome, transfer result and follow-up ownership as separate fields. The evaluation kit flags as a red flag any demonstration that ends with a message, draft or task instead of a confirmed outcome. Apply the same rule to your own reporting.

Receiving-staff acceptance checklist

Give the people who take transfers a short checklist to use during the first weeks, then sample it afterwards. Each item is yes or no.

1. I could see the caller's original request before I spoke.
2. I knew whether this was caller-requested or rule-triggered.
3. I knew what the agent had already done, so I did not repeat it.
4. I knew the one thing that was still open.
5. I could see the confirmed recovery route, or that none was available.
6. I could distinguish identity details collected by the agent from verification I still had to perform under policy.
7. When I finished, I recorded the outcome where the practice expects it.
8. If I could not finish, I assigned the open item to a named owner.

A transfer that fails items 1 through 4 is a context failure. A transfer that fails items 7 or 8 is an ownership failure. Separate the two in your review, because they have different fixes.

If you want to walk through how this checklist maps to a live transfer flow, you can book a demo and bring your own transfer rules to the session.

Labelled synthetic example: an unsuccessful transfer and the next owner

This example is invented for illustration. It is not a Linear customer experience and not a measured result.

A caller phones a multi-site practice to ask whether a referral has been received. The agent confirms the caller's identity, searches, and cannot find a matching referral. A practice-approved rule says unmatched referral questions go to the referral desk. The agent tells the caller: "I could not find that referral. I am going to transfer you to the referral desk so they can look further." State: Requested, with reason, identity status and the search already performed in the packet.

The referral desk line rings for the configured wait limit with no answer. State: Incomplete, caller still on line. Under the fictional configuration, the agent returns to the caller, explains nobody picked up and offers the approved callback route. The caller agrees, and the system confirms that the task was created for the referral desk lead. Only then does the agent describe the accepted next step. This illustrates a requirement to test, not a capability asserted for any vendor.

The coordinator calls back later, locates the referral under a slightly different spelling, confirms status with the caller, and records the outcome. State: Resolved. The transfer itself failed; the request did not.

Now imagine the same scenario without a fallback owner. The caller waits, gives up, and the request lives nowhere. That is the gap this design exists to close.

How to evaluate a vendor's transfer handling

This is proposed editorial method, not a measured benchmark.

1. Run an approved test case. Ask for one transfer scenario with a missing record and one with a no-answer at the receiving end. The evaluation kit recommends a representative case with normal complexity, missing data and at least one exception, and warns that a scripted happy path is not enough.
2. Inspect the packet. Confirm what staff see, and where. Do not accept a verbal description.
3. Ask who owns the incomplete state. The kit lists as a red flag a vendor that cannot show who owns an exception.
4. Score it. Use the kit's 0 to 3 ladder: not addressed, claimed, demonstrated, verified. Move up only when the evidence is visible and attributable.
5. Treat authority gaps as gates. If the vendor cannot say what the agent is not permitted to decide, do not let a strong demo elsewhere offset it.

Linear Health is operational AI for healthcare that does not replace clinical judgment, with established integrations with athenahealth, eClinicalWorks, NextGen and Greenway Health. Ask every vendor, including those with overlapping voice and patient-access offerings, to show transfer behavior in your own environment.

For related context, see multi-location voice AI for patient access and what works and what breaks in voice AI, and the broader patient engagement platform overview. To test transfer evidence against your own rules, book a demo.

Frequently asked questions

Sources

Sources accessed October 31, 2026.

• Linear Health, Operational AI Evaluation Kit.
• AHRQ, Workflow Assessment for Health IT Toolkit.
• Linear Health, Patient engagement platform.