Hi, my agent is set up to press 1 to accept forwarded numbers. After it presses 1 to accept, the agent is silent until the customer speaks first, then it starts the welcome message. When the agent is getting calls directly, it welcomes the customer first, but it seems to be quite when answering forwarded numbers. How can I fix this?
Thank you for reaching out to Retell AI Support. We’ve received your ticket and our team will respond within 8 hours.
Hi Retell,
Thanks for the details about your agent’s behavior. To help us investigate further, could you please provide the following:
- If a particular agent was affected, what is the agent ID?
- What is the purpose or use case of this agent?
- A copy of your company’s registration document (or proof of incorporation).
- Your company’s website URL (if available).
- If you are speaking on behalf of another company, an authorization letter granting you permission.
If you’re not able to share any of these details, just let us know and we’ll proceed with our investigation.
Best,
Evy AI
AI Support Agent @ Retell AI
Is there any update on this? I am also trying to implement a similar feature and am having difficulty doing so.
Hello @jasonrosso can you share relevant agent id and call id?
Agent ID: agent_a102c5a1879723918d5e6cef56
Call IDs
call_6b35b156dbd731e1d9f01d6e43f
call_2c3e026e1dd9851051190774c99
call_e07edff9cb572c9d16e04541fb0
Hi @jasonrosso checking with the team
Essentially, I need a way to simulate a digit press without having to rely on a user response or an IVR response.
The press digit node seems to be built around a conversational framework and it will not allow me to transition out of it if the user end of the call is silent.
I have tried several work arounds, even building a seperate single promt node to call a digit press function, but none seem to be reliable and it alwasy goes back to retell expecting a response after a digit press and not allowing tthe agent to be first to speak after said digit press
Hey Jason, I’ve experienced something similar before. What was wrong on mine was that the interruption sensitivty was too high/too low to properly pick up the IVR press. Have a look at that first for your node that it’s on (and it will need to allow interruptions)
Thanks, Nick.
I found a work around.
What I did was use a subagent node to call the pre-built press_digit function and was able to set its transition condition to skip user response (something I was not able to do with the dedicated Press Digit node).
Seems to be working so far.
Hello @jasonrosso Thanks for the call IDs, that gave us a clean trace. Here’s what’s happening:
Your flow’s start node (“Greeting v11 With Button Press”) is a prompt-driven conversation node that runs before the press-1 step. On forwarded calls the carrier plays a “You have a new lead, press any key to connect” announcement before bridging the human. That announcement is being transcribed as a user turn at ~0.4s, which triggers a partial “Thanks for calling Waygur Painting…” before the IVR finishes. The flow then moves to the Press Digit node, fires press_digit(“1”) at ~4s — and there is no node after Press Digit configured to speak. So once the human is bridged, the agent has nothing to say until the caller speaks and the LLM transitions out of the Press Digit node. That’s the silence you’re observing.
Can you try these two changes:
- Add a deterministic post-press greeting node. Right after the Press Digit subagent node, insert a
conversationnode whose instruction isstatic_textwith your welcome line (e.g. “Hi, thanks for calling Waygur Painting, this is Emily how can I help?”). Wire the Press Digit node’s outgoing edge into this new node. Astatic_textnode speaks immediately on entry without waiting for the caller. - Make the start node not greet on the pre-press leg. Either move the Press Digit subagent to be the start node (so press_digit fires first, then transitions to the new greeting node), or change
node-1770822939083’s instruction so it doesn’t attempt a greeting when thebutton_pressbranch is taken. The orphan “Hi!” nodenode-1781548933466) you already have in the flow looks like it was meant for exactly this wiring it in after Press Digit would close the gap.
Optional polish: under the agent’s Welcome Message → Pause Before Speaking, add ~500–1000 ms so the static-text greeting lands cleanly after the carrier finishes bridging the audio path.
For the second part implementing the same pattern on another agent same shape: start node is a press_digit subagent (no speech), unconditional transition to a static_text welcome node, then the rest of the flow.
Thank You
Subject: Agent silent after press_digit on a retell-llm (single-prompt) agent — Conversation Flow fix doesn’t apply
Hi team,
We’re hitting the same issue described in this thread: Agent doesn’t speak after pressing digit until customer speaks first
Our setup: Our voice agent forwards through Google Voice, which plays a “press 1 to confirm you’re not a voicemail” screening prompt before bridging the real caller. Our agent detects this prompt and calls the built-in press_digit tool to send “1”, which succeeds. But once the real caller is bridged, the agent stays completely silent until the caller speaks first — it never delivers its opening greeting on its own.
Key difference from the linked thread: In that thread, support’s fix was to insert a static_text conversation node right after the Press Digit node in Conversation Flow, so it speaks immediately on entry without waiting for the caller.
Our agent is not a Conversation Flow agent — response_engine.type is retell-llm (single-prompt: general_prompt + general_tools, no states, no nodes/edges). There’s no equivalent structure in this agent type to “insert a node after Press Digit.”
press_digittool config already has"speak_after_execution": true- Our prompt explicitly instructs the agent to speak immediately and unprompted after
press_digitsucceeds, without waiting for the caller — this has no effect on the behavior
Question: Is there an equivalent fix for retell-llm (single/multi-prompt) agents — some way to force the LLM to generate a follow-up turn immediately after press_digit succeeds, without waiting for a new caller utterance? Or is this capability currently exclusive to Conversation Flow agents?
Agent ID: agent_e7a74e69687ffeb806e5085a9d
LLM ID: llm_da47d50b1cb611f9b114e8cf82b7
Happy to share call IDs/recordings if that helps trace it.
HELP US PLEASE!!!
Thanks!
Hello @supernova77 Could you please share any relevant Call IDs? This will help us investigate the issue further.
Hi Shah,
Thank you Shah for helping with this. It is affecting us being able to provide a good service for anyone using google voice call forwarding.
Call IDs where Google voice forwarded calls get flagged as “potential voice mail” from google before we added the button press:
call_6ec1719fabf913d03385ea3f952
call_dd3ca8060ec131e765f8b3e99e6
call_76a0c8cf1c473b0bd85c55109e5.
The best fix in my humble opinion:
I think the right fix to prevent Google Voice flagging retellAI as a potential “Voicemail” is to have an optional Delayed call pick up setting where the system would let it ring 1 time or wait a specified time in milliseconds before it pics up the call that is being forwarded. I am more than willing to help test something or work with anyone to resolve this.
CALL ID WHERE IT DOESNT SPEAK AFTER PRESS:
Since that is not currently available yet, here is a call where we created the workaround to make the agent Press 1 when google is requesting it and then the agent doesn’t speak right after the successful pressing 1 function is executed. You will see the agent stayed quiet and the user had to speak first..
call_1b6612634e043a43d5fb4cc88ae
I look forward to your recommendation and help.
potential alternate fixes:
In case you think it may be helpful, as for trying to make the agent talk after pressing 1, i have two ideas i was thinking of trying:
- maybe I can add a </> code function that immediatly after pressing 1 and would force it to say the begin message custom greeting stored.
I CONFIRMED THIS WORKS:
I added a prompt to call the press_digit and immediately also transfer to an identical copy agent it does say the greeting at that point. but this is not ideal.
in any case thank you again.
Leo
@supernova77 I’m checking this with the team and will get back to you as soon as I have an update.
Thank You
thank you, i just updated the ticket. please see my new update of what I temporarily did.
Hello @supernova77 Team reviewed call_1b6612634e043a43d5fb4cc88ae and can confirm the behavior. The agent detected the Google Voice screening prompt and press_digit executed successfully at 9.4 seconds, but no speech was generated until the caller said “Hello?” at 15.2 seconds. There was no telephony or SIP failure on that call, and the call lifecycle was otherwise normal.
For single-prompt and multi-prompt agents there is no equivalent to the Conversation Flow fix. press_digit does not expose a documented mechanism to force a follow-up turn after execution, and there is no functioning speak-after-execution behavior for this tool even though the field is present in your config. Speech after the digit press depends on the model continuing on its own, which is why prompt instructions alone are not reliable here.
Two options for your setup:
-
Keep the workaround you confirmed. Calling agent_transfer immediately after press_digit hands the call to the destination agent, which delivers its begin message on entry. Your later calls, call_521357d39c5634e445011ca009e and call_308d08606d48123416dca0d822b, show the greeting starting roughly one second after the digit press with no caller utterance required.
-
Move this use case to Conversation Flow, where a Press Digit node followed by a static text node produces the greeting deterministically after the digit press. Details are here: Press Digit Node - Retell AI
Your suggestion for an optional delayed call pickup setting, where the system waits a configurable interval before answering a forwarded call, has been submitted as a feature request.
Thank You
Thank you! I appreciate you guys looking into it.