AI Voice Agent Handoff: A 15-Scenario Acceptance Test

An AI phone agent is not ready for a live customer line merely because it sounds natural, answers quickly, or can invoke a transfer tool. The go-live decision should turn on a more concrete question: when the system says it is handing a call to a person, did the person actually answer, receive the minimum useful context, and continue without forcing the caller to start over? If the destination is unavailable, did the caller get a real fallback instead of silence, a dead end, or a false promise?

For a small team, the practical recommendation is to run a short acceptance test on the exact phone number, carrier path, queue, CRM and agent configuration intended for production. Use the 15-case matrix in this guide, record each attempt as a state transition, and reject a launch if the system cannot distinguish “transfer requested” from “human answered.” Do not use a vendor’s containment rate, a polished demo, or an aggregate voice-quality score as a substitute for that proof.

The reusable asset below is a designed test protocol, not a report of measured vendor performance. It gives a team a common way to test ordinary routing, interruptions, context handoff, unavailable staff, privacy boundaries and recovery. A short, well-instrumented pilot can tell you whether your specific workflow is safe enough to expand; it cannot establish that voice agents generally improve customer service.

What the current evidence says—and does not say

The search question behind this article is practical: “How do I choose or validate an AI voice agent that can transfer a customer call safely?” A query-page extract from the site’s own Google Search Console for 13–20 October 2026 showed 9 impressions for “meilleur agent vocal ia” at an average position of 9.6 on the source page. This is a first-party measurement for one page and one seven-day window, not market demand, a stable ranking, or evidence that this article will rank. The extract uses Search Console’s available rows; anonymised queries and low-volume variation may be missing.

The published comparison page for AI voice-agent solutions lists common jobs such as lead qualification, appointment booking and first-line service, then presents customer-result and latency figures. The page does not state the cohort, comparison group or measurement method alongside those claims, so they are treated here as the publisher’s claims—not independently verified evidence or a basis for choosing a supplier. The buyer question left open by the feature comparison is more useful: how can a team prove the transfer worked for its own callers?

Public benchmarks show why that distinction matters. Cekura’s published comparison says it called nine live production agents, used ten conditional-action scenarios and repeated them three times—270 calls in that benchmark—and reports voice, turn-taking, interruption, latency and reliability measures. That is a useful structured snapshot of the sampled agents and its chosen scenarios, not a universal ranking or a direct estimate of what a particular small business will experience. Its table shows different leaders on different measures; for example, the fastest median turn and the fastest stop after interruption are not the same result. A single composite score can hide that operational difference. Read Cekura’s benchmark and methodology.

The VAmoS Bench preprint makes a complementary point: speech quality and latency are not the same as completing a phone task correctly. It frames containment as calls resolved without a human, while noting that an appropriate result can also be refusal or redirection. Its first version focuses on financial-service simulations, so it is a research proposal for evaluating verified outcomes, not a ready-made score for every service desk. Read the VAmoS Bench paper.

Consulting firms also publish projections about their own voice-agent offerings. PwC’s brief on a voice agent developed with OpenAI describes a possible reduction in human-agent escalation as an early projection and includes an expected outcome for a large network-and-telecom client. That is relevant as an example of how an integrator frames business impact, but the brief is not an independent head-to-head handoff benchmark and does not make those outcomes transferable to a small team. Use it to sharpen the procurement question—what exact denominator and event prove escalation was avoided?—not as a forecast. Read PwC’s description of its real-time voice-agent offering.

The AFRC–IPAG study of AI in customer relations gives another useful, but differently scoped, view. The report describes 14 semi-structured interviews with customer-relations directors at large French companies selected by the research team. It distinguishes applications that autonomously execute a task from tools that resolve simple requests and pass complex ones to a human; it describes immediate transfer after a customer asks for an adviser or after two failed attempts in one example. This qualitative sample helps explain how practitioners frame collaboration, but it is not a representative survey of small businesses or a controlled test of vendor success rates. Read the AFRC–IPAG study.

Microsoft’s current voice-agent guidance recommends explicitly defining which intents require a person, what context moves with the call, what happens when no one is available, and whether callers can request a human at any time. It also warns against claiming that a transfer succeeded before the downstream system confirms it. That is product guidance, not a regulatory standard, but it translates directly into acceptance checks. See Microsoft’s voice-agent handoff and interruption guidance.

