Why We Built the Phone System—not Just an AI Voice on Top

A client calls a veterinary practice and says, “I need to make an appointment for my dog.”

For the client, this is one request. They do not care which carrier handles the call, which software answers it, or whether scheduling is extension 204. They want the right next step.

Now imagine an assistant that understands the request perfectly but can only dial the practice’s main number. That number leads to a menu. The menu leads to a ring group. The group’s unanswered calls go back to the assistant.

The language problem has been solved. The client’s problem has not.

That distinction explains why PupPilot chose to build at the phone-system layer. We wanted the software interpreting the request to work with the software responsible for routing the call, reaching the team, and recovering when the first plan fails—not merely hand the caller into another system and hope its rules do the right thing.

An intelligent voice is useful. An intelligent voice with the authority to carry out the next step is a different kind of system.

This is not an argument that every AI add-on fails. It is an argument about where control lives, what an integration actually exposes, and what a practice should expect the system to do after it understands a caller.

First, what does “being the phone system” mean?

A PBX—a private branch exchange—is the call-control layer behind a business phone system: the software that connects calls to extensions, groups, queues, voicemail, and other destinations. The important distinction here is between carrying a call and controlling what happens to it.

Building the PBX layer does not mean owning the public telephone network, eliminating carriers, or avoiding every external dependency. Carrier connectivity and application-level call control can be separated. Twilio’s Bring Your Own Carrier architecture, for example, connects an existing carrier to programmable calling capabilities. The carrier can remain while the application gains control over call handling. ¹

Nor are all AI integrations equivalent:

SIP, the Session Initiation Protocol, is a standard used to establish and manage internet-based calls. A good SIP/API integration can be substantially more capable than simple number forwarding. Retell’s documentation illustrates the distinction: its SIP-trunking integration supports transfers, while its dial-to-SIP approach requires the integrator to implement transfer logic because Retell does not control the underlying telephony in that configuration. The same AI platform has different powers depending on how it is connected. ²

The meaningful comparison is therefore not “AI versus old phones.” It is limited attachment versus coordinated call control.

Part I: Where an AI voice add-on can become brittle

1. One conversation can consume several different kinds of capacity

The client experiences one call. Infrastructure may handle several call legs: separate connections between the caller, the original phone system, the AI service, and the eventual recipient. Twilio’s dialing documentation makes this explicit: forwarding an existing call creates a connection to another destination that can be bridged with the original call. ³

Consider an illustrative configuration. A practice has four external trunk channels. Its PBX retains an incoming call while creating an outgoing call to the AI number, and both connections count against that same four-channel limit. Two assisted conversations can occupy all four channels. A consultation or transfer may require further capacity while the existing connections remain active.

That arithmetic is conditional, not a universal “AI doubles your lines” rule. Network-level forwarding, direct SIP connections, and transfers that release an earlier leg can have different resource usage. Multiple SIP dialogs also do not necessarily mean multiple chargeable PSTN channels—or multiple AI sessions. The resource being counted matters. ^1,6

A deployment needs a capacity map, not just a promise that the assistant can answer many callers. That map should identify the carrier’s simultaneous-call allowance, the PBX’s call/session limits, any conference or media limits, and the AI platform’s own quota. It should show what remains occupied during ringing, hold, consultation, and transfer.

The AI platform can be a separate bottleneck. Retell, for example, documents workspace-level concurrency and an inbound-reservation mechanism designed to stop outbound traffic from crowding out incoming callers. A practice’s follow-up campaign and its incoming calls should not be assumed to have independent capacity. ⁴

Calls per second is a different limit. Concurrency measures how many calls are active; a call-creation rate measures how quickly new calls can start. Twilio specifically distinguishes API-created outbound calls, which are subject to its Calls Per Second limit, from inbound and <Dial> calls, which are not subject to that particular limit. Applying one provider’s limit to every call path produces misleading calculations. ⁵

The practical requirement is to test peak arrivals and peak handoffs together. An assistant that can admit the caller but cannot obtain the resources to reach a person has not solved the capacity problem.

2. A transfer is a process—not a phone number

