A 24/7 Voice Agent Needs a 12-Case Availability Test

Short answer: “24/7” describes when a number may accept calls; it does not prove that a caller can complete a useful, safe task at every hour. Before choosing an AI phone agent, test the whole caller path: carrier, SIP routing, media, speech services, model, approved data, text-to-speech, transfer destination and the people or fallback process behind that transfer. If one link in that chain has no tested alternative, describe the service as best-effort or state the limitation plainly.

For a concrete example, the Vocalis garage reception guide explicitly tells buyers to check what happens when the schedule or telephony is unavailable. That question is more useful than asking only whether the agent answers outside office hours. This article turns it into a reproducible acceptance protocol for any inbound voice service. It does not report a vendor uptime result, certify a product, or promise a target percentage.

A buyer should leave with three things: a caller-visible definition of success, a failure-routing plan with named owners, and evidence from controlled calls at the times and through the routes that matter. A green model dashboard is not enough. If the line rings, audio is silent, a queue has no staffed destination, or a transfer hangs without an honest message, the service has failed from the caller’s point of view even if the language model endpoint stayed healthy.

What “available” must mean to the caller

Start by writing the service promise in ordinary language. “Calls are accepted at any time” is a routing promise. “A caller can get an approved answer or a reliable next step at any time” is an outcome promise. They are not interchangeable. A system can accept a call and then provide silence, an unsupported answer, a dead-end transfer, or a callback that nobody owns.

Choose a useful outcome for each allowed call class. For a public-hours question, it might be an answer that matches the currently approved schedule. For a booking request, it may be a confirmed reservation returned by the system that owns the calendar, rather than the agent saying “you are booked.” For an urgent or out-of-scope request, success may mean a prompt, understandable handoff to a staffed human or a clearly described alternative. Define the boundary before measuring; otherwise a vendor and buyer can count different things as success.

Google’s SRE guidance recommends user-oriented service indicators and distinguishes an aggregate operation-success measure from counting only time periods when a service is “up.” Its availability table also shows why a percentage is meaningless without a window and a definition. Apply that idea to calls: the denominator should be all in-scope test calls that reached the agreed test entry point, including calls that failed before the model started. Do not quietly remove carrier failures, transfer failures, after-hours cases or timeouts because they make a dashboard look worse.

A simple outcome availability measure is:

useful-outcome availability = in-scope calls ending in the predefined useful outcome / all in-scope calls offered to the tested entry path

Keep technical reachability, task completion, response correctness, transfer completion and caller comprehension as separate measures. One composite score can hide a severe defect. For example, 11 calls that provide a correct answer cannot compensate for a twelfth call that drops a caller trying to report a safety-critical issue. Define severity-specific stop rules as well as an aggregate measure.

Map every dependency before accepting a “24/7” claim

A voice agent is a chain of services, not a model with a telephone attached. The public number may be hosted by a carrier; a session border controller or telephony platform handles signaling; separate systems carry audio; speech recognition converts sound to text; the model decides what to say or do; retrieval and business tools supply current information; speech synthesis creates audio; and transfer, queue or callback systems deliver the next step. Power, networks, account limits, credentials, certificates, regional configuration and human staffing can each become part of the path.

Google Cloud’s contact-center high-availability documentation describes dependencies on external CPaaS providers, network readiness, telephony redundancy, regional architecture and configuration alignment. It distinguishes managed-provider redundancy from customer-managed carrier choices and notes that failover timing can depend on the platform. Those are examples from one product, not a universal design prescription. The useful lesson is architectural: ask which party owns each hop, who can initiate failover, and whether the fallback preserves the caller’s task rather than merely keeping a socket open.

OpenAI’s telephony and SIP documentation similarly treats a phone connection as an integration path with signaling, acceptance and transfer behavior. That implementation detail does not establish that any specific deployment has carrier redundancy, staffed destinations or an end-to-end service guarantee. Ask the provider to draw the deployed path using the actual carrier, trunk, platform, model, region and transfer destination in your contract. A generic architecture slide cannot substitute for that map.