Real support discussions add a failure mode that feature pages often skip: the destination may answer but the post-transfer audio can still be unusable. In one July 2026 support thread, a customer reported degraded audio after a cold transfer; the platform response investigated the specific call path and differentiated transfer modes. One thread cannot tell us how often this happens, and its diagnosis may be specific to that carrier and configuration. It is still a good reason to test the receiving leg, not merely the caller’s experience before transfer. Read the de-identified technical discussion in Retell’s community.

A recorded product demonstration can help a buyer see the intended experience. Assistable’s June 2026 transfer demo shows a caller asking for a named person, an announcement, hold music and an introduction when the person joins. The page explicitly says the receiving person’s private briefing is not separately audible. Treat it as a demonstration of a configured path—not proof of what happens when no one answers, the queue is full, the call drops, or context fails. Watch the transfer demonstration and its stated limits.

The decision rule: measure completed handoffs, not transfer attempts

Count a handoff as successful only after the destination system confirms that a human answered and the call remained connected long enough for a useful continuation. A “transfer tool invoked” event is an attempt. A SIP redirect or bridge request is a routing action. A ringing destination is not an answer. A successful handoff needs a downstream confirmation event or an auditable call-state signal, plus evidence that the human received the context your workflow promised.

Keep at least four outcomes separate:

This prevents a dashboard from improving its “containment” score by counting a caller who gave up, was disconnected, or was promised a callback that never entered a tracked queue. If a caller asks for a person, the agent may still collect one necessary detail before routing, but the request must not become a loop that tries to talk the caller out of help.

Use a denominator that matches the decision. For a transfer metric, report both confirmed handoffs / transfer requests and confirmed handoffs / eligible calls. Also report safe fallback, unknown state and caller repetition separately. Do not merge them into one percent. If 20 calls were eligible and 8 requested a person, then 6 confirmed handoffs means 75% of transfer requests and 30% of eligible calls. Those are two different ratios; neither says whether the six callers got a useful handoff unless context and continuation were checked. The numbers in this example are arithmetic only, not observed data.

The important distinction is between a system outcome and an interface event. “The transfer function returned success” can mean only that a request was accepted by one component. “The queue accepted the call” can still precede a timeout. “A human answered” can still leave the caller repeating their name and problem because no summary crossed the boundary. The evidence chain should therefore use separate timestamps or events for request, destination ringing, answer, bridge, context delivery, first human response and end reason. If the platform does not expose all these events, record that observability gap as a procurement risk rather than trying to infer success from a friendly-sounding sentence.

The 15-scenario acceptance matrix

This matrix is an original reusable asset prepared on 23 October 2026. Its sample size is 15 scenario types, written as controlled acceptance cases; it is not 15 real customers, a benchmark dataset, or a measured result. It excludes provider-to-provider performance comparisons, statistical confidence intervals, accents beyond the team’s chosen test set, and any claim about customer satisfaction. A team can run each case twice on a staging number, then repeat with a small, consented pilot. Keep the configuration, call script and expected state unchanged between runs.

The table is deliberately not a list of fifteen prompts to read mechanically. Each row combines a caller situation, a required state transition and evidence. A test is useful only if the expected behavior is written before calling the system. Otherwise, a reviewer can unconsciously grade a plausible-sounding answer as correct even when no route was confirmed.

For every call, preserve the minimum fields needed to replay the decision: anonymized test ID, configuration version, start time, scenario ID, agent intent, transfer request time, destination and queue status, answer/bridge confirmation, context-delivery status, fallback record ID, end reason, and evaluator verdict. Do not paste an entire customer transcript into an issue tracker to make testing convenient. Use synthetic identities and fabricated account details in pre-production. If real calls are needed for evaluation, decide the purpose, lawful basis, access, retention and notice with the responsible privacy owner before collecting them.

A reproducible runbook

1. Freeze the test boundary

Write down the exact configuration under test: agent prompt or flow version, speech model, telephony route, transfer mode, queue, business hours, CRM connection, fallback behavior and recording setting. A test against a demo number is not evidence for a production number if the carrier, routing or downstream queue differs. Hash or version the configuration export where possible so a later pass can be compared without relying on memory.

Define the supported intents before testing. For each, specify whether the agent may answer, may perform a reversible action, must request confirmation, or must transfer. Make “human now” an unconditional route where operationally possible. Sensitive issues should have a short, explicit policy rather than relying on the model to infer which topics are sensitive from vague language.