“Can it transfer calls?” sounds like a yes-or-no question. In practice, it conceals several questions: Can it contact the destination? Can it keep the caller connected while doing so? Can it tell what happened? Can it recover if nobody is available?

The distinction exists in the underlying standards. SIP’s REFER method separates accepting a transfer request from reporting the outcome of the resulting operation. A successful acknowledgment is not, by itself, evidence that the intended recipient answered. ⁷

The IETF’s transfer guidance also describes preserving the original signaling relationship so the call remains recoverable when the destination cannot be reached. An unattended transfer that releases that relationship gives up that particular recovery path. This is call-control behavior, not something a better language prompt can manufacture. ⁶

For a practice, the useful outcome is not “the transfer command succeeded.” It is “the right person received the caller,” or “the system recognized that the handoff failed and followed an appropriate alternative.”

This is also where an exclusivity claim would go too far. Third-party voice platforms can support sophisticated handoffs. Retell documents warm transfers that stay on the line, wait for a person, and provide a private briefing; it also documents transfer agents that can bridge or cancel a handoff. Owning the PBX is not the only possible way to deliver those behaviors. The advantage of integrated call control is being able to coordinate them with the rest of the practice’s routing policy rather than depending on a limited external interface. ¹⁹

3. “Answered” does not necessarily mean a person answered

Suppose the system rings the front desk and an on-call mobile simultaneously. The mobile is unavailable, so its voicemail answers immediately. A first-answer-wins strategy can stop ringing the desk before anyone has a reasonable chance to pick up.

This is not a hypothetical limitation of language models. Twilio’s simultaneous-dialing documentation explicitly warns that an office phone system or unavailable mobile can answer quickly and prevent other destinations from ringing long enough for a human to answer. ⁸

Answering-machine detection can help, but it introduces its own tradeoffs. Twilio documents false-human and false-machine classifications, along with settings that trade detection speed against those errors. A long business greeting and a short voicemail greeting are not always easy to distinguish. ⁹

The design implication is straightforward: define what qualifies as a successful handoff. Depending on the workflow, that might require staff acceptance, a supervised introduction, or another confirmation mechanism—not simply a network “answered” event.

Even a fully integrated PBX needs to make that distinction. Control provides the ability to implement a policy; it does not make every answer signal reliable evidence of human receipt.

4. Two routing authorities can create a loop

Imagine this route:

Main number → AI assistant → main number → AI assistant.

The assistant is trying to reach staff. The existing phone system is following its instruction to send incoming calls to the assistant. Each component can be behaving exactly as configured while the combined system fails.

A subtler version appears only when the destination is busy: the AI transfers to a department, the department’s unanswered-call rule forwards to the AI, and the assistant tries the same department again. A quiet demonstration may work; a busy afternoon may expose the cycle.

SIP includes hop-limiting and loop-related mechanisms. But the protocol’s Max-Forwards field limits the path of a request. An application that repeatedly starts new calls can create a higher-level cycle that a hop limit on each individual request does not, by itself, prevent. That is an architectural inference from the protocol’s scope, not a claim that all SIP systems loop. ¹⁰

The safeguards should be explicit: a protected staff-transfer destination distinct from the public entrance where needed, remembered routing history, a maximum number of attempts, an overall deadline, and a terminal fallback that does not re-enter the same route.

A prompt that says “do not get stuck in a loop” is not a substitute for a routing system that prevents the loop.

5. Separate schedules and timers can contradict one another

Consider another illustrative configuration. The assistant believes the practice is open until six. The PBX begins after-hours routing at five thirty. The department’s mobile forwards to voicemail after twelve seconds, while the assistant waits thirty seconds before considering the handoff unsuccessful.

No component needs to be offline for the client to have a poor experience. The problem is conflicting policy.

A robust deployment should test opening hours, holidays, lunch closures, temporary overrides, ring durations, queue behavior, and unanswered-call destinations as one route. Those tests should include a destination becoming unavailable during the attempt—not merely being unavailable before it begins.

It should also distinguish a phone that supports another call from a route that is willing to offer it one. Call-waiting capability, group membership, queue eligibility, and staff availability are separate configuration questions. Modern routing systems make these relationships explicit; Amazon Connect’s routing profiles, for example, determine which contacts an agent can receive and how simultaneous work across channels is handled. ²⁷