flowchart LR
  A[Caller dials public number] --> B[Carrier and number routing]
  B --> C[SIP trunk or telephony platform]
  C --> D[Media and audio transport]
  D --> E[Speech recognition]
  E --> F[Agent model and policy]
  F --> G[Approved knowledge and business tools]
  G --> H[Speech synthesis]
  H --> I[Caller hears useful response]
  F --> J[Human transfer or queue]
  J --> K[Named staffed destination]
  B -. failure .-> X[Carrier fallback or truthful outage message]
  C -. failure .-> X
  D -. failure .-> X
  E -. failure .-> Y[Safe prompt, human route, or callback]
  F -. failure .-> Y
  G -. stale or unavailable .-> Y
  H -. failure .-> Y
  J -. destination unavailable .-> Y

Do not multiply provider uptime figures to invent a whole-system commitment. Component percentages may use different measurement windows, request populations, exclusions and remedies. A component SLA is evidence about that component under its own definition; it is not automatically an SLA for the caller’s successful task. Instead, document the end-to-end path and measure the user-visible result with a repeatable synthetic call. If a supplier will not disclose component details, record the uncertainty and make the supplier’s own contractual outcome definition explicit.

The 12-case acceptance protocol

The following is an original, synthetic acceptance set written on 7 November 2026. It contains twelve designed scenarios, not twelve field calls or a measured reliability sample. Its purpose is to make a procurement or release review repeatable. Adapt the expected safe behavior to the actual service, then run each case against the production-equivalent phone route with test identities and non-production records. Never create a real booking, disclose real customer information or trigger emergency services while exercising a failure case.

Case	Injected condition	Required caller-visible behavior	Evidence to keep
1. Normal after-hours call	Call outside staffed hours, with all dependencies healthy	State the permitted scope and complete one allowed task or explain the next step	Call ID, route, task result, transcript/audio timestamps
2. Number or carrier route unavailable	Disable or redirect the primary test route under an approved change	Secondary route answers, or caller reaches an honest carrier-level message	Carrier route, failover event, time to answer
3. SIP signaling rejection	Reject the test INVITE or return the configured failure response	A documented alternate route or useful failure message; no silent disconnect	SIP response, route decision, caller recording
4. Media path broken	Allow signaling but block or interrupt RTP/media in the test environment	Detect missing audio and end or transfer safely; never pretend to hear the caller	RTP/media counters, silence duration, result state
5. Speech recognition unavailable	Return a timeout or controlled service error	Ask once for a safe retry or route to a defined alternative	ASR request ID, timeout, spoken prompt, final state
6. Model unavailable or quota exhausted	Use a provider-supported test failure or sandbox fault	Do not invent a successful answer; use fallback or state the limitation	Model status, error class, fallback selected
7. Knowledge source stale or offline	Mark one approved source stale or unavailable in a test copy	Abstain, use a verified alternative, or create a human task	Source version, retrieval result, answer comparison
8. Speech synthesis fails	Force a controlled TTS error after the system has a response	Retry within a bounded policy or switch to a legible alternative	TTS event, retry count, caller-heard result
9. Transfer destination offline	Make the intended extension unavailable	Offer only configured alternatives; do not claim a transfer succeeded	Destination status, transfer event, caller message
10. Queue open but unstaffed	Route to a queue with no eligible responder	Announce the actual wait/alternative, or record a callback with owner and consent	Queue state, wait announcement, callback record
11. Region or platform component lost	Use a vendor-approved sandbox or a planned maintenance exercise	Route through a genuinely independent path or clearly state service degradation	Region, failover path, configuration comparison
12. Recovery after dependency returns	Restore one failed dependency while a test call is in progress	One coherent continuation or a clean restart; no duplicate action or lost task	Correlation ID, duplicate check, final task state

