Faster response and/or break-in to speak

Support Help
1

How can I get my agent to not wait for the IVR caller response to complete speaking and to respond right when the desired option is said even if the IVR continues to speak?

2

Hey @mail4j098 To have your agent respond/act mid-IVR (as soon as it hears the desired option), increase Interruption Sensitivity (higher = agent interrupts the IVR sooner) and increase Responsiveness in Speech Settings. Pair this with clear IVR navigation prompts and a Press Digit tool so the agent knows exactly when to act. Thank You

3

Thank you @mark1, unfortunately this did not do the trick. I maximized the Responsiveness and set the Interruption Sensitivity to each extreme, tested both, same results for my issue. This Interruption setting appears to be for the Retell agent to block or allow it being interrupted. I need to force my Retell agent to interrupt so that it injects press_digit or speak even while the IVR is speaking the rest of the options.

It appears my Retell agent is waiting for a pause and then another moment to process the text instead of jump in when the desired option is stated. Are there other options in order to force it to react faster, at least for one specific statement that is well defined, and consistent? Thank you

4

Hello @mail4j098

Thanks for the detailed write-up — your read on the two settings is correct, and that’s why neither moved the needle:

  • *interruption_sensitivity** only controls how easily the user can interrupt the agent. It has no effect when the other side (the IVR) is the one talking.
  • *responsiveness** controls how long the agent waits after it has decided the other side is done speaking. It can shorten that wait, but it cannot make the agent respond before the other side pauses.

Today the agent pipeline is strictly turn-based: the LLM (and therefore press_digit / speech) is only invoked once endpointing detects a pause from the remote side. There is no setting that lets the agent barge in on a third-party IVR mid-utterance or trigger on a partial transcript / keyword, so what you’re trying to do isn’t achievable with configuration alone right now.

What we’d recommend to minimize the lag:

  • On the IVR-navigation node specifically, set *responsiveness to 1.0** as a node-level override (so it doesn’t affect any human-facing nodes).
  • If you’re on Deepgram for STT, lowering *endpointingMs** in custom_stt_config shortens how long the ASR waits before declaring the IVR done — this is the most direct knob for “react sooner after the option is spoken.”
  • In the prompt for that node, give a very tight, deterministic rule like “As soon as you hear ‘for billing, press 2’, press 2 immediately — do not wait or acknowledge.” The model will then fire press_digit on the very first turn-end after the keyword.

The combination of those three gets the response as close to the IVR’s pause as the pipeline allows. If “barge in on the remote party” is something you’d like us to weigh as a product request, let us know how often you hit IVRs that don’t pause between options and we can attach that context.

Thank You

5

Hi Mark1,
Thank you very much for this, it is very helpful.

Knowing which knob to turn is valuable. I reduced the Pause Detection from the ‘press_digit’ function which really helped what I needed.

I regularly find that IVR prompts will say multiple options and not require the user to wait for the end before making a selection. It is desirable to be able to trigger the DTMF tone as soon as the desired option is heard.

My agent is working much better. Thank you for your help.
John