Putting policy in one coordinated system reduces the number of independently maintained assumptions. It does not remove the need to test them.

6. Access to the audio does not imply control of the call

An integration may be able to transcribe a call without being able to speak into it. Another may support conversation but not the exact transfer, keypad, or concurrent-media operation the application needs.

Twilio’s Media Streams documentation distinguishes unidirectional streams, which receive audio but cannot send it back, from bidirectional streams. It also documents limitations on audio tracks, outbound DTMF, and the execution of subsequent call instructions while a bidirectional stream remains connected. These are specific interface constraints, not problems an AI model can reason its way around. ¹¹

Keypad navigation has a separate interoperability layer. RFC 4733 explains why telephone-event payloads exist: low-rate voice codecs cannot be assumed to preserve tones accurately enough for automatic recognition. Even when digits can be sent, automating a department’s existing menu still depends on the menu’s sequence and timing. ¹³

There is also a difference between establishing a call and carrying usable audio. Twilio’s trunk troubleshooting guide documents unsupported media formats, one-way audio caused by media-address or firewall configuration, and calls that initially connect but later drop because signaling acknowledgments do not arrive correctly. These are examples of telephony interoperability failures that can exist below an otherwise functioning AI conversation service. ³⁴

The test should continue through hold, transfer, and reconnection. Hearing the greeting is not sufficient evidence that the entire media path works.

A voice demonstration establishes that an assistant can converse on that connection. It does not establish that the connection exposes everything required to manage a production call lifecycle.

7. Latency is an end-to-end property

A slow conversation is not necessarily a slow language model.

The delay a caller experiences can include transporting audio, deciding that the caller has finished speaking, recognizing speech, retrieving information, generating a response, calling another application, synthesizing speech, and delivering buffered audio back to the handset. Some stages can overlap, so adding a collection of vendor averages is not an accurate end-to-end measurement. Retell’s troubleshooting guidance separates transcription, model, speech-synthesis, and network-related causes rather than treating latency as one model setting. ¹⁵

Microsoft similarly distinguishes speech-synthesis service latency from the latency observed by a client, which includes network transport. A fast first audio byte at the speech provider is not the same event as sound reaching the caller. ¹⁴

Additional bridges or poorly placed media services can create avoidable delay, but “add-on” is not itself a latency measurement. A well-engineered integration can outperform a poorly engineered integrated system. The reason to control the call path is to make that path measurable and adjustable—not to declare it automatically fast.

Human conversation helps explain why this matters. Levinson and Torreira’s research on turn-taking describes typical transitions on the order of a few hundred milliseconds, while also showing substantial variation. That is useful context, not a universal pass/fail threshold for an assistant answering a complex question. ¹⁷

Interruption handling matters too. When a caller starts speaking, stopping new speech generation is insufficient if old audio remains queued for playback. Twilio’s streaming protocol provides a clear-buffer operation specifically for interrupting already-buffered audio. ¹²

The useful tests therefore include caller-perceived response delay, long-tail delays, interruption-to-silence time, and dead air during transfers. Metric definitions need inspection: Retell documents that its reported e2e field excludes the network trip from its server to the user’s frontend and does not count tool-only turns. A dashboard labeled “end to end” should not automatically be treated as a complete recording of the caller’s waiting experience. ¹⁶

8. Identity and context can disappear between systems

A transferred call carries several different kinds of identity: the original caller, the number they dialed, the forwarding system, the transfer destination, and the application’s internal conversation identifier.

They are not interchangeable. The receiving team may need to know both who called and which location or department the person originally tried to reach. SIP’s History-Info extension exists to convey how and why a request was redirected. The existence of that standard is a reminder that routing history has to be represented and preserved; it does not appear merely because two systems can exchange audio. ¹⁸

Caller-ID behavior also varies by transfer method and carrier support. Retell documents that an unsupported caller-ID override can cause a transfer to fail, and that custom SIP metadata can be stripped when a transfer passes through the public telephone network. ¹⁹