The expected behavior must be agreed before the test. “The bot spoke” is not a pass if it gave the wrong opening-hours answer. “A transfer was initiated” is not a pass if the caller never reached a human or a working queue. “A callback was created” is not a pass if it lacks consent, a validated number, an owner and a status that the receiving team can see.

For each case, record the exact build/configuration, test time and time zone, originating number class, route, injected fault, expected result, observed result, event IDs and reviewer. Repeat only where the behavior is nondeterministic or where the supplier’s agreed test plan requires repeats. Do not average away a critical failure. A single unsafe response can be a release blocker even if a descriptive percentage looks high.

A pass means the observed outcome met the predefined rule for that case. A fail means it did not. “Not run” is not a pass. “Could not inject this fault” is an evidence gap. If a platform does not permit customer-controlled fault injection, ask the supplier to provide a dated demonstration, a test environment, an incident simulation or a contractual fallback statement. Label evidence supplied by a vendor separately from tests run by your team.

Decide what the denominator includes

The test denominator is often where availability promises become incomparable. Decide whether your measure begins when the caller dials, when the public carrier accepts the call, when the telephony platform creates a session, or when the AI service receives audio. Each boundary answers a different question. If your responsibility is the total customer experience, begin at the public number or at the earliest observable carrier event you can access, and separately publish any exclusions outside your control.

Record offered attempts as well as connected calls. If your monitoring only samples calls that reached the agent, it cannot detect a number-routing failure that prevented the agent from starting. If you exclude planned maintenance, disclose the schedule and what a customer hears during it. If you count a queue as successful despite no staff being available, you have measured queue entry, not resolution. If one call retries twice, decide whether the denominator is one customer attempt or three technical attempts; do not switch definitions between reports.

The aggregate measure can be written as A = U / N, where U is the number of in-scope calls that reached their predefined useful outcome and N is the number of in-scope calls offered at the defined entry boundary. Report U, N, the date range, the service window, test/live traffic split, excluded cases and the raw failure categories. A percentage without those values is difficult to audit and easy to misread.

For a synthetic acceptance suite, do not call 12/12 “99.9% uptime.” Twelve selected cases do not sample the distribution of real calls, volume by time of day, carrier events or rare failures. The 12-case set is a coverage checklist. Its result should read “12 specified scenarios passed in this configuration on this date,” not “the service is 100% available.” For service-level tracking, use production evidence under a defined privacy and retention policy, while keeping test calls identifiable as tests.

Google SRE explains that aggregate operation-based availability can be more useful than wall-clock time for services with variable load or partial failure. Its published examples are not a target for a phone agent. Use them to learn why a chosen SLI should match what users experience, not to copy a percentage from a different service. The test owner must choose and justify any threshold based on the harm of an unanswered, incorrect or abandoned call.

A small executable control for the test log

The following Python script checks a CSV export from the acceptance run. It expects one row per test case with case_id, expected_useful and observed_useful fields containing 1 or 0. It reports missing cases, mismatches and a descriptive fraction. It does not place calls, validate transcripts, infer the quality of an answer, or turn a twelve-case synthetic set into a production uptime estimate. A human reviewer must decide whether each observed outcome was actually useful and safe.

#!/usr/bin/env python3
import csv
import sys
from pathlib import Path

REQUIRED = {str(i) for i in range(1, 13)}


