Enable/Disable Barge-In
What Is Barge‑In in Voice Bots?
Barge‑in is a feature in voice bots that allows a caller to interrupt the bot while it is speaking. For example, if a voice assistant starts explaining something and the user already knows the answer, they can speak over the bot to skip ahead or change the flow of the conversation.
Why Is Barge‑In Important?
Barge‑in improves user experience by making conversations feel more natural and efficient. Instead of waiting for the assistant to finish a long message, users can respond immediately—just like in a human conversation.
Why Would You Disable Barge‑In?
The text you provided highlights an important compliance use case, especially in regulated industries such as:
Banking and financial services
Regions with strict regulatory requirements (e.g., EMEA)
In these scenarios, there are parts of the conversation—such as legal disclosures, compliance statements, or mandatory explanations—that must be spoken in full. Users are not allowed to interrupt or skip these sections.
For example:
A banking voice bot may be required to read out a specific legal disclaimer.
Regulations may mandate that every word of that message is delivered to the caller.
If barge‑in were enabled, a user could interrupt the assistant and say something like “Yeah, skip this part”, which would violate compliance requirements.
Barge‑In at the Node Level
The feature can be enabled or disabled at the node level, which means:
You can turn barge‑in ON for parts of the conversation where flexibility is allowed (e.g., navigation, FAQs).
You can turn barge‑in OFF for specific nodes where the bot must complete its message without interruption (e.g., compliance or regulatory statements).
This gives designers precise control over where interruptions are allowed and where they are not.
There are three visible parts to this feature:
Barge-in Controls
Comfort Play
Run Ahead
1. Barge-in Controls
In previous versions, Say nodes were not interruptible. This behavior was hard‑coded, meaning users could not speak over or interrupt a Say node once it started playing. This behavior was not configurable and remained outside the flow designer’s control.
To configure this feature, click on Say or Agent node:
Default is “checked ON”; unclick to disable this feature.
Then click on SAVE:
From a user experience standpoint, it is good to have all nodes to be enabled with “Barge-in feature”. Only in cases where customer must listen to bot audio, due to legal compliance, the barge-in can be disabled.
⚠️ Warning: Potential Loss of User Input
If an earlier interaction node has Barge‑in enabled and a subsequent node has Barge‑in disabled, interrupting the first node may result in unexpected behavior. Specifically:
When a user interrupts a barge‑in–enabled prompt, playback stops at the point of interruption.
The next prompt with Barge‑in disabled will play in full.
Any user input collected during the interruption is discarded, and the user must provide their input again.
While a later node with Barge‑in enabled may allow the user to re‑enter their input, this can lead to frustration and a suboptimal experience.
Best Practice (Recommended):
Place prompts with Barge‑in disabled at the beginning of the flow (e.g., mandatory or informational messages).
Follow them with prompts that have Barge‑in enabled, ensuring user input is accepted and not discarded.
This configuration is recommended for optimal user experience, but it is not automatically enforced by the system.
2. Comfort Play
Comfort Play is designed to improve the user experience during periods when the system is processing and cannot respond immediately.
In some scenarios—such as when a backend API call takes longer than expected—the voice bot may otherwise remain silent while waiting for a response. Extended silence can make users feel that the system is unresponsive or stuck.
Comfort Play addresses this by allowing you to play audio while processing is in progress.
To set up a comfort play:
Navigate to Flow Settings:
Go to Step 4: Voice Settings:
Scroll down to Comfort Prompt Settings:
Comfort Prompt: It is recommended to provide a public URL here which has a pre-recorded audio, that is accessible to Customer V2 environment.
Comfort Prompt Delay: It is how long the system must wait, to see if the response comes back. If the response is going to take less than, in this case, 2.5 seconds, then it wouldn't play this.
Comfort Prompt Min Play: How long the audio is to be played, once play is initiated.
Note:
Comfort play cannot be barged-in for the min play time; after that it can be interrupted.
It will not loop, in case delay extends beyond min play time.
3. Run Ahead
The Run Ahead feature improves conversation performance by allowing the runtime to continue executing subsequent steps in a flow while prompts are still being played to the user.
Behavior in Earlier Versions
In previous versions of the system, flow execution was strictly sequential:
A node had to complete fully before the runtime moved to the next node.
For example, when a Say node sent a prompt to the channel, the runtime paused execution until the prompt finished playing.
Only after playback completed would the runtime proceed to the next step, such as an API call.
This design often caused unnecessary delays. In many cases, backend work (like API calls) could have been executed while the prompt was playing, but the system was unable to do so.
How Run Ahead Works
With Run Ahead enabled, the system operates more efficiently:
Prompts are sent to the channel and queued for playback.
While the channel plays these prompts, the runtime continues executing subsequent nodes wherever possible.
Execution proceeds until the runtime reaches a point where it must stop—typically when user input is required (for example, at an Agent node).
At that point:
The runtime signals that it is waiting for user input.
The channel finishes playing any queued prompts.
User input is then accepted within the configured timeout window.
Interaction with User Interruptions
Run Ahead is designed to preserve semantic consistency of the flow:
Backend operations (such as API calls) are not canceled, even if the user interrupts a prompt.
If the user speaks while an API call is still running, the runtime allows the operation to complete.
Any user input provided during this time is buffered.
Once the runtime reaches an Agent node that can consume the input, the buffered input is processed.
This ensures that dependent data (for example, results from a weather API call) is always available when required by downstream nodes.
Example Scenario
A Say node plays a prompt.
While the prompt is playing, an API call executes in parallel.
The user barges in during the prompt.
The API call continues and completes.
The user’s input is captured and processed once the flow reaches the appropriate Agent node.
Key Benefits
Reduced perceived latency
Faster overall flow execution
Reliable handling of user interruptions
Consistent and predictable runtime behavior
Last updated
Was this helpful?