For a practice, the implication extends beyond caller ID. The patient, reason for contact, information already collected, and promises already made should travel with the handoff through an appropriate data channel.

That context also needs verification. A household phone number is a useful matching clue, not proof that the current speaker is authorized to receive every record associated with it. A unified platform should preserve the distinction between a likely match, a confirmed identity, and permission to perform an action.

9. Fragmented events can produce misleading records

An external call can leave several records: the original inbound call, a forwarded leg, the AI conversation, the attempted transfer, and a subsequent callback. Without correlation, one request can appear to be multiple unrelated contacts—or a successful interaction can conceal an unsuccessful handoff.

Even event delivery needs engineering. Twilio Event Streams documents retries, possible duplicate delivery, and events arriving out of order. An application consuming such a stream needs to recognize repeated events and reconcile ordering rather than blindly treating every notification as a new action. This is a documented property of that service, not a claim about every telephony webhook. ²⁰

Our design requirement is to make the request—not the individual vendor log entry—the organizing record. That requires linking call legs and attempts to a stable interaction identifier, recording the route and policy version, and distinguishing an attempted action from a confirmed outcome.

The same discipline should apply to cost analysis. Before comparing a bundled phone system with an add-on, map which provider meters which resources and when those resources are released. Ringing, waiting, consultation, and a completed handoff may have different billing treatment. An extra connection does not establish the total price difference; a complete call-path cost model does.

10. Recovery can fail at a different layer from the AI

An assistant can be unavailable because its model connection failed, its speech service failed, its media connection disappeared, or its capacity was exhausted. Retell’s documented disconnection reasons distinguish these cases, including lost WebSocket connections, missing audio, transcription failures, and concurrency limits. A single generic “AI failed” category discards useful operational information. ²²

The fallback has to match the failure. Routing around an unavailable model is different from routing around a failed PBX, a clinic internet outage, or an upstream carrier problem. A route that depends on the same unavailable service is not an independent fallback.

Twilio’s failover guidance explicitly recommends placing a fallback application in a different availability zone, region, or cloud provider where appropriate. It also describes simpler fallbacks, such as redirecting to another support line. ²¹

Integrated control can make recovery easier to coordinate. It can also concentrate failure if every route depends on one component. The requirement is not “everything in one process.” It is a coherent policy with deliberately separated failure paths.

A further distinction belongs in every test plan: rerouting new calls does not prove that a call already in progress will survive. Admission, active-call recovery, and the preservation of any unfinished request should be evaluated separately.

Part II: What becomes possible when the request drives the route

11. The important change is not “press a button” becoming “say a word”

Replacing “press two for scheduling” with “say scheduling” changes the input method. It does not change who is responsible for understanding the practice’s organization.

Intent-based routing starts elsewhere: what is the person trying to accomplish?

“I need to bring her in.” “Thursday no longer works for us.” “Can someone confirm the recheck was booked?” These may belong to related workflows without sharing the word scheduling. Conversely, a sentence containing the word appointment may describe a concern that needs the clinical team rather than a routine scheduling queue.

Natural-language intent recognition is not new, nor is it unique to an integrated PBX. Dialogflow CX, for example, documents intent matching, confidence thresholds, and no-match events. The architectural change we care about is connecting interpretation to the policies and controls that can carry out the next step. ²⁶

For PupPilot, that means separating the caller’s request from the destination that happens to handle it today. A department can change its staffing, hours, or endpoint without forcing clients to learn a new vocabulary.

The router should ask, in effect: what is being requested, what may the system do, who should handle it now, and what should happen if that person is unavailable?

12. A scheduling request is a workflow, not merely a destination

Here is an illustrative design—not a claim that every practice has the same workflow or every integration supports every step.

The client asks for an appointment. The system establishes the relevant client and patient, clarifies the request where necessary, and applies the practice’s policy. If the policy permits a direct booking, it offers appointment times and books the one the client chooses, whether the practice is open or closed. If the scheduling team is available and a live conversation is appropriate, it routes the call there with the collected context. If review is needed, it creates or updates a request for the responsible team instead of presenting the appointment as booked. If the practice is closed, it uses the agreed after-hours process. If the caller describes a concern outside a routine administrative request, it follows the appropriate human-escalation policy.