def main(path: str) -> int:
    with Path(path).open(newline="", encoding="utf-8") as f:
        rows = list(csv.DictReader(f))

    seen = {}
    for row in rows:
        case_id = row.get("case_id", "").strip()
        if case_id not in REQUIRED:
            print(f"ERROR unknown case_id={case_id!r}")
            continue
        if case_id in seen:
            print(f"ERROR duplicate case_id={case_id}")
        expected = row.get("expected_useful", "").strip()
        observed = row.get("observed_useful", "").strip()
        if expected not in {"0", "1"} or observed not in {"0", "1"}:
            print(f"ERROR case {case_id}: use 0/1 for expected_useful and observed_useful")
            continue
        seen[case_id] = (expected, observed)

    missing = sorted(REQUIRED - set(seen), key=int)
    failures = [case for case, (expected, observed) in seen.items() if expected != observed]
    print(f"cases_observed={len(seen)}/12")
    print(f"missing_cases={','.join(missing) if missing else 'none'}")
    print(f"outcome_mismatches={','.join(sorted(failures, key=int)) if failures else 'none'}")
    if seen:
        successes = sum(1 for expected, observed in seen.values() if expected == observed)
        print(f"descriptive_case_match={successes}/{len(seen)}")
    return 1 if missing or failures or len(seen) != 12 else 0


if __name__ == "__main__":
    if len(sys.argv) != 2:
        raise SystemExit("usage: acceptance_check.py outcomes.csv")
    raise SystemExit(main(sys.argv[1]))

The expected result is not always observed_useful=1. Some cases intentionally expect the agent to abstain or give a safe outage message. That is why the CSV uses an expected value for every scenario rather than assuming the normal path is always correct. A test runner can pass the technical behavior gate while still failing a human quality review; retain both decisions in the evidence packet.

Set the safe behavior before calling it failover

“Failover” is not a single behavior. It can mean switching from one carrier to another, using a different region, changing from a live answer to a voicemail, routing to a human, saving a callback request, or simply telling the caller that the service is unavailable. These options protect different outcomes. The buyer should decide which one preserves the purpose of the call and which ones are acceptable only as a temporary fallback.

Write one fallback rule for each dependency. If the primary telephony route fails, can the number be redirected by the carrier without the same control plane? If recognition is down, can the caller reach a human without asking them to repeat sensitive details into an unapproved channel? If the model is unavailable, is a fixed, reviewed message safe for the relevant call class? If a data source is stale, which answers must be withheld? If the human queue has no staff after hours, what is the honest alternative and who owns it next morning?

A fallback should have an audible and operationally truthful outcome. Do not have the agent say “I am connecting you now” until a transfer is actually established. Do not label a callback “scheduled” unless a task was persisted, has a responsible queue, has a due-time rule and can be recovered after a restart. Do not imply that a caller is speaking with an employee when they are still in an automated path. A truthful alternative is often better than a fluent false promise.

CISA’s public-safety communications resilience guide warns that a single service line from a single provider can create a single point of failure, and that nominally separate carriers can still share underlying facilities. Its context is public-safety network planning, not commercial AI call centers; the principle to borrow is dependency mapping. Ask vendors whether the supposed alternate path has independent carrier facilities, credentials, regions, power and control-plane dependencies. “Two providers” is not proof of two independent paths.

Google Cloud’s documentation makes a similar point from a product-specific angle: failover ownership and timing depend on whether telephony is managed by the platform or brought by the customer, and the settings between instances must stay aligned. Treat any vendor’s design as an example to inspect, not as evidence that your deployment has it. Test the actual number and account that customers will use.

Human transfer is a service dependency, not a prompt line

A transfer instruction in a prompt does not make a human available. Verify the destination, its operating schedule, queue membership, capacity, holiday rules, caller-ID preservation and the behavior when all agents are busy. A transfer can be technically accepted but still fail the caller if the queue is unstaffed, the audio is silent, the destination is wrong or the receiving worker lacks context.

In a 3CX community thread, a user described calls being dropped when the real-time AI connection stopped; a support representative replied that the observed case lacked a defined fallback route and described routing to an extension, queue or digital receptionist as a possible safe behavior. Another 3CX support thread reports a long transfer delay and conflicting observations during testing. These are individual support discussions, not frequency estimates and not vendor-wide defect rates. They are useful because they expose concrete acceptance questions: what happens on model disconnection, and how do you measure transfer completion from the caller’s side?

