# Voicely — full corpus

> AI voice agents that answer and make your business calls This file concatenates every blog and glossary page
> published on callvoicely.com, tldr and full body, for a reader
> that wants the content in one fetch rather than a crawl per page. It is
> generated at build time from the same MDX source the pages render from —
> see llms.txt for the index.

# What four phone calls taught us that the tests did not

It took four attempts to get one voice agent through a complete phone call. Each of the first three found a defect that the entire test suite had passed. The lesson for anyone buying voice AI is that a working demo and a working phone line are different products, and only one of them is what you are paying for.

## The number

Our first complete production phone call ran 112 seconds over 16 turns and ended
cleanly. Getting there took four attempts.

The first three each found a defect. Not one of those defects was caught by the test
suite, and the suite was not thin. Every one of them had a passing test that asserted
the opposite of what the phone line did.

That is the whole post, and it is the reason this company argues what it argues on the
rest of this site. The wider list of
[why voice AI agents fail on real phone calls](/blog/why-voice-ai-agents-fail) starts
here.

## Why the tests agreed

A test is written by the same person, from the same understanding, as the code it
covers. When the misunderstanding is about the outside world, the test inherits it and
then confirms it. The suite goes green, and the green means the code matches the
assumption rather than that the assumption matches reality.

Voice telephony is unusually rich in assumptions that feel obviously true and are not:

- That when the speech vendor says it has finished delivering audio, the caller has
  finished hearing it. Those are different moments, seconds apart, and the difference
  decides whether callers can [interrupt the agent](/glossary/barge-in) during the
  second half of a sentence.
- That a pause long enough to mean "I have finished speaking" is one number. That
  decision, [end-of-turn detection](/glossary/end-of-turn-detection), needs at
  minimum one number per language, which is why
  [callers who mix Hindi and English](/glossary/code-switching) break systems tuned on
  one of them.
- That audio arrives in the order and at the rate it was sent. On a mobile network it
  does neither.

Every one of those is invisible in a browser tab. A laptop microphone and a local
connection make all three assumptions true. A carrier makes none of them true.

## What we changed as a result

Two things, and both are now visible to customers.

**We record the timing per turn, on every call, and keep it.** How long the caller sat
in silence before hearing an answer is the number a voice product is judged on, and it
cannot be worked out after the fact. Storing it only when someone complains is storing
it too late. This is also the number we suggest asking any vendor for, in the piece on
[questions to ask a voice AI vendor](/blog/questions-to-ask-a-voice-ai-vendor).

**We treat production as the test.** Assertions that can only be checked on a live call
run on live calls, in production, on real traffic. The first of them fired on the first
real phone call and named the exact problem. A scheduled probe samples; production sees
everything.

## What this means if you are buying

Three things follow, and they are worth more than any feature list.

**A demo tells you the vendor can hold a conversation, not that they can hold a phone
call.** Those are different products. Ask what has gone wrong on a real call.

**Ask for the evidence per call, not the average.** A vendor who records what each
caller experienced can show you the bad call. A vendor who reports one figure across a
thousand calls has no way to explain the one that lost you a customer.

**Run the pilot on your own line.** Two weeks on one call type, on real callers,
measured against what that job costs you today. The vendor whose system survives that is
the one to sign with, and it will not always be the one whose demo was smoothest. There
is a short guide to
[picking which call type to start with](/use-cases).

Source: https://callvoicely.com/blog/four-phone-calls

---

# Nine questions to ask a voice AI vendor before you sign

Most voice AI demos are honest and still tell you almost nothing, because a browser tab on a quiet laptop is not a phone call. These nine questions are the ones whose answers change between vendors, and each one has a tell in the wrong answer.

## Why demos are a poor test

Every voice AI demo you will sit through this quarter works. It works because it runs
in a browser tab, on a laptop, in a quiet room, with a good microphone, on a script the
vendor chose. Nothing in that sentence describes a phone call.

The gap between the two is where pilots die: a caller on a moving train, on a mobile
network that loses a fraction of a second of audio, switching between Hindi and English
inside one sentence, talking over the answer because they already know what they want.

Nine questions follow. Each one has an answer that differs between vendors, and each
has a wrong answer worth listening for. The failures the questions are designed to
catch are collected in [why voice AI agents fail](/blog/why-voice-ai-agents-fail).

## What did the slowest one call in twenty look like last week?

Not the average. The average is the number that hides the calls where your customer
hung up.

**The tell:** a vendor who cannot answer this does not record how long each caller
waited, which means nobody can tell you afterwards why a bad call was bad. Timing per
turn either exists or it does not, and it cannot be reconstructed later. There is more
on why the published figures rarely compare in
[response time in a voice agent](/glossary/response-latency).

## Where are your servers, physically?

Every leg of a voice call goes to a server somewhere and comes back, on every turn. If
those servers are on another continent, that round trip is paid before any work has
been done.