2. Prepare controlled callers and expected states

Use one caller script per scenario. Keep the spoken facts and timing repeatable, including an interruption at a fixed point for H05 and a correction for H04. Test one clear French voice and the languages and accents your actual line is expected to serve. The aim is not to simulate every human voice; it is to detect whether the flow fails when speech recognition is imperfect or a turn ends earlier than the model planned.

For each scenario, agree on an expected final state. Example: H08 should end as transfer_requested -> destination_ringing -> no_answer -> callback_offer -> callback_created if the caller accepts. If the caller declines, the state should instead end with an accurately recorded decline and another available route. Neither final branch is a confirmed handoff. Store the expected sequence beside the observed sequence so reviewers compare events, not vibes.

3. Run the calls and inspect both ends

Run the caller script on the actual staging route. For transfers, inspect both the caller-side audio and the receiving person’s side. The caller may hear hold music while the agent says it is transferring; that does not show what the colleague heard, whether the original caller ID survived, whether audio was clear after bridging, or whether context was visible. The Assistable demo illustrates the caller-facing steps, while its own page notes that the receiving person’s private briefing is not audible in that recording. Your acceptance test must inspect that missing side explicitly.

Use a clock source consistent across the voice platform, carrier and CRM logs. If clocks cannot be aligned, avoid sub-second latency claims; compare event order and record the uncertainty. A small team can manually mark a recording or event log for each test. Do not report an average from a handful of calls as if it predicts production reliability.

4. Grade each state, not just the final result

Assign a pass/fail to transfer correctness, context sufficiency, caller repetition, audio intelligibility, fallback correctness and side-effect control. Add an unknown verdict if a system did not expose enough evidence. Unknown is not pass. The human reviewer should be able to answer: who asked for the transfer; what the agent told them; what event proves a destination answered; what context arrived; and what happened if the route failed?

Avoid turning the scoring form into a fictional universal standard. The thresholds should be chosen by the team and the customer risk. A service that only books low-stakes appointments may tolerate a different fallback delay than an urgent repair line. The initial gate is categorical: zero fabricated transfer confirmations, zero untracked customer promises, and no high-risk scenario handled outside its approved path. For quality measures that can tolerate variation, publish the observed numerator and denominator and the date/configuration instead of calling a single pass percentage “industry standard.”

5. Review the exceptions and retest changes

For each failure, label the layer that caused it: recognition, model decision, tool call, queue, carrier, media bridge, context payload, CRM write, or evaluator visibility. Fix one layer at a time and rerun the same cases. If a vendor changes a transfer implementation or a telephony route changes, rerun the relevant cases; yesterday’s clean call does not verify today’s new path.

Do not expand from a small set of scripted tests directly to all callers. First shadow or stage the workflow, then use a limited pilot with a human fallback and a named owner. Review failed, unknown, escalated and abandoned paths—not just calls that completed. Sample size should grow with the consequence and variability of the task. Fifteen scenario types are a practical acceptance checklist, not a statistical guarantee.

State machine: the event that counts as success

stateDiagram-v2
    [*] --> ActiveCall
    ActiveCall --> AgentResolved: verified allowed action
    ActiveCall --> TransferRequested: person needed or requested
    TransferRequested --> DestinationRinging: downstream accepts route
    DestinationRinging --> HumanAnswered: answer event confirmed
    HumanAnswered --> ContextChecked: summary delivered and reviewed
    ContextChecked --> HandoffComplete: call connected and context adequate
    DestinationRinging --> NoAnswer: timeout or unavailable
    TransferRequested --> TransferFailed: error or disconnect
    NoAnswer --> FallbackOffered: accurate status told to caller
    FallbackOffered --> CallbackCreated: caller accepts, task ID returned
    FallbackOffered --> AlternateRoute: caller selects another option
    CallbackCreated --> SafeFallback
    AlternateRoute --> SafeFallback
    TransferFailed --> SafeFallback: recovery path actually created
    TransferFailed --> Unknown: no reliable downstream event
    AgentResolved --> [*]
    HandoffComplete --> [*]
    SafeFallback --> [*]
    Unknown --> [*]

The diagram makes one operational rule visible: TransferRequested is not HandoffComplete. A successful state transition needs evidence from the receiving system, then a context check. If the vendor exposes only a single “transfer success” Boolean, ask what event it represents, which component emits it, and whether a dropped post-bridge leg can still leave it true.