Instrument the transfer as a sequence: intent to transfer, destination chosen, transfer command accepted, remote side answered, caller audio bridged, context delivered and call completed. Report each state distinctly. If the PBX only exposes the first two events, do not claim that the caller reached a person. Ask the receiving team to confirm that context arrived in a usable form, and test a destination that does not answer.

Set an explicit timeout for each stage. A short timeout that drops a call is not a safe policy; an unlimited timeout can strand a caller in silence. The acceptable interval depends on the business, the queue and the human alternative. Choose a threshold with service owners, speak an update before the caller is left waiting, and let the caller choose from approved alternatives when possible. The threshold is a local service decision, not a universal number from this article.

Define what “after hours” means at the destination. If the agent answers at 02:00 but the only human queue opens at 08:00, the service may still be useful if it can collect a request, state the next response window and assign the task. It is not a 24/7 human service. Label the distinction: always-answering, always-self-service, or always-human-supported are different promises.

Monitor from outside the agent, not only inside its dashboard

Use a synthetic call from a controlled number over the public entry route. It should verify that the expected greeting is heard, a known test phrase is understood, the approved answer is delivered or a transfer is completed, and the call ends in the expected state. Run the probe from more than one network path where appropriate, but avoid high-frequency calls that create cost, nuisance, or misleading artificial demand. Every probe needs a test label so it cannot be counted as a real customer interaction.

Monitor the component signals too: SIP response codes, call setup time, dropped sessions, packet loss or audio gaps where available, ASR and TTS errors, model response timeouts, retrieval freshness, tool error codes, transfer events, queue status and unresolved callback age. Component telemetry explains a failure; the synthetic call tests whether the combined service still works. Neither one replaces the other.

Google Cloud recommends monitoring status pages and using regional alerts for call failures or increased latency in its own CCAI environment. A public status page is an input, not a user-impact measurement. A green page can lag an incident, cover a different region, or exclude your specific integration. The system owner should also run its own end-to-end probe and compare the vendor status timeline with local call evidence.

Alert on consequences and action. A notification that says “voice model timeout above threshold” is useful only if someone knows whether the system has switched to a safe response, who is on call, and how to suspend a broken function. Google SRE guidance argues that monitoring should distinguish signals requiring immediate human action from tickets that can wait and informational logs. Apply that discipline to telephony: actionable alerts need an owner, a response playbook and a validated fallback.

Keep timing coherent. Use a stable correlation ID across carrier event, telephony session, audio stream, model invocation, business tool and transfer. Store UTC timestamps plus the displayed local time zone for support staff. Without a shared identifier, one call may appear as several disconnected events and an incident reviewer may be unable to tell whether the customer got the answer, was transferred or called back.

Agree on a service-level objective that can be audited

An SLO is a target measured by a service-level indicator. Google SRE describes availability in terms of a fraction of useful operations and advises choosing indicators based on what users care about. For a voice service, write down the entry boundary, in-scope call types, allowed outcome, measurement window, treatment of maintenance, treatment of tests, and how retries are counted. Put the definition beside the numerical target in procurement documents and dashboards.

The target itself is a business decision. A public-information line, an emergency route, an appointment assistant and a sales qualification bot do not have the same failure cost. Choose thresholds by considering caller harm, operating hours, human coverage, manual capacity, legal or contractual duties and the cost of building real redundancy. A higher “nines” target may require geographically separate infrastructure, more than one provider, tested staffing and an incident team. It may not be worth the cost for a low-risk, non-critical task.

Do not confuse SLO with SLA. An SLO can be an internal objective. An SLA is a contractual commitment that should define measurement, exclusions, remedies, reporting and who can challenge a result. If a vendor advertises an uptime SLA, ask whether it measures the API, media service, telephony platform, public number, agent response or a caller’s useful outcome. Ask how credits apply when the model is technically up but callers cannot complete a task.