On our own systems, reaching speech recognition from Mumbai takes about 20 ms. Reaching
the same models hosted in the United States takes about 300 ms. No engineering wins that
back, and the old telephony guidance in
[ITU-T G.114](https://www.itu.int/rec/T-REC-G.114) is a reminder of how little delay a
conversation tolerates before it degrades.

**The tell:** "our cloud provider has a region in India" is not the same answer as "the
speech, the reasoning and the voice are all served from India". Ask about all three.

## Can I interrupt it in the last two seconds of a long answer?

Try it in the demo. Many systems stop listening the moment they have handed the audio
over, which is several seconds before the caller has finished hearing it. The result is
an agent you can interrupt at the start of a sentence and not at the end.

**The tell:** the vendor demonstrates interruption by breaking in at the beginning. Ask
to do it yourself, near the end.

## What happens when a door slams?

The opposite failure. On an Indian mobile call there is always background noise. A
system tuned in a quiet room stops mid-word every time a bus passes.

**The tell:** the demo is conducted somewhere silent. Ask them to take it outside. Both
of these failure modes are covered in [barge-in](/glossary/barge-in), and the more
common complaint, that the [voice AI agent interrupts callers](/blog/voice-ai-agent-interrupts-callers),
has three causes worth testing for separately.

## Show me a sentence with two languages in it

Not one language and then the other. One sentence: Hindi, an English product name, back
to Hindi. That is how your customers speak.

**The tell:** the answer is a language count. "We support 40 languages" means the system
can be set to each of them, which is a different claim from handling two at once. The
detail that matters, and the reason a single setting cannot work, is in
[callers who mix Hindi and English](/glossary/code-switching).

## What are the rules for fetching a person, and who writes them?

The answer should be that you write them and they are enforced in advance: a subject the
agent never touches, a value above a threshold, an upset caller, a caller who asks.

**The tell:** handover happens only after the agent has failed. That means every
customer who needed a person spends ninety seconds discovering the agent could not help,
and arrives at your colleague annoyed. See
[when a voice agent should fetch a person](/glossary/human-handover).

## What does my colleague see when the call is transferred?

They should see who is calling, what was asked, and what has already been looked up. If
the call is merely forwarded, your customer repeats themselves, which is the experience
they rang to avoid.

## Who bills the call minutes, and can I keep my numbers?

Minutes are often the largest line on the invoice and are frequently billed by a
different company from the one selling you the software. Ask for both figures before
comparing quotes, and ask what happens to your numbers if you leave. The two common
arrangements are set out in [SIP trunking](/glossary/sip-trunking). If you resell voice
agents to your own clients, ask your supplier the same two questions; the page on our
[white label voice AI platform](/white-label) sets out what a reseller should expect.

## What has gone wrong on a real call, and what did you change?

The last one, and the most revealing, because the honest answer is specific and the
dishonest answer is smooth.

**The tell:** "nothing significant". Every system that has been on a live phone line has
a list. A vendor who cannot produce one has either not been on a phone line or is not
watching. Ours starts with the day it took
[four attempts to complete one phone call](/blog/four-phone-calls), three of which
found a defect the entire test suite had passed.

## What to do with the answers

Pick one call type your team handles a lot and dislikes, and run the same two-week test
with each shortlisted vendor on your own inbound line. Agree beforehand what it is
measured against: calls answered outside working hours, callbacks made within a minute,
appointments confirmed without a person. Then the comparison is between products rather
than between sales decks.

Our own version of that test is described on the page about
[which calls to hand over first](/use-cases).

Source: https://callvoicely.com/blog/questions-to-ask-a-voice-ai-vendor

---

# Is AI calling legal in India? What TRAI changed

Yes, AI calling is legal in India. What changed on 18 September 2026 is narrower and more concrete: TRAI now defines "A2P calls" to explicitly include autodialled, robocall and artificial-voice calls, and requires the business sending them to declare that use to its telecom provider in advance. An undeclared A2P call, whatever it says, is treated as spam.

## The short answer

Nothing in TRAI's Third Amendment to the Telecom Commercial Communications
Customer Preference Regulations, 2018, [gazetted 18 September
2026](https://www.trai.gov.in/sites/default/files/2026-09/Regulation_18092026.pdf),
makes AI voice calling illegal in India. It does something more specific, and
more useful to know before you sign a contract: it names the category an AI
voice agent's outbound calls fall into, and attaches a duty to it.

## What changed

Two changes matter for anyone buying or running outbound voice AI in India.

**First, a new definition.** The amendment inserts clause (ea) into the
principal regulations:

> "Application-to-Person call or A2P call" refers to a voice call that is
> initiated by an application, software system, or automated platform without
> direct human dialling and delivered to an individual telecom subscriber;
> including using autodialling, robo-calls and/or pre-recorded/artificial
> voice technologies.

That is not a vague aside; it is the operative definition the rest of the
amendment hangs on, and it was written to be technology-neutral: an
autodialer working a list, a recorded robocall, and a voice AI agent
conducting a live conversation are all "without direct human dialling," so
all three land in the same category. Read what the category covers in full in
[A2P call](/glossary/a2p-call).

**Second, a declaration duty.** Regulation 4 is replaced with this:

> Every Sender shall declare to the Originating Access Provider (OAP), in
> advance, about the use of Application-to-Person (A2P) calls, along with the
> details such as Calling Line Identification (CLI) ranges to be used for
> making A2P calls... Provided that any such call made by a Sender without
> prior declaration to the OAP, shall be treated as Unsolicited commercial
> communication.

Read plainly: before a business places A2P calls, it tells its telecom
provider which numbers it will call from, and that gets recorded on the
industry's shared DLT platform. Skip the declaration and the calls are
treated as spam, not because of anything said on the call but because the
paperwork was never filed.

## The enforcement side: AI now watches for AI

The amendment also inserts a new regulation 21A, requiring every terminating
carrier to run an AI/ML-based detection system that flags Calling Line
Identifications with a high probability of sending unsolicited commercial
communication, and share the flag with the originating carrier within two
hours. It is the mirror image of the declaration duty: one side of the rule
tells you to identify yourself before you call at scale, the other side is
the machinery that goes looking for the numbers that did not.

## When it takes effect

The regulations are staged from the 18 September 2026 gazette date: most
provisions in thirty days, the declaration duty in regulation 4 among a
smaller set that takes sixty days, and a further batch of amendments
(including a termination charge on A2P calls) at ninety days. A business
running outbound voice AI calls into India has a window measured in weeks,
not months, to have this conversation with its telecom provider and its
vendor.

## What to ask before you sign

Three questions, on top of the [nine questions to ask a voice AI
vendor](/blog/questions-to-ask-a-voice-ai-vendor):

- **Who is the "Sender" on our calls, us or you?** The declaration duty
  falls on the Sender, and if that is the vendor's own number resources
  rather than yours, you need to know whose declaration you are relying on.
- **Has that declaration been filed**, or is it a plan for later?
  TRAI's language treats an undeclared call as spam from the first call, not
  from some grace period.
- **What happens to our calls if the declaration lapses or a number gets
  flagged** under the new AI/ML detection in regulation 21A? A vendor who has
  not thought about this has not read the amendment.

This is a paperwork question with a real consequence: a call that never
gets answered because it was treated as spam before anyone picked up. It
belongs in the same conversation as the technical questions in
[nine questions to ask a voice AI vendor](/blog/questions-to-ask-a-voice-ai-vendor),
next to [where the vendor's servers physically sit](/blog/voice-ai-indian-phone-calls).

Source: https://callvoicely.com/blog/trai-rules-for-ai-voice-calls

---

# Why a voice AI agent interrupts callers, and how to stop it

A voice agent interrupts callers because it decided they had finished speaking when they had not. On real phone calls that decision goes wrong in three ways: the pause threshold was tuned for one language, a gap in a mobile network looks like a pause, and somebody talking in the background looks like the caller. Each has a different fix, and none of them is "make the agent wait longer".

## What the caller experiences

Your customer rings to ask about an order. Halfway through the sentence they pause to
read the order number off a screen. The agent answers the half-question. They start
again, louder, and the agent, which is now speaking, either talks over them or stops
dead. By the third turn they are speaking in short bursts to stay ahead of it, and they
hang up with the impression that your company has installed something that does not
listen.

People who run voice agents describe this as one problem. On real phone lines it is
three, and each one needs a different fix.

## What is happening underneath

A voice agent cannot see the caller. Its only signal that a person has finished
speaking is that the line has gone quiet, so it waits for a pause of a certain length
and then replies. That decision is called
[end-of-turn detection](/glossary/end-of-turn-detection), and every interruption you
have ever heard from a voice agent is that decision being made too early.

The obvious fix is to make the pause longer. That works, and it is wrong, because the
same delay is then added to every reply on every call, and past about two seconds of
silence callers assume the line has dropped. A vendor who solves interruptions by
turning up one number has moved your complaint from "it cuts people off" to "it is
slow", which is the complaint described in
[response time in a voice agent](/glossary/response-latency).

The three causes below are the ones we found on the way to our first completed
phone call, which took four attempts. Two of them had a passing test asserting the
opposite of what the phone line did.

## Cause one: the pause threshold was tuned on one language

Measured against a labelled set of real calls, the pause that means "I have finished"
is not the same length in English as in Hindi. English speakers leave shorter gaps
inside a sentence. Hindi speakers leave longer ones. A threshold tuned on English
recordings is therefore set to cut Hindi speakers off in the middle of a thought.

The obvious escape is to stretch the threshold to suit Hindi, at which point every
English caller waits at the end of every sentence. And a caller who moves between the
two languages inside one sentence, which is how most Indian customers talk on the
phone, behaves like neither. The mechanics are set out in
[callers who mix Hindi and English](/glossary/code-switching).

**The fix** is a threshold set per language, measured against recordings of the calls
the agent will take rather than against a default. This is measurement work somebody
has to have done. It is not a setting you can turn on.

## Cause two: a gap in the mobile network looks like a pause

Our tests assumed that audio arrives in the order it was sent and at a steady rate. On
a laptop in an office that is true. On a mobile network it is not: a run of packets
gets held up in transit and reaches the agent as a short silence, followed by a burst.

A rule that counts silence counts that gap. The caller never stopped talking. The
agent decided they had, started its reply, and then the delayed audio arrived on top of
it. From the caller's side this is the agent interrupting them for no reason at all,
mid-word, on a call where they had not paused.

This one is invisible in a demo, because the demo runs over a connection that does not
do it. It is the reason a system that behaved well in a browser tab behaves badly on a
customer's phone, and it is one of the defects that
[four phone calls found and the tests did not](/blog/four-phone-calls).

**The fix** is to stop treating "no audio arrived" as the same thing as "the caller
went quiet". Those are different facts, and a system on a real phone line has to tell
them apart.

## Cause three: somebody else in the room is talking

Background conversation is speech. On an Indian mobile call there is nearly always
some: a colleague, a television, a shop. A system that cannot tell speech aimed at it
from speech that happens to be nearby will take the person behind the caller as the
caller's turn, answer it, and appear to have skipped the question that was asked.

The same weakness shows up in the other direction with the small noises a listening
person makes. "Hmm", "haan", "okay" are not turns; they are the caller telling the agent
to carry on. Taken as an interruption, they stop the agent mid-sentence. Taken as the
end of a turn, they trigger a reply to nothing. Telling a listening noise from a real
interruption is its own problem, and the work on it is
[described in public](https://izmailov.dev/blog/smart-conversation) by people who
have hit it.

**The fix** is a system that decides whether the speech it hears is the caller
addressing it, which is harder than deciding whether it is speech at all. The
opposite failure, an agent that stops dead when a door slams, is covered in
[barge-in](/glossary/barge-in).

## How to tell which one you have

Three tests, each in a live demo on a real phone number rather than a browser tab.

1. **Pause mid-sentence for two seconds,** as though reading an order number off a
   screen, in Hindi and then in English. If the agent cuts in on one language and not
   the other, you have cause one.
2. **Take the call on a mobile while walking,** somewhere the signal is ordinary. If
   the agent interrupts you mid-word when you had not paused, you have cause two.
3. **Have someone talk near you** while you are on the call. If the agent answers
   them, or repeats itself, you have cause three.

Then ask the vendor one question: is the pause threshold the same for every language,
and what was it measured against? The honest answer is specific. The other answer is a
number. There is a longer list in
[nine questions to ask a voice AI vendor](/blog/questions-to-ask-a-voice-ai-vendor),
and a way to run the same test on your own line, on one call type, for two weeks,
starting with [after-hours reception and the other calls to hand over first](/use-cases).

We found all three on our own line before a customer did. The fourth call completed.
The first three are why this page exists, and interruption is one of eight entries in
[why voice AI agents fail on real phone calls](/blog/why-voice-ai-agents-fail).

Source: https://callvoicely.com/blog/voice-ai-agent-interrupts-callers

---

# Why voice AI built for English struggles on Indian calls

Voice platforms built for English-speaking markets fail on Indian phone calls for two measurable reasons: the servers are on another continent, which costs about 300 ms on every turn against 20 ms in-country, and the timing that decides when a caller has stopped speaking is different for Hindi than for English.

## Two problems, both measurable

Voice AI platforms built for English-speaking markets often perform poorly on Indian
phone calls, and the reasons are less mysterious than they look. There are two, they
compound, and both can be measured rather than argued about.

## Problem one: the servers are somewhere else

A voice call is a loop. Audio goes to a server, an answer comes back, and the loop runs
again on every turn. If those servers sit on another continent, the network round trip
is paid every time, before any useful work has begun.

On our own systems the difference is stark. Reaching speech recognition from our Mumbai
deployment takes about 20 ms. Reaching the same models hosted in the United States takes
about 300 ms.

That is a network measurement, not a benchmark. There is no clever engineering that
recovers it, and it is spent on every turn of a call: three turns into a conversation
you have already given away most of a second to geography alone. The old telephony
guidance in [ITU-T G.114](https://www.itu.int/rec/T-REC-G.114) is a reminder of how
little delay a conversation tolerates before people start behaving as though the line
has dropped.

The uncomfortable part for a buyer is that this is invisible in a demo run over a good
office connection, and painfully visible on a customer's mobile.

## Problem two: your customers use two languages at once

Not one language per caller. Two languages per sentence:

> Mera order abhi tak deliver nahi hua, tracking mein "out for delivery" dikha raha hai
> since Tuesday.

Most platforms model language as a setting: pick one per agent or per call. That model
is correct in a market where each caller speaks one language and wrong in a market where
they do not. Whichever value you pick, it is wrong for part of every call.

The visible damage is a bad transcript. The expensive damage is in timing.

### Where the timing goes wrong

A voice agent decides that a caller has finished speaking by watching for a pause. Set
the threshold short and it cuts people off mid-thought. Set it long and every turn
carries dead air, which is the thing callers notice. The three ways that decision goes
wrong on a real line are in [why a voice AI agent interrupts callers](/blog/voice-ai-agent-interrupts-callers).

Measured against a labelled set of real calls, that threshold is not one number. English
speakers want a noticeably shorter pause than Hindi speakers do, and speech that moves
between the two behaves like neither. A single value tuned on English cuts Hindi
speakers off. Stretched to suit Hindi, it makes every English call feel slow.

So the system needs the threshold set per language, tuned against recordings of the
calls it will take. That is not a feature to buy; it is measurement work
somebody has to have done. The mechanics are set out in
[callers who mix Hindi and English](/glossary/code-switching).

## The third thing, which is not technical

Background noise. An Indian mobile call usually has traffic, a television, or another
conversation in it. A system tuned for a quiet room stops mid-word every time a bus
passes, which is the opposite failure from an agent that cannot be interrupted at all.
Both failure modes, and how to test for each in a demo, are in
[barge-in](/glossary/barge-in).

## What to ask for

- **Where is each part of the call served from?** Speech, reasoning and voice
  separately. "Our cloud has a region in India" answers none of the three.
- **Show me one sentence with two languages in it,** and give me the transcript.
- **Is the pause threshold the same for every language?** If the answer is one number,
  the system was tuned on one language.
- **Take the demo somewhere noisy.**

If those four answers hold up, the rest of the evaluation is about your business rather
than about the technology. The fuller list is in
[nine questions to ask a voice AI vendor](/blog/questions-to-ask-a-voice-ai-vendor).

There is now a fifth question that has nothing to do with latency or language: whether
[AI calling is legal in India](/blog/trai-rules-for-ai-voice-calls) the way your vendor is
running it. As of 18 September 2026 it is a paperwork question with a real consequence,
not a technical one.

Source: https://callvoicely.com/blog/voice-ai-indian-phone-calls

---

# Why voice AI agents fail on real phone calls — and the fix for each

Voice AI agents rarely fail in the demo. They fail on the phone line: servers on another continent, a pause threshold tuned for one language, interruptions that stop working near the end of a reply, a handover that only happens after the agent has failed, and no record of the call that went wrong. Each failure has a specific fix, and each fix has a question you can ask before you sign.

## Where pilots die

Nearly every voice AI demo works. It runs in a browser tab on a laptop with a good
microphone, in a quiet room, on a script the vendor chose. Then the agent is pointed at
a real number, and the first caller is on a moving train, switching between Hindi and
English in one sentence, talking over the answer because they already know what they
want.

That gap is where pilots die. Our own first complete phone call took four attempts, and
each of the first three found a defect that every automated test had passed. The eight
failures below are the ones we have watched on real lines, in the order a buyer tends to
meet them, each with the fix and with the question that shows whether a vendor has done
the work.

## It was tested in a browser, and the browser lied

A laptop microphone on an office connection makes three things true that a mobile
network makes false: audio arrives in order, it arrives at a steady rate, and the
moment the system finishes sending a reply is the moment the caller finishes hearing
it. A test suite written from those assumptions confirms them every time. The suite
goes green because the code matches the assumption, and the phone line does not.

**The fix** is to treat production as the test: assertions that can only be checked on
a live call run on live calls. The story of how we learned that is in
[what four phone calls taught us that the tests did not](/blog/four-phone-calls).

**The question:** what has gone wrong on a real call, and what did you change? A vendor
with no list has either not been on a phone line or is not looking.

## The servers are on another continent

A voice call is a loop. Audio goes to a server and an answer comes back, on every
turn. If the servers are far away, that round trip is paid before any work has begun.
From our Mumbai deployment, reaching speech recognition takes about 20 ms. Reaching
the same models served from the United States takes about 300 ms, and that gap is
spent again on every turn of every call. Telephony has known for decades how little
delay a conversation tolerates, which is what
[ITU-T G.114](https://www.itu.int/rec/T-REC-G.114) is about.

**The fix** is to serve the whole call from the country the callers are in: speech,
reasoning and voice, not one of the three. Why this matters more on Indian lines is in
[why voice AI built for English struggles on Indian calls](/blog/voice-ai-indian-phone-calls).

**The question:** where is each part of the call served from? "Our cloud has a region
in India" answers none of the three.

## It interrupts callers, or leaves them waiting

An agent decides a caller has finished by waiting for a pause. Set that pause too short
and it cuts people off mid-sentence. Set it too long and every reply carries dead air,
and past about two seconds callers assume the line has dropped. The pause that means
"I have finished" is not the same length in English as in Hindi, and a gap in a mobile
network looks exactly like a pause to a rule that counts silence.

**The fix** is a threshold set per language against recordings of real calls, and a
system that treats "no audio arrived" as a different fact from "the caller went
quiet". The three causes and the demo test for each are in
[why a voice AI agent interrupts callers](/blog/voice-ai-agent-interrupts-callers);
the mechanism is [end-of-turn detection](/glossary/end-of-turn-detection).

**The question:** is the pause threshold the same for every language? One number
means the system was tuned on one language.

## Callers cannot interrupt it, or a door slams and it stops

The opposite pair of failures. Many systems stop listening the moment they have handed
the audio over, which is seconds before the caller has finished hearing it, so the
agent can be interrupted at the start of a reply and not at the end. Others are tuned
for a quiet room and stop mid-word whenever a bus passes, which on an Indian mobile
call is most of the time.

**The fix** is to keep listening until the caller has finished hearing the reply, and to
tell speech aimed at the agent from noise that happens to be nearby. Both tests take
one minute in a demo and are set out in [barge-in](/glossary/barge-in).

**The question:** can I interrupt it in the last two seconds of a long answer? Then,
while it is talking, make a noise that is not speech.

## It has one language setting and your customers use two

Most platforms model language as a setting: one per agent or per call. That is correct
in a market where each caller speaks one language and wrong in one where a caller
begins a sentence in Hindi, names a product in English and finishes in Hindi.
Whichever value you pick, it is wrong for part of every call, and the expensive damage
is in the timing rather than the transcript.

**The fix** is a system tuned for [callers who mix Hindi and English](/glossary/code-switching)
inside a sentence, which is measurement work rather than a feature.

**The question:** show me one sentence with two languages in it, and give me the
transcript. A language count is the tell.

## A person is fetched only after the agent has failed

There are two ways to build a handover. As a fallback, the agent tries everything,
fails, apologises and transfers, and your customer arrives at your colleague after
ninety seconds of explaining something to a machine that was never going to help. As a
rule, you decide in advance which calls a person takes, and the agent transfers those
early, sometimes in the first sentence.

**The fix** is the second shape: a subject the agent never touches, a value above a
threshold, an upset caller, a caller who asks. The rules and what your colleague should
see on pickup are in [human handover](/glossary/human-handover).

**The question:** who writes the rules for fetching a person, and what does my
colleague see when the call arrives?

## Nobody can show you the call that went wrong

Every vendor publishes a speed number. Almost none say what was measured, where the
clock started, or whether it was a browser or a phone. An average across a thousand
calls tells you nothing about the one where a customer hung up, and if the wait on each
turn was not recorded at the time, it cannot be reconstructed afterwards.

**The fix** is to record how long the caller waited on every turn of every call, and
keep it, so that "it felt slow" becomes a row you can look at. What the numbers mean
and why published ones rarely compare is in
[response time in a voice agent](/glossary/response-latency).

**The question:** for real calls last week, what did the slowest one call in twenty
look like? A vendor who records per turn answers in a minute. A vendor who cannot will
offer an average.

## It was pointed at the wrong first job

A pilot on a call type your team handles twice a week cannot show anything inside a
fortnight. A pilot on a call type that takes a month of shadowing to learn will spend
the fortnight discovering exceptions. The pilots that go well are almost always the
boring ones: high volume, low variation, currently done badly because nobody has the
hours.

**The fix** is to pick the call your team makes most often and dislikes most, agree what
it costs you today, and measure the pilot against that number. The six jobs that fit,
and where a person still belongs in each, are on
[the calls to hand over first](/use-cases).

**The question:** which call type do you recommend we start with, and what will we
measure it against?

## What to do with this list

Take the eight questions into every demo, and then stop trusting demos. Run the same
two-week pilot with each shortlisted vendor on your own inbound line, on the same call
type, with the same handover rules, so the comparison is between products rather than
between sales decks. The fuller version of the questions, with the wrong answer to
listen for on each, is in
[nine questions to ask a voice AI vendor](/blog/questions-to-ask-a-voice-ai-vendor).

We found every failure on this list on our own line before a customer did. That is
the only reason we can write it down.

Source: https://callvoicely.com/blog/why-voice-ai-agents-fail

---

# A2P call: the TRAI term for an automated or AI voice call

A2P (Application-to-Person) call is TRAI's term for a voice call placed by an application rather than a person dialling: autodialled calls, robocalls, and a voice AI agent calling out. Since September 2026 the business sending them must declare the practice to its telecom provider in advance or risk the calls being treated as spam.

## Where the term comes from

"A2P call" is not industry jargon — it is a defined term TRAI inserted into the
Telecom Commercial Communications Customer Preference Regulations, 2018,
by its [Third Amendment, gazetted 18 September
2026](/blog/trai-rules-for-ai-voice-calls). The definition:

> "Application-to-Person call or A2P call" refers to a voice call that is
> initiated by an application, software system, or automated platform without
> direct human dialling and delivered to an individual telecom subscriber;
> including using autodialling, robo-calls and/or pre-recorded/artificial
> voice technologies.

## What it covers

Three things people usually keep separate turn out to be the same category
under this rule: an autodialer working through a list, a recorded robocall,
and a voice AI agent placing a call and speaking in real time. All three are
"without direct human dialling," so all three are A2P calls.

## Why it matters before you buy

TRAI's Third Amendment attaches a duty to the category, not to any one
technology: the Sender declares A2P use to its Originating Access Provider in
advance, naming the numbers it will call from. An undeclared A2P call is
treated as unsolicited commercial communication and can be blocked. The full
rule, its timeline, and what to ask a vendor about it are in
[TRAI's new rules for AI voice calls](/blog/trai-rules-for-ai-voice-calls).

Source: https://callvoicely.com/glossary/a2p-call

---

# Barge-in: letting callers interrupt a voice agent

Barge-in is a caller talking over the agent and the agent stopping to listen, the way a person would. Without it, callers have to sit through every sentence, which is the thing everybody hated about phone menus. Getting it wrong in the other direction is worse: an agent that cuts itself off whenever a door slams.

## What it is

Barge-in is the caller talking over the agent, and the agent stopping to listen. The
name comes from older telephony systems, where a `bargein` property on a prompt decided
whether callers were allowed to cut it short. In
[VoiceXML](https://www.w3.org/TR/voicexml20/) it was a setting you turned on per
prompt. In a modern voice agent it should be on all the time, because that is how
people talk.

## Not the same as call barging

Contact-centre software uses the same word for something else. There, a barge call or
[call barging](https://www.nice.com/glossary/what-is-contact-center-barge-in) is a
supervisor listening to a live call between an agent and a customer and joining it,
sometimes after whispering guidance to the agent first. That is a management feature
for a human team. The barge-in on this page runs the other way: it is your customer
breaking into what a voice agent is saying, and the agent giving way. If you are
evaluating voice AI, this is the one to ask about.

## Why it matters

Callers who already know what they want do not wait. They say the account number over
the greeting. An agent that has to finish its sentence turns every one of those callers
into somebody repeating themselves, and it is the single most recognisable trait of a
system that was built without listening to real calls.

## The two ways it goes wrong

**Deaf at the end of the answer.** This is the common one and it is hard to spot in a
short demo. Many systems arm interruption when they start producing audio and disarm it
when they have finished handing that audio over, which happens seconds before the
caller has finished hearing it. The result is an agent that can be interrupted during
the first half of a sentence and not the second. The fix is to keep listening until the
audio the caller is hearing has finished playing, which is a different clock
from the one the speech vendor reports.

**Too easily startled.** The opposite failure. A door slams, a bus passes, somebody in
the room says something to somebody else, and the agent stops mid-word. On an Indian
mobile call there is nearly always background noise, so a system tuned for a quiet room
will cut itself off constantly. Distinguishing speech aimed at the agent from noise is
the harder half of this problem, and it is where the difference between vendors shows.

## How to check it

In any demo, do these two things. Interrupt the agent in the last two seconds of a long
answer. Then, while it is talking, make a loud noise that is not speech. The mirror
image, an agent that cuts the caller off, is a different setting going wrong, and it is
worked through in [why a voice AI agent interrupts callers](/blog/voice-ai-agent-interrupts-callers). A system that
handles both is one that has been on a real phone line. A system that handles neither is
one that has been tested in a browser tab, which is a different product from the one you
are buying. Our own version of that lesson is in
[what four phone calls taught us](/blog/four-phone-calls), and the full list of ways an
agent fails once it meets a real line is in
[why voice AI agents fail on real phone calls](/blog/why-voice-ai-agents-fail).

Source: https://callvoicely.com/glossary/barge-in

---

# Code-switching: callers who mix Hindi and English

Code-switching is a speaker moving between two languages within a single sentence, which is how most Indian customers talk on the phone. Systems built to be set to one language per call mishandle it, and the damage is worst in the timing that decides when a caller has finished speaking.

## What it is

[Code-switching](https://en.wikipedia.org/wiki/Code-switching) is a speaker moving
between two languages inside one utterance. On an Indian customer-service call this is
not an edge case, it is the default:

> Mera order abhi tak deliver nahi hua, tracking mein "out for delivery" dikha raha hai
> since Tuesday.

One sentence, two languages, and the words that carry the actual meaning are split
across both.

## Why it defeats a language setting

Most voice platforms let you choose a language per agent or per call. That model
assumes one caller speaks one language, and it holds fine in a market where that is
true. Where it is not true, the setting is wrong for part of every call regardless of
which value you choose.

The visible damage is in transcription. The less visible and more expensive damage is
in timing.

## The timing problem

A voice agent has to decide when the caller has stopped talking, using the length of a
pause; that decision is [end-of-turn detection](/glossary/end-of-turn-detection). Set that threshold short and the agent interrupts people mid-thought. Set it
long and every turn of the call carries dead air, which is the main thing callers
notice, as described in [response time](/glossary/response-latency).

The right threshold is not the same across languages. Measured against a labelled set
of real calls, English wants a noticeably shorter pause than Hindi does, and speech
that switches between them behaves like neither. A single value tuned on English
speakers cuts Hindi speakers off; the same value stretched to suit Hindi makes every
English call feel sluggish. This is why Voicely tunes the threshold per language
against recordings rather than shipping one number, and the measurements behind it are
in [why voice AI built for English struggles on Indian calls](/blog/voice-ai-indian-phone-calls).

## What to ask a vendor

- Play them a mixed sentence, not one language and then the other. Ask for
  the transcript.
- Ask what the pause threshold is set to, and whether it is the same for every
  language. If the answer is one number, the system was tuned on one language.
- Ask what happens when the caller changes language partway through a call, rather than
  partway through a sentence. Some systems are fine with the first and not the second.

Source: https://callvoicely.com/glossary/code-switching

---

# End-of-turn detection: how a voice agent knows you stopped

End-of-turn detection is the moment a voice agent decides the caller has finished speaking and starts its reply, usually by measuring the length of a pause. Set the pause too short and the agent interrupts people mid-sentence; set it too long and every reply carries dead air. The right value differs by language, and on a mobile network a gap in the audio can look like a pause when it is not one.

## What it is

A voice agent cannot see the caller. The only signal it has that a person has finished
talking is that the audio has gone quiet, so it waits for a pause and, when the pause is
long enough, starts its reply. That decision is end-of-turn detection. Underneath it is
[voice activity detection](https://en.wikipedia.org/wiki/Voice_activity_detection), the
component that decides whether what is coming down the line is speech or not.

Everything a caller experiences as rudeness or slowness in a voice agent traces to this
one decision going wrong in one of two directions.

## The two directions it goes wrong

**Too short.** The agent takes an ordinary mid-sentence pause as the end of the turn
and starts answering. The caller was about to say the second half of the sentence.
Both now talk at once, the agent has answered the wrong question, and the caller has
learned to speak in short bursts to stay ahead of it. This is the failure people
describe as the agent interrupting them, and it is set out call by call in
[why a voice AI agent interrupts callers](/blog/voice-ai-agent-interrupts-callers).

**Too long.** The agent waits long enough to be sure, on every turn, and every reply
arrives after a silence. Callers do not experience this as caution. They experience it
as a slow line, and past about two seconds they start saying "hello?", which is
covered in [response time in a voice agent](/glossary/response-latency).

There is no value of one number that avoids both, because the callers on the other end
are not all the same.

## Why one number cannot work

Measured against a labelled set of real calls, the pause that means "I have finished"
is not the same length in English as it is in Hindi. English speakers leave shorter
gaps inside a sentence; Hindi speakers leave longer ones. A threshold tuned on English
cuts Hindi speakers off. Stretched to suit Hindi, it leaves every English caller
waiting. And a caller who moves between the two languages inside one sentence, which
is how most Indian customers talk, behaves like neither. That is why Voicely sets the
threshold per language against recordings, and why the mechanics of
[callers who mix Hindi and English](/glossary/code-switching) matter more than a
language count.

## What else looks like a pause, and what else looks like speech

Two things confuse the decision that have nothing to do with the caller.

**A gap in the network.** On a mobile connection, audio does not arrive in order or at a
steady rate. A run of packets held up in transit reaches the agent as a short silence,
and a rule that counts silence counts it.
The caller never stopped talking. The agent thinks they did. This one is invisible in a
demo run over an office connection.

**Somebody else in the room.** Background conversation is speech. A system that cannot
tell speech aimed at the agent from speech that happens to be nearby will treat the
television as the caller's turn, answer it, and appear to have skipped the question.
The mirror image, an agent that stops mid-word when a door slams, is described in
[barge-in](/glossary/barge-in).

## What to ask a vendor

- Is the pause threshold the same for every language? If the answer is one number,
  the system was tuned on one language.
- What was it measured against? "Our defaults" is a different answer from "recordings
  of calls like yours".
- In the demo, pause for two seconds in the middle of a sentence, as though looking up
  an order number. Then take the same call on a mobile while walking.

Source: https://callvoicely.com/glossary/end-of-turn-detection

---

# Human handover: when a voice agent fetches a person

Human handover is the agent transferring a call to one of your people, with the context it has already gathered. The rules are yours to write: a topic, a value threshold, an upset caller, or a caller who asks. A system where handover only happens after the agent has failed is a system that will annoy your customers first.

## What it is

Human handover is the moment a voice agent stops handling a call and gives it to one of
your people. It sounds like a small operational detail. It is the thing your customers
will judge the whole system on, because it is where the calls that matter most end up.

## Why it belongs in the design

There are two ways to build this, and they produce two different customer experiences.

**As a fallback.** The agent tries everything it knows, fails, apologises, and
transfers. The customer has by then spent ninety seconds explaining something to a
machine that was never going to be able to help, and they arrive at your colleague
already annoyed.

**As a rule.** The business decides in advance which calls a person should take, and
the agent transfers those calls early, sometimes within the first sentence. The
customer never discovers that the agent could not have helped, because it never tried.

The second is the correct shape, and it is why the first question worth asking about
any call type is not "can the agent handle this" but "which parts of this should it
never attempt".

## The rules worth writing down

- **Subject.** Anything legal, medical, safety-related, or about a complaint already in
  progress. This list is short and specific to your business.
- **Value.** Above a rupee threshold, a person confirms it. The threshold is yours.
- **Emotion.** A caller who has become upset gets a person, and the agent should not
  attempt to calm them down first.
- **On request.** A caller who asks for a person gets one, immediately, without being
  asked why. Every system that argues about this is training your customers to start
  the call by shouting.

## What to check

Ask a vendor what the agent does with everything it has learned when it transfers. The
answer should be that your colleague can see the caller's number, what they asked, and
what has already been looked up. If the answer is that the call is merely forwarded,
your customer is about to repeat themselves, and the handover has undone most of the
value of the agent taking the call in the first place.

An agency or platform running [white label voice ai](/white-label) for its own
customers writes these rules per customer, not once for the whole book — the
handover threshold one account sets should never leak into another's calls.

There is a section on where a person still belongs for each of the common
[call types businesses automate first](/use-cases).

Source: https://callvoicely.com/glossary/human-handover

---

# Response time in a voice agent, and how to ask about it

Response time on a voice call is the silence between a caller finishing their sentence and hearing the first word of the reply. Under about a second feels like a conversation; past two seconds callers assume the line has dropped. Published vendor figures are rarely comparable, so ask for the distribution across real calls rather than an average.

## What the caller experiences

A caller does not experience a pipeline. They experience silence: the gap between the
moment they stop talking and the moment they hear a voice. Everything that happens
inside that gap is the vendor's problem, and the caller's only measurement is whether
the pause felt normal.

Roughly, and consistently with how people react on ordinary telephone calls:

- **Under about a second** feels like talking to somebody.
- **One to two seconds** feels like talking to somebody who is distracted.
- **Past two seconds** and callers start saying "hello?" because they assume the line
  has gone.

The old telephony standard on this, [ITU-T G.114](https://www.itu.int/rec/T-REC-G.114),
is about one-way transmission delay rather than about thinking time, but it points at
the same human threshold: conversations degrade well before a second of delay.

## Why published numbers rarely compare

Almost every vendor in this market publishes a sub-second figure, and almost none of
them say what was measured. Four things vary, and each of them can move the number by
more than the difference between two vendors:

- **Where the clock starts.** From the end of the caller's speech, or from the moment
  the system decided the caller had finished? Those are different numbers, and the
  second one quietly excludes a real part of the wait.
- **Where it stops.** At the first byte of audio produced, or at the first sound the
  caller can hear? A carrier connection sits between those two.
- **What it was measured on.** A browser tab on a laptop with a good microphone, or a
  telephone call over a mobile network.
- **Average or worst case.** An average across a thousand calls tells you nothing about
  the one where a customer hung up.

## The question that gets a straight answer

Ask this: *for real phone calls last week, what did the slowest one turn in twenty look
like?*

A vendor who records timing per turn can answer immediately. A vendor who cannot will
give you an average, which is the tell. This is why Voicely records how long the caller
waited on every turn of every call and keeps it, rather than reporting a single figure:
the number is only useful on the call that went badly.

## What makes it slow

In rough order of how much each one costs:

- **Distance.** Every leg of the work goes to a server somewhere. If those servers are
  on another continent, the network round trip is paid on every turn, before any work
  is done. What that costs on an Indian phone line is measured in
  [why voice AI built for English struggles on Indian calls](/blog/voice-ai-indian-phone-calls).
- **Waiting too long to decide the caller has finished.** Deciding too early
  interrupts people; waiting too long adds dead air to every turn. The setting is
  [the pause threshold, or end-of-turn detection](/glossary/end-of-turn-detection). The right value is
  different per language, which is why a system tuned only on English gets it wrong for
  [code-switching](/glossary/code-switching) callers.
- **Doing the work in sequence rather than as it arrives.** Waiting for a complete
  answer before starting to speak adds the whole length of the answer to the pause.
- **Looking things up.** A slow lookup in your own system is a slow call, and it is the
  one part of this a vendor cannot fix for you.

Source: https://callvoicely.com/glossary/response-latency

---

# SIP trunking, explained for people buying voice AI

SIP trunking carries telephone calls over an internet connection rather than over traditional phone lines. It matters when buying voice AI because it determines whether an agent can be attached to the numbers you already publish, and because call minutes are often the largest line on the invoice.

## What it is

A telephone call has to travel somehow. Traditionally it travelled over dedicated phone
lines rented from a telecoms company. SIP trunking carries it over an ordinary internet
connection instead, using a protocol called SIP, defined in
[RFC 3261](https://www.rfc-editor.org/rfc/rfc3261), to set up, manage and end each call.

The word "trunk" is inherited from the physical bundle of lines it replaced. In practice
it is a connection between your phone numbers and whatever software answers them.

## Why it comes up when buying voice AI

A voice agent is software. For it to answer your main number, that number's calls have
to reach the software, and SIP is usually how. Three practical consequences:

- **Your existing numbers can usually stay.** You do not have to publish a new number or
  reprint anything. The number keeps ringing where it rings; a copy of the call reaches
  the agent.
- **Somebody is billing you per minute.** Call minutes are frequently the largest line
  on a voice AI invoice, and they are often billed by a different company from the one
  selling you the agent. Ask which, and ask for both numbers before you compare vendors.
- **How many calls at once has a limit,** and the limit is a setting rather than a
  rebuild. Worth agreeing before a campaign rather than during one.

## The two arrangements

**The vendor supplies the numbers.** Simplest to start, and everything appears on one
invoice. You are then buying your telephony from your software vendor, which is fine
until you want to leave.

**You bring your own carrier.** You keep your existing telecoms provider and the vendor
connects to it. Usually cheaper at volume, and it keeps the number relationship in your
name, which is the part that matters if you ever change software.

## What to ask before signing

- Can my existing published numbers reach the agent without being ported?
- Who bills the call minutes, and at what rate?
- How many calls can run at once, and what happens at the limit?
- If I leave, do I keep my numbers, and how long does it take?

Source: https://callvoicely.com/glossary/sip-trunking

---

# Voice AI agent: what it is and how it differs from an IVR

A voice AI agent is software that answers or places a phone call, understands what the caller says in their own words, and carries out the task they rang about. Unlike a phone menu it has no fixed options, and unlike a recorded message it can be interrupted, questioned and argued with.

## What it is

A voice AI agent answers or places a telephone call and holds a real conversation on it.
The caller speaks in ordinary language, the agent works out what they want, does the
task if it can, and says the answer out loud. Nobody presses a number, and there is no
list of options to sit through.

## How it differs from a phone menu

A phone menu, properly an [interactive voice response](https://en.wikipedia.org/wiki/Interactive_voice_response)
system, is a decision tree. Every caller walks the same branches, and a caller whose
problem is not on the tree ends up at the branch marked "other". This is why people
press 0 repeatedly.

A voice agent has no tree. It has a description of its job, the systems it is allowed
to read and write, and rules about when to stop and fetch a person. Two callers with
the same underlying problem can describe it completely differently and both get
handled.

## What makes one useful

Four things, and a system that misses any of them is unpleasant to talk to:

- **It answers fast enough.** The gap between the caller finishing and the agent
  starting is the whole experience. See [response time](/glossary/response-latency).
- **It can be interrupted.** Real callers talk over the answer. An agent that finishes
  its paragraph first is the thing everyone hated about phone menus. See
  [barge-in](/glossary/barge-in).
- **It understands the caller's actual language,** including callers who move between
  two of them inside a sentence. See [code-switching](/glossary/code-switching).
- **It knows when to stop.** A [handover to a person](/glossary/human-handover) is part
  of the design rather than a failure state.

## Where businesses use them

The pattern is high volume, low variation, and currently done badly because nobody has
the hours. Reception and after-hours answering, calling new enquiries back, appointment
reminders, order status, and payment follow-ups. There is a page on
[which calls to hand over first](/use-cases) with the escalation rules for each.

Source: https://callvoicely.com/glossary/voice-ai-agent

---

# White label voice AI: reselling agents under your own brand

A white-label voice AI platform lets an agency, call centre or software company sell voice agents under their own name, with their own pricing and their own customer relationship. Whether it works in practice depends on whether customers are separated from each other underneath, which is difficult to add to a platform later.

## What it means

A [white-label](https://en.wikipedia.org/wiki/White-label_product) voice AI platform is
one you sell as your own. Your customer sees your name, your colours and your domain,
signs your contract, pays your invoice, and calls you when something is wrong. The
vendor underneath is your supplier, not theirs.

## Who does this

Three groups, all of which already sell to businesses that live on the phone:

- **Agencies and consultancies** running marketing or operations for clients who miss
  calls. Voice agents become a retained monthly service on top of work already
  happening.
- **Call centres and BPOs** being asked to quote against automation at every renewal.
  Taking the repetitive volume themselves is a better answer than losing the account.
- **Vertical software companies** selling to clinics, dealerships, lenders or logistics
  firms. A phone agent that already understands what is in their product is a feature
  competitors will spend a year building.

## What has to be true underneath

The branding is the easy part. Four things are harder, and each of them is difficult to
retrofit:

- **Separation.** Each of your customers needs their own agents, numbers, recordings
  and data, with nothing shared between them by accident. This is the one that cannot
  be added convincingly later.
- **Settings per customer.** One client's Hindi collections agent and another's English
  booking line should not have to agree about anything.
- **Spending limits per customer.** A ceiling on minutes and on how many calls may run
  at once, set by you and enforced per number, so a client's runaway campaign hits a
  limit rather than your invoice.
- **More than one brand.** If you sell under two names, the platform has to apply
  branding per customer rather than once for your whole account.

## Questions that separate a real arrangement from a logo upload

1. When was multi-customer separation built? Day one, or after the first partner asked?
2. What can one of my customers see or reach of another's?
3. Who owns the contract and the invoice with my customer?
4. What stops one of my customers spending my money?
5. Will you sell to my customer directly if they contact you?

There is a page for partners on
[selling voice agents under your own brand](/white-label), including how the first one
usually gets built.

Source: https://callvoicely.com/glossary/white-label-voice-ai