A small audit tool for event logs

The following Python checker consumes a JSON Lines export from a staging run. It does not grade speech quality or determine legal compliance. It flags attempts without an answer signal, answer signals without context confirmation, unknown results counted as completed, and fallback promises without an actual task ID. Adapt the field names to the logs your vendor actually exposes; if a required field is unavailable, record an observability gap instead of manufacturing a value.

Example input shape (use synthetic values in test):

{"case_id":"H08","transfer_requested":true,"destination_answered":false,"context_delivered":false,"outcome":"callback_created","callback_id":"TEST-001","transfer_counted_success":false}

Save the following as handoff_audit.py, then run python handoff_audit.py calls.jsonl:

import json
import sys
from collections import Counter

REQUIRED = {"case_id", "transfer_requested", "destination_answered",
            "context_delivered", "outcome", "transfer_counted_success"}

def audit(path):
    rows = []
    with open(path, encoding="utf-8") as source:
        for line_no, line in enumerate(source, 1):
            if not line.strip():
                continue
            row = json.loads(line)
            missing = REQUIRED - row.keys()
            if missing:
                raise ValueError(f"line {line_no}: missing {sorted(missing)}")
            rows.append(row)

    findings = []
    outcomes = Counter(row["outcome"] for row in rows)
    for i, row in enumerate(rows, 1):
        case = row["case_id"]
        if row["transfer_counted_success"]:
            if not row["transfer_requested"]:
                findings.append((case, "success without transfer request"))
            if not row["destination_answered"]:
                findings.append((case, "success without downstream answer"))
            if not row["context_delivered"]:
                findings.append((case, "success without context confirmation"))
        if row["outcome"] == "callback_created" and not row.get("callback_id"):
            findings.append((case, "callback promised/labelled created without task id"))
        if row["outcome"] in {"unknown", "dropped", "no_answer"} and row["transfer_counted_success"]:
            findings.append((case, "failed or unknown outcome counted as success"))

    print(f"rows={len(rows)} outcomes={dict(sorted(outcomes.items()))}")
    for case, issue in findings:
        print(f"FAIL {case}: {issue}")
    if not rows:
        print("UNKNOWN: no rows; no rate can be calculated")
    return 1 if findings else 0

if __name__ == "__main__":
    if len(sys.argv) != 2:
        raise SystemExit("usage: python handoff_audit.py calls.jsonl")
    raise SystemExit(audit(sys.argv[1]))

This is intentionally a consistency checker, not a “voice AI score.” It does not prove the answer was useful, the transfer destination was appropriate, or the caller understood the notice. It also assumes that destination_answered and context_delivered are backed by trustworthy platform or human-review evidence. If they are inferred from the agent transcript, the check can pass a story rather than the call.

Privacy, recording and caller notice

Treat call audio, transcripts, phone numbers, names, account references and summaries as personal data where they identify a person. Before collecting production calls for quality review, write down the purpose, legal basis, access roles, retention, deletion method, vendor processors, transfer locations and the information shown or spoken to callers. Keep test recordings separate from training data and avoid retaining full audio when event-level evidence answers the operational question.

The European Commission describes the AI Act as a risk-based framework. That does not make one generic “AI notice” or this article a legal assessment; applicable duties depend on system purpose, location, role and context. As an operational default, tell callers clearly that they are speaking with an automated system, provide a simple route to a person, and make the choices understandable. Have privacy or legal counsel verify the exact notice and any sector-specific requirements before launch. See the Commission’s AI Act overview.

The CNIL’s 2026 retention reference says recordings of workplace calls used for training, service-quality improvement or evaluation should be kept for a maximum of six months in active use, and that only analysis documents may remain in intermediate storage for up to one year. The reference labels the linked workplace-call guidance a recommendation and discusses employee-related processing. Do not automatically apply that duration to every customer recording, transaction record or jurisdiction. Use it as a strong reason to define a purpose-specific schedule and to seek advice for the exact processing. Read the CNIL retention reference.

Data minimisation also improves the handoff itself. A human usually needs a short summary, not a raw transcript dump: caller’s stated intent, confirmed identifiers required for the task, what the agent already tried, what remains unresolved, urgency label and the source/time of each fact. Clearly distinguish caller-confirmed information from a model inference. A transcript can be incomplete after an interruption; Microsoft specifically notes that the turn context may be truncated to what was actually heard. A transfer summary must not treat a planned utterance as if it was received by the caller.