Use error budgets as a release-management tool, not as permission to ignore incidents. A team can define a maximum tolerated share of failed eligible calls over a period, then pause expansion when the budget is consumed. The budget must count the failures the service promise includes. If carrier failures are omitted from the vendor’s metric but remain the customer’s problem, track a separate end-to-end indicator and show both measures.

A good contract also names failover responsibilities. List the party that detects the issue, the party authorized to redirect the number, the time expectation, required customer cooperation, data retained during an outage, and what the caller hears. Specify whether the provider will run a failover exercise with the customer. Define whether the customer can export call records and configuration during a provider incident. The goal is not to force every supplier into a multi-carrier design; it is to know exactly what service is and is not promised.

Keep recovery goals separate from availability percentages

Availability answers how often a defined operation meets its rule over a window. Recovery time objective (RTO) says how quickly a service should be restored after disruption. Recovery point objective (RPO) says how much data or task state may be lost. They solve different decisions. A call service can have a reasonable aggregate availability figure and still lose the caller’s pending callback tasks during a regional restart. Conversely, it can restore service quickly while leaving callers without a verified outcome.

For voice agents, define state explicitly. A caller may be connected, awaiting a tool, waiting for transfer, consented to callback, callback assigned, callback attempted or resolved. Store enough state to recover without creating a duplicate booking or pretending that an unconfirmed action succeeded. If a call ends during a write operation, query the authoritative business system before retrying. The agent’s conversation memory is not the business ledger.

Test a restore while a call is in flight, not only an idle service. Cases 11 and 12 in the protocol cover region loss and recovery after a dependency returns. Confirm how active callers are treated, whether the system can continue or must start a new call, what happens to a pending task, and how duplicate actions are prevented. The operator should be able to find the test event in logs after restoring production state.

Recovery objectives must be realistic. If a human fallback is available only by manually editing carrier settings, that action may take longer than the vendor’s API recovery target. If customer staff are not on call overnight, a “restore within minutes” promise may not mean a person can answer the transferred call. Write separate time budgets for technical restoration and customer outcome restoration, and report whichever is relevant to the caller.

Evidence, measurement date and limitations

This guide’s original asset is a designed 12-case acceptance suite and a small CSV checker, prepared on 7 November 2026. The sample size is twelve scenarios by design; it is not a random sample of callers and does not estimate production availability. The method is to map a defined call path, inject one controlled condition per case, compare the observed outcome with an expected safe result, and retain route, timestamp, status and reviewer evidence. Excluded are real customer calls, live emergency traffic, vendor-wide uptime measurements, financial savings and any claim that a system was tested here.

The editorial gap came from three inputs. First, Search Console data for the selected primary site over 29 October–5 November 2026 included the query “comment mettre en place un agent vocal 24h sur 24 ?” at average position 8.0 with two impressions and zero clicks. This is a small internal search observation, not proof of market demand or a ranking opportunity. Second, official contact-center documentation describes multi-layer telephony dependencies and failover choices, but does not define one universal caller-outcome test for every vendor configuration. Third, 3CX community discussions raised concrete questions about the missing AI fallback path and delayed transfers; they are qualitative examples, not representative samples.

A relevant Exotel webinar page describes a session about production voice AI, SIP versus WebRTC, latency and failover. The page was available as an event description, but its recording was behind a “Watch now” gate and no transcript was available in the inspected result. It is therefore treated as an editorial lead about questions practitioners discuss, not as evidence for a technical claim or a measured result. A Weights & Biases event page similarly lists latency spikes, audio degradation and agent inconsistency, but the recording itself was not evaluated here.

All examples are product-neutral. Google Cloud’s design guidance applies to its CCAI service; OpenAI’s SIP instructions apply to its documented interface; CISA’s communications resilience guide was written for public-safety communications; EY’s agent governance discussion is a consulting perspective; and individual 3CX forum posts describe particular installations and software versions. Transfer those lessons to another environment only after checking your architecture, contract, regional obligations and actual settings.