Clinical decisions remain with the authorized clinical team. Understanding “appointment” is not authorization to diagnose, book outside the practice’s rules, or promise a time that has not been confirmed.

That pattern is:

Understand the request → check policy and context → choose a permitted next step → confirm what happened → retain ownership of anything unfinished.

PupPilot’s published reason analysis helps explain why this distinction matters. Scheduling appeared in 35.6% of the business-hours reason-analysis items, and basic questions in 10.0%. Items could carry multiple labels. These are different kinds of work, not interchangeable units of phone traffic; the study describes requests, not proof that those requests were completed. ²⁵

A stronger router does not simply find the most plausible department. It connects the request to the right process.

13. The route can respond to availability without making callers start over

The same request may need different handling at ten in the morning, during lunch, and after closing. It may need a different path when the designated person is already helping another client.

PupPilot’s published routing design separates the entry policy for a number, the request or intent, the destinations to try, and the behavior when nobody answers. It also describes route preview and department-specific destinations. Those are useful building blocks because they separate what the caller needs from the mechanics of reaching someone. ³¹

The broader design goal is continuity. A failed attempt should not erase what the system already learned. The caller should not have to navigate the public menu again merely because the first destination did not answer.

That does not require AI to answer every call first. A practice may choose human-first service, overflow assistance, after-hours coverage, or different policies for different numbers. How AI connects to the phone system and when AI participates are separate decisions. Building integrated call control should make those choices easier, not eliminate them.

Nor does unlimited automated conversation create unlimited human attention. A sound routing policy must account for the receiving team’s capacity, including work outside the phone channel.

14. Omnichannel means preserving the work—not just displaying several channels

The argument reaches beyond voice.

A client might leave a voicemail, send a text with the patient’s name, and later email a document. Three messages are not necessarily three requests. But neither should every message from the same household be collapsed into one case: two pets or two unrelated problems may require separate work.

This is the connection to our AAHA session Beyond the Scribe. Its central design proposal was one router across communication channels, rather than separate assistants attached to separate inboxes. The session’s omnichannel scenarios were illustrations of an operating model, not measured comparative outcomes. ²⁹

A genuine cross-channel workflow needs a persistent request record: what the client needs, which patient it concerns, who owns the next step, what has already happened, what is still pending, and which communication methods are appropriate.

For example, a phone call might establish a records request; an email might supply the receiving hospital’s details; a staff member might complete the work; and a text might tell the client it is finished. The channel changes. Responsibility for the request should not reset.

Being the PBX does not automatically create that capability. Voice forwarding does not connect an email inbox or establish the state of a text conversation. Messaging and chat connections, identity matching, permissions, and work-state management still have to be built. A sufficiently capable platform can also coordinate them without replacing the carrier.

PupPilot’s current communications description includes a shared work-item inbox and client history across phone, text, and email. Extending the same request model to web chat and other channels is an architectural opportunity; each channel still requires its own implemented connection and rules. ³²

The point of controlling the phone layer is to make the live call a full participant in that system rather than an opaque event that another product reports afterward.

15. Cross-channel routing should protect the team’s attention

A shared inbox is not enough if the system assigns a phone call, several chats, and an urgent task to the same person without considering their current work.

Amazon Connect’s documentation provides an established example of cross-channel routing that evaluates the contacts an agent is already handling and the concurrency policy before offering more work. This is not a capability invented by generative AI. It is an operational principle that an AI-enabled front office should respect. ²⁸

Our design implication is to route based on the work and the capacity to do it—not simply to the next nominally available address. Some requests deserve a live conversation. Others can become clearly owned asynchronous tasks. Some can be completed through an approved workflow without interrupting anyone.

This also gives repeat contact a different meaning. Before creating another callback, the system should check whether the request is already owned, awaiting a clinical decision, or completed. Where the relationship is uncertain, it should preserve the messages for review rather than silently merge them.

In our AAHA session The Front Desk of the Future Is Not a Desk, routing was treated as work hidden inside several front-office roles. The objective was not to automate every relationship. It was to reduce the coordination burden so people have more attention for conversations that need them. ³⁰