Failure modes that make a demo misleading

The system says “I’m transferring you” but the route never answers

This is the simplest trust break. Require a downstream answer or bridge event before confirming that a colleague has joined. If the route times out, have the agent say so plainly and offer only real alternatives. A callback is real only when a task is created, has an owner or queue, and returns an ID the workflow can track.

The human answers but the caller repeats the whole story

An audio connection is not continuity. Test whether the human receives a concise, accurate summary in the system they actually use. Do not define success as “a screen popped up.” Ask the recipient to read the summary and state the next action. If crucial details are missing, the agent should ask one focused clarification before transfer or mark the field unknown.

The destination audio is worse than the agent audio

Voice quality can change across the transfer leg, codec, carrier or bridge. The Retell support thread is one concrete report, not a frequency estimate; it illustrates why the receiving-side path deserves its own check. Listen to both sides on the actual route, verify caller ID and duplex audio, and test interruption after connection. An excellent voice before transfer does not prove clear speech afterwards.

The agent interprets silence as consent

Silence, a partial answer, background speech or a caller being interrupted must not authorize a callback, recording, booking or data change. Record explicit choices where needed. If recognition confidence or caller intent is ambiguous, ask a narrow clarification or route to a person.

The tool logs an intent, not an outcome

A CRM event such as handoff_requested can be mistaken for human_reached. Use distinct event names and idempotency keys. Retried webhooks should not create duplicate callbacks or tickets. Keep the system of record as the source of truth for an appointment, callback or case, and reconcile event IDs after test calls.

The score rewards calls that should have been escalated

Containment is useful only when the caller’s task was actually resolved in scope. A call that should be escalated is not a failure merely because the model declined to answer; a safe refusal or referral may be correct. VAmoS Bench explicitly treats refusal or redirect as a possible correct call outcome. Design the scorecard around policy-compliant resolution, not “keep every caller away from a person.”

The benchmark hides the conditions that matter locally

Published benchmarks use selected platforms, scripts, access routes, languages and scoring rules. A 270-call comparison can be more informative than a single demo and still may not represent your carrier, accents, customer mix, after-hours queue, sector or CRM. Read the methodology. Re-test the shortlist with your scripts and route; don’t transpose a leaderboard rank into a production guarantee.

A practical decision matrix for buyers

The right buying question is not “Does it transfer?” but “Which event confirms that it transferred, who owns the failure state, what context reaches the person, and how can we audit a miss?” Request a redacted event log schema, not just a list of integrations. Ask whether the system supports a warm transfer, cold transfer or platform-specific bridge; what each mode does to the media path; and whether the receiving person gets a separate briefing. The appropriate mode depends on the phone system and workflow, so test on the intended setup rather than assume one mode is universally better.

A seven-day pilot that can stop safely

Day 1: choose one low-risk intent, one phone route and one human owner. Write the allowed actions, prohibited claims and escalation triggers. Day 2: implement the 15 cases with synthetic details and define event names. Day 3: run the scripted cases twice on staging and inspect caller and receiving sides. Day 4: correct the first layer of failure and rerun the exact cases. Day 5: if every safety gate passes, shadow a small, consented production slice while a human remains available. Day 6: review all unknown, dropped, escalated and fallback cases; sample successful cases as well. Day 7: decide whether to keep, narrow, extend or stop the pilot. This is a suggested operational cadence, not a validated statistical design.

The pilot should have a named stop condition. Pause the agent if it falsely confirms a transfer, creates an untracked commitment, routes a sensitive case outside policy, loses the caller without an auditable end state, or exposes a transcript to an unauthorised person. Keep an operator able to disable the agent and restore the prior phone route. A fallback that exists only in a prompt is not a rollback plan.

Record decision evidence with the release: configuration version; test date; number of scripted attempts; counts for each final state; unknown count; issues fixed; unresolved risks; owner approval; and expiry date for the review. For a real pilot, list the period, eligible call definition, exclusions, whether repeated callers count once or more than once, and whether any calls were removed. Do not compare a week of low-volume calls to a vendor benchmark unless definitions and populations match.

What to put in the procurement request

Ask each vendor to demonstrate the same scenarios rather than choosing its preferred happy path. Request the exact transfer event sequence, queue integration behavior, no-answer policy, callback mechanism, caller-ID behavior, context payload, post-transfer audio path, retry and idempotency behavior, recording controls, exportable logs and retention controls. Ask for one example of a transfer that failed and how the product reported it. A provider that can explain its unknown states is more useful than one that presents every attempted action as success.