Proof pack

Claim used in this article	Source and type	What it supports	Limit of the evidence
A phone service can depend on external CPaaS, network, SIP and regional configuration	Google Cloud CCAI high-availability guide — vendor technical documentation	Concrete product-specific layers and failover responsibilities	Does not prove that another vendor has the same design or that your route is redundant
Availability should be measured in terms of user-relevant operations and a defined window	Google SRE availability table — engineering reference	Time-window and aggregate-operation distinctions	Not an AI phone-agent target or a telecom service commitment
A single carrier path can create a communications single point of failure; alternate providers may share underlying facilities	CISA Public Safety Communications Network Resiliency Self-Assessment Guidebook — government guide	Dependency mapping and physical-path diversity as resilience questions	Written for public-safety networks; commercial implementation and local regulation differ
AI-agent use needs explicit accountability, oversight and scalable controls	EY AI governance report — consulting analysis	Governance context for ownership and monitoring	Consulting analysis is not an independent availability benchmark
A phone route may fail when an AI service disconnects, and transfer delay is a practical issue	3CX fallback discussion and transfer-delay discussion — user support forum	Real questions that an acceptance test should cover	Anecdotal, product/version-specific; no incidence rate can be inferred
Production voice-AI teams discuss telephony, latency and failover	Exotel webinar listing — vendor event/video description	Topic scan only	Recording was gated and transcript unavailable; not used as proof
The selected group page says to check telephony and schedule unavailability	Vocalis garage reception guide — primary context page	Context for this article’s reader task	A product/service page is not an external validation of availability

The sources are intentionally not averaged into a market-wide claim. An SRE definition, a public-safety resilience guide, a vendor architecture, a consultancy’s AI-governance analysis and user forum posts measure or describe different things. They support the design questions in this article, not a statement that voice agents generally achieve a particular uptime or that one fallback is always best.

Choose the test depth by consequence

Service consequence	Minimum evidence before launch	Escalation rule
Low-risk public information	Run all normal-path and failure cases that can change the answer; verify current source version and a truthful outage message	Pause that answer class if data freshness cannot be established
Booking or customer record update	Add duplicate prevention, authoritative confirmation, permission checks, recovery after interrupted writes and owner visibility	Block writes if the system cannot prove whether the action committed
Human escalation	Test transfer acceptance, answer, bridge audio, after-hours destination and no-staff queue	Route to a truthful alternative when a person is not actually reachable
Safety, emergency or regulated workflow	Use qualified service owners, legal/regulatory review, stronger separation, external test witness and documented human response	Do not represent an AI route as an emergency service unless that exact role is authorized and proven

Do not automatically choose the highest-redundancy design. A separate carrier, region and provider can add configuration drift, operational complexity, data-transfer issues and cost. A small organization may be safer with a simple agent that does one low-risk task and offers a clear human or callback fallback than with a complex active-active design that nobody can operate during an outage. The right architecture follows the consequence and recovery capability, not a marketing label.

Failure modes that invalidate a “24/7” claim

The dashboard only measures the model. Calls rejected before a model request disappear from its denominator. Add a probe at the public number and reconcile carrier, platform and model logs.

A fallback exists only in a diagram. No one has tested the carrier switch, queue route, alternate account or fail-safe prompt. Schedule an authorized exercise, record the owner and retain a caller-side recording.

Two routes share the same failure. Separate trunks may share a carrier, data center, identity provider, internet access, region or configuration account. Ask for dependency evidence and test the exact alternate path.

Transfer initiation is counted as transfer success. The system requested a transfer but no one answered or audio never bridged. Measure answer and caller-audible completion separately.

The after-hours queue is empty. The agent answers overnight but routes into an unstaffed queue and says “please hold.” Define a callback owner, a next-service window and a way to reclaim an abandoned task.

An outage message makes a false promise. “I have booked that” or “a colleague will call shortly” is spoken before the action or assignment exists. Verify the system-of-record result before confirming it to the caller.

Retries create duplicate work. A timeout occurs after the booking system accepted a request but before the agent saw its response. Use idempotency keys and reconcile the business record before retrying.

The fallback is technically live but unsafe. A static answer can become stale, an alternate model can lack the approved knowledge, or a voicemail may collect data without the intended privacy controls. Define permitted fallback content and data handling first.

Synthetic checks are confused with customer calls. Test traffic inflates demand, contaminates outcome metrics or triggers real messages. Use isolated test numbers and records, explicit labels and a separate dashboard dimension.

A successful percentage hides a critical class. Most callers ask routine questions, while a small safety or complaint class fails. Report results by call class and retain severity-specific release gates.

Configuration drifts between primary and secondary systems. Different prompts, queues, holidays or knowledge versions make failover behave differently. Compare configuration fingerprints and rerun the acceptance set after material changes.

The monitoring system depends on the failed service. An alert routed through the same identity, network or voice platform may never arrive. Maintain an out-of-band incident channel and a named human owner.

A 30-minute procurement review

Ask the vendor to draw the real path from the public number to the successful business outcome. Mark the carrier, telephony provider, AI region, model, retrieval sources, business systems, transfer destinations, status feed, human staffing window and the party that can reroute each component. If an answer is “the platform handles it,” ask for the failure case, evidence and customer responsibility in writing.

Then take one customer journey and test it with the intended caller language. Ask for a normal answer, an out-of-scope request, an interrupted call, a tool timeout, a failed human transfer and a retry after service recovery. A demo on a vendor’s ideal network is not enough. The organization should test its actual number, business-hour rules and receiving queue in a controlled environment.

Request a sample incident timeline. It should connect the customer’s call ID with telephony events, model events and any business action. Check that the record distinguishes attempted action from confirmed action. Confirm how the vendor reports incidents, how quickly customers are notified, what evidence can be exported, and whether an independent test is permitted.

Finally, decide what a caller should hear when the system cannot finish. Write the sentence, identify the fallback route, name the owner and prove the resulting task can be recovered. If the organization cannot yet support a reliable human route, the correct promise may be limited: an automated line that accepts a request and states a next step, rather than a service that resolves every call at any hour.

Release checklist

• [ ] The promise distinguishes call answering, self-service completion, human support and callback.
• [ ] The start and end of the availability measurement are written down.
• [ ] In-scope attempts include failures before the model starts.
• [ ] Test traffic, maintenance, retries and exclusions are identified in reports.
• [ ] Each dependency has an owner, a failure signal and an approved fallback.
• [ ] Carrier and regional alternatives are tested for shared dependencies.
• [ ] An unavailable model cannot produce a fabricated success confirmation.
• [ ] A transfer is counted as successful only after the defined human destination is reached.
• [ ] After-hours queue and callback behavior have a named operational owner.
• [ ] The 12 synthetic cases are run against the agreed configuration and evidence is retained.
• [ ] A “not run” case remains a gap, not a pass.
• [ ] Recovery after an interrupted call does not lose or duplicate business actions.
• [ ] Monitoring works outside the voice platform and has an actionable on-call path.
• [ ] The SLA names its metric, window, exclusions, remedies and measurement source.
• [ ] Any public “24/7” wording is no stronger than the tested service outcome.

The decision is straightforward: buy “24/7” only after the phrase has been translated into an observable caller outcome and every failed dependency has a safe, owned next step. A twelve-case test cannot predict all outages, but it can expose whether the service promise has a real route behind it.

Comments

[Alex Shev]

The caller-visible definition of success is the part teams most often skip. I would include a test that validates the handoff owner actually receives enough context to act: caller identity where permitted, reason, urgency, transcript summary, and a deadline. A completed transfer to an unaware queue is technically connected but operationally still a failure.