Part III: Control creates responsibility

16. Measure the handoff—not just whether the AI answered

PupPilot’s September 2026 phone-line research found that 26.1% of eligible assistant-to-staff transfers did not reach a person within the ring window. At 1 p.m., that share was 35.2%. These figures describe the handoff after the assistant had already answered; they are not a conventional missed-inbound-call rate. ²³

The finding does not establish why every handoff failed, prove that a different architecture would have succeeded, or show that automation fixes staffing constraints. The panel is observational, vendor-operated, and uses defined eligibility rules—not a randomized comparison of PBX-native and add-on products. ²⁴

It does establish a useful question: What happens after an assistant says it will connect the caller?

For this architecture, we would evaluate the whole sequence: attempted contact, admission to the phone platform, connection to the assistant or staff, correct identification of the request, attempted handoff, confirmed receipt, and eventual request outcome. Those stages should not be collapsed into a single “success” percentage.

An AI service’s own logs cannot establish what happened to calls that never reached it. The complete admission picture requires upstream phone-system or carrier evidence as well. Similarly, a conversation transcript cannot, by itself, establish that a booking was committed in the practice-management system or a records request was completed.

The standard should be evidence of the next step, not merely a fluent statement that it happened.

17. The AI should interpret the request—not rewrite the rules

Intent-based routing should not mean giving a language model unrestricted authority over phone numbers, records, or clinical workflows.

The safer design separates interpretation from permission. The model proposes a structured intent and relevant details. Application policy determines which destinations and actions are allowed, what information is required, and where human approval is necessary. A caller’s request is input to that policy, not permission to bypass it.

OWASP’s guidance on excessive agency recommends limiting an AI system’s functionality and permissions, avoiding unnecessary autonomy, and requiring approval for sensitive operations. Those principles apply directly to a voice agent with transfer and workflow tools. ³³

For a practice, that means preserving a clear route to a person, asking for clarification when interpretation is uncertain, restricting external dialing, respecting record-access boundaries, and keeping clinical decisions with the clinical team. A transcript, email, or web message should not be allowed to change those rules merely because the assistant can read it.

The destination of a call is an operational decision. The system should be able to explain which policy authorized it.

18. A phone-system provider inherits the unglamorous work

There is a cost to our architectural choice: broader responsibility.

A practice does not judge its phone system only on the assistant’s voice. It also needs dependable ordinary calling, hold and transfer behavior, usable desk and mobile endpoints, voicemail, appropriate emergency-calling arrangements, support, and a migration that does not lose the main number. Local power and internet failures, upstream outages, and the practice’s particular equipment all belong in the deployment review.

Those are acceptance requirements, not benefits to assume from the label “integrated.” The phone path should have a tested behavior when the optional AI component is unavailable. Changes should be versioned and reversible. A failure should be traceable without asking the client to describe it a second time.

A well-integrated add-on can be a sensible choice when the existing system exposes the necessary controls and the scope is clear. A limited after-hours capture workflow has different needs from a platform expected to coordinate live transfers, clinical-team availability, and continuing work across channels.

Our choice was to build for the latter. We wanted the call-control layer to be part of the product we could design, observe, and improve—not an external boundary at which our responsibility stopped.

The phone is the starting point. The request is the unit of work.

The architecture question is ultimately not whether an AI can answer a telephone.

It is whether the system that understands a request can take the appropriate next step, recognize when that step did not happen, and keep the request from disappearing between components.

Building at the PBX layer does not eliminate limits, interoperability, outages, or the need for human judgment. It gives us a place to coordinate those realities with the intelligence interpreting the call.

That is why we built the phone system—not simply to put an AI voice at the front of it, but to make understanding the caller the beginning of a dependable workflow.

---

Research note: This article combines primary telephony standards, official platform documentation, PupPilot’s published observational research, and explicitly identified design examples. Standards and documentation establish mechanisms and supported behaviors; they do not establish the market-wide frequency of failure or a measured reliability advantage for PupPilot. No comparative deployment benchmark is claimed. Sources were reviewed October 2, 2026.

Technical appendix: what to verify before putting an assistant on the main number

This appendix is a proposed evaluation framework, not a report of tests performed on PupPilot or any other vendor. The cited documentation establishes the background mechanisms. The scenarios and acceptance criteria below are original engineering recommendations. Apply them to integrated and third-party systems alike.

A. Capacity worksheet

For every state—new call, AI conversation, hold, outbound consultation, completed transfer, and disconnect—record the resources occupied at each provider. Do not use “lines” as a substitute for naming the resource.

Resource	Record for this deployment	Question to resolve
Carrier/trunk channels	Limit, directionality, channel occupancy by call state	Does forwarding retain an inbound channel and consume an outbound channel on this same quota?
PBX calls/sessions	Licensed or enforced limit and treatment of external/internal legs	Does the PBX count the conversation, separate legs, or another unit?
Conference/media resources	Mixer, stream, transcoder, or participant limits	Is capacity needed temporarily during a warm handoff?
AI sessions	Workspace, tenant, or organization quota	Do outbound calls or another clinic share the quota?
Call-creation rate	Limit, affected interface, queued/rejected behavior	Does it apply to API calls, SIP trunk setup, internal dialing, or some subset?
Human attention	Eligible staff, current work, acceptance rules	Does reaching an endpoint mean a staff member can accept the work?

These are separate constraints. Provider examples document forwarding and parent/child call resources, workspace concurrency, and interface-specific rate limits; none supplies a universal multiplier for all architectures. ^3,4,5

Illustrative arithmetic. With four available trunk channels, two retained external legs per assisted conversation consume all four channels at two simultaneous conversations. That does not describe an upstream-forwarded call that does not occupy those same resources. Recalculate from the actual path, and include ordinary staff calls plus temporary consultation capacity. Do not substitute this arithmetic for a busy-period load test.

B. Failure-mode and acceptance-test matrix

Area	Scenario to exercise	Required evidence or behavior
Admission	Incoming calls arrive while staff and AI are already busy.	Identify the first limiting resource and demonstrate the declared overflow response rather than losing the call silently. 3,4
Call-creation bursts	Several transfers begin together.	Measure setup delay and rejection/queueing behavior for the actual dialing interface; do not confuse CPS with concurrency. 5
Shared quotas	Outbound follow-up is running at the same time as inbound demand.	Show the reservation or isolation that protects incoming calls; confirm which tenants share capacity. 4
Transfer outcome	The transfer request is accepted, but the destination is busy or unreachable.	Do not mark human handoff complete merely because the request was accepted; preserve the appropriate recovery path. 6,7
Recipient readiness	An automated greeting answers before a person.	Show the distinction between network answer and staff acceptance, and demonstrate the policy for uncertain detection. 8,9
Parallel ringing	A mobile voicemail answers before the front desk.	Verify the intended recipient-selection policy and that unattended endpoints cannot silently claim a human-required handoff. 8
Routing cycles	A department’s unanswered route points back to AI.	Stop the cycle with shared route history, bounded attempts, and a terminal alternative; test cycles formed by newly initiated calls as well as signaling hops. 10
Schedule mismatch	The assistant and department have different holiday, lunch, or temporary-closure states.	Resolve the governing policy explicitly; preserve the request if availability changes during routing.
Queue eligibility	A handset supports another call but the group or agent profile does not.	Demonstrate actual offering/acceptance behavior rather than inferring capacity from handset features. 27
Interface permissions	The AI receives audio through a connection without native transfer control.	Enumerate supported operations, identify custom implementation responsibilities, and test those operations on the production path. 2,11
Media interoperability	Audio works initially, but fails after hold or transfer.	Validate both directions across the actual endpoint mix; inspect supported formats, reachable media addresses, firewall policy, and signaling completion. 34
Keypad navigation	A destination requires extension digits or changes its menu.	Verify digit transport and timing; prefer a direct controlled destination where feasible rather than a brittle menu script. 13
Response delay	The assistant must retrieve information or call a slow backend.	Measure what the caller hears and waits through, including turns excluded from a vendor’s reported latency metric. 14,15,16
Interruption	The client starts speaking while a response is already playing.	Measure how quickly playback stops, not merely when generation is canceled; check queued audio. 12
Caller/context identity	An anonymous caller, shared household number, or forwarded call reaches the team.	Preserve available routing history and distinguish matching from authorization; avoid depending on unsupported caller-ID behavior. 18,19
Event reconciliation	Duplicate, delayed, or out-of-order notifications are delivered.	Maintain one coherent request state; make processing safe to repeat and prevent a stale event from undoing a later confirmed outcome. 20
Abandonment cleanup	The caller hangs up while staff are being dialed.	Cancel unused attempts, release resources, and retain any legitimate unfinished work without treating abandoned consultation as success.
Failed downstream action	A scheduling or task-writing operation times out after submission.	Check the downstream result before retrying or claiming completion; distinguish pending, failed, and confirmed actions.
AI dependency outage	The model, speech service, or media connection fails.	Exercise the declared fallback without depending on the same failed component; capture the specific failure reason. 21,22
Broader outage	The clinic loses connectivity or the call-control service is unavailable.	Test new-call routing separately from active-call survival and show which independent infrastructure performs recovery. 21
Cross-channel continuity	A client follows a call with a text and email about the same request.	Preserve ownership and pending state, avoid duplicate work, and do not merge distinct patients or problems solely because the household matches.
Cross-channel workload	Staff already handling a live interaction receive additional messages and tasks.	Enforce explicit attention/capacity rules rather than using nominal availability alone. 28
Unauthorized actions	A caller or message asks the assistant to bypass a rule or dial an arbitrary destination.	Enforce permissions outside the model, restrict tools and destinations, and require approval for sensitive actions. 33
Change management	A route, endpoint, model, or integration is changed.	Re-run the affected scenarios, record the deployed version, and demonstrate rollback without losing unfinished requests.