Ask whether an answer signal is available from the downstream phone system or is inferred. Ask what event confirms a person picked up, how the system detects a dropped bridge, and whether an operator can trace the complete call without collecting more personal data than necessary. Check that an “AI resolved” label is tied to an authoritative CRM or booking event rather than the model’s own closing phrase.

Ask for measurement definitions and denominators before comparing claims. If one supplier reports containment on all inbound calls and another reports task completion only among supported intents, their figures are not directly comparable. Likewise, caller satisfaction, successful call routing, resolution at first contact and abandonment are distinct metrics. Preserve each metric separately and read how the sample was selected.

Checklist before opening the line

• [ ] The supported intents and prohibited actions are written in plain language.
• [ ] A caller can request a human without being trapped in a qualification loop.
• [ ] The receiving answer event is distinct from the transfer request event.
• [ ] The system does not announce a completed handoff before downstream confirmation.
• [ ] The receiving person can see a short, accurate summary with fact sources and unresolved fields.
• [ ] The caller does not have to repeat the full story in the test cases where context is promised.
• [ ] No-answer, full-queue, closed-hours, dropped-call and callback-decline cases have real outcomes.
• [ ] The receiving-side audio is clear on the production-like carrier path.
• [ ] Interruptions and corrections do not cause the system to act on stale or unheard facts.
• [ ] Retries do not duplicate transfers, appointments, cases or callbacks.
• [ ] Event logs allow the team to calculate requests, confirmed handoffs, safe fallbacks, failures and unknowns separately.
• [ ] Caller notice, legal basis, data access, processors and retention have been reviewed for the actual deployment.
• [ ] Real-call sampling has an owner, purpose, deletion schedule and restricted access.
• [ ] The stop switch and human fallback have been tested, not merely described.

If any of the first six checks fails, keep the agent off the live route or limit it to a supervised, reversible task. If a later privacy or observability check fails, pause the pilot until that control is fixed. A system that cannot report what happened should not be allowed to report that it succeeded.

Bottom line

Voice naturalness is a user-interface quality. Human handoff is a system reliability property. Choose a voice agent only after it can show a verified path from caller request to destination answer, context receipt and a usable next step—and can represent no-answer, bad audio, disconnect and uncertainty honestly. Use the 15 scenarios as a repeatable acceptance asset, adapt them to your risk and phone stack, and keep the results limited to the configuration and period actually tested. No benchmark or article can promise a ranking, a customer-experience gain or production performance for your exact line.

Sources and scope notes

• Microsoft, “Best practices for voice-based agents,” current guidance on interruption handling and human handoff. Product documentation; recommendations, not a regulatory standard: Microsoft Learn
• Cekura, “Best Production Voice Agent Benchmark 2026,” nine agents, ten scenarios, three repeats per scenario as described on the page. Provider/sample/method limits apply: benchmark methodology
• VAmoS Bench, arXiv preprint on simulation-based voice-agent task outcomes; first version focuses on finance and is not a universal deployment benchmark: paper abstract
• AFRC and IPAG Business School, 2025 customer-relations and AI study, based on 14 semi-structured interviews with large French companies selected by the research team; qualitative scope: study PDF
• PwC, description of a voice-agent product developed with OpenAI; includes early projections and an expected client outcome, not an independent comparative test: product brief
• Retell AI Community, one July 2026 support discussion about audio after a cold transfer; illustrative case, not a prevalence estimate: community discussion
• Assistable, recorded June 2026 product demonstration; the page explicitly limits what is audible about the receiving person’s briefing: transfer demonstration
• Commission européenne, AI Act risk-based framework overview. This article is operational guidance, not legal advice: framework overview
• CNIL, 2026 retention reference for workplace telephone recordings; the stated durations are scope-specific guidance and should not be generalized to all customer-call processing: retention reference

Method note: research and article checks completed 23 October 2026 (Europe/Paris). The original asset comprises 15 authored scenario types and the included log-consistency checker; no voice-agent platform was run for this article. Search Console figures refer only to the specified site/page and 13–20 October 2026 window. Forum material and a vendor demo were used to identify test questions, not to estimate incidence or prove product performance. Relevant sources were read before writing; conflicting benchmark methods remain incomparable, so no averaged score or industry-wide claim is made.