Some of these risks come from adding another system boundary. Others exist in every programmable phone deployment. Integration changes who can coordinate the response; it does not remove the need for the response.

C. Outcome measures worth publishing

Use a measurement specification with an explicit unit, denominator, time window, exclusions, and data source. These proposed measures are not existing PupPilot performance claims.

Admission success. Of eligible inbound attempts observed at the declared upstream boundary, how many reached the intended service? State the boundary; an AI-provider denominator excludes calls that never reached that provider.

Human-handoff completion. Of handoffs requiring a person, how many reached a confirmed appropriate recipient within the configured policy? Report unanswered, machine-answered, caller-abandoned, and technically failed attempts separately where evidence supports the distinction.

Recovery completion. Of unsuccessful first attempts, how many produced the intended alternative—another accepted handoff, a correctly owned task, or another agreed outcome? A fallback being invoked is not the same as that fallback succeeding.

Caller-perceived responsiveness. Measure from the end of caller speech to audible response at the relevant observation point. Include the median and long-tail distribution, interruption-to-silence, and transfer dead air. Disclose excluded turns and any unmeasured last-mile delay. ¹⁶

Request completion. Of eligible requests of a defined type, how many reached a verifiable completed state? A transcript saying “booked” is not the database confirmation. Segment scheduling, records, and other workflows rather than combining unlike outcomes.

Repeat contact and duplicate work. Track repeat contact linked to an unresolved request, while preserving legitimate new requests. Evaluate incorrect merges and missed links alongside any reduction in duplicate tasks.

Operating cost. Report cost per appropriate completed outcome where feasible, alongside the underlying call and AI usage. Disclose scope and avoid claiming that a shorter call is necessarily a better result.

D. A fair comparative study

To establish an actual architectural advantage, compare defined deployments under matched scenarios: the same call intents, destination availability, source networks, traffic bursts, and outcome criteria. Include a well-configured SIP/API integration, not just an intentionally weak forwarding setup. Where possible, hold the speech/model stack constant so a voice-quality change is not mistaken for a routing advantage.

Predefine primary outcomes—such as completed human handoff, successful recovery, resource occupancy at a stated load, and caller-perceived delay. Report the number of attempts, uncertainty, exclusions, architecture diagrams, and configuration versions. Keep live operational evaluation separate from laboratory results. This article provides the rationale and testable hypotheses; it does not supply that comparative experiment.