| Can you clarify what capabilities are available in the staging environment, and how closely it mirrors production for testing purposes? |
|---|
| Backchanneling / Agent Speech Quality |
| We’ve noticed the agent uses filler language (e.g., “um,” “uhh”) quite frequently, which makes interactions sound unnatural. Are there controls or configurations available to reduce or optimize this behavior? |
| Voicemail Detection Accuracy |
| We currently have voicemail detection enabled, but it does not appear to be fully reliable. In several cases where a voicemail is reached, the call ends with agent_hangup or user_hangup. |
| Can you provide examples or guidance on how voicemail detection outcomes should be handled and validated? |
| Scalable Solution Feedback |
| We’ve designed a scalable approach for our implementation. Can we walk through our solution with your team to get feedback and identify any opportunities for improvement or optimization? |
| API-Based Testing in Staging |
| Is it possible to execute and validate staging tests via API, specifically using conversation flow or response engine configurations? If so, what is the recommended approach? |
| Transfer Agent & IVR Handling |
| For transfer scenarios involving IVR systems, we are currently using a workaround. Are there recommended best practices or native solutions for handling IVR navigation more effectively? |
Hi Kkean,
Great questions. Here is what I have found when testing agents and then sending them into production.
- Yes, you can toggle this setting on and off so that there are no filler words used. Where you find it depends on the agent type that you are setting up.
- When conducting outbound and facing voicemail boxes, you can write into your system/global prompt the different voicemail queues and when to exit. The auto detection might not catch everything or know how to navigate past options such as a prerecorded message or an IVR system.
- I have found that the transcriptions are fairly accurate. You can use a post processing system in order to figure out your rate of success when dealing with voicemails. Any SOTA LLM will work just fine!
- I am happy to discuss with you if you’d like
- Yes, it is possible to conduct backtesting using the API. First, you have to create the test cases and success metrics, then you can push those to the API and have it run your tests and send back results. I would again recommend using an LLM in order to create the test cases as well as the scripts that communicate with the API.
- There is a native button pressing feature that Retell has integrated in order to navigate IVR. You can also connect custom scripts to help your agent navigate this most effectively.
Happy to answer any follow ups!
Thanks,
Buddy
Im wanting to set up trigger based sms outreach. For example: if customer books an appointment on calender or crm, then 1 hour before send a appointment reminder, after appointment ask for google reveiw. Is this possible by adding sms to the voice agent or would I need to create a chat agent?
You would need to add sms to your phone number and then you can add that node. Another alternative is to use a third party texting service and add a tool that calls a webhook to make the text send from the third party service.
Hey, good question. The voice agent’s SMS tool only works during a live call, so it is not the right fit for scheduled outreach.
For appointment reminders and review requests, the trigger and timing live in an automation tool (n8n, Make, Zapier), not in a Retell agent. Your calendar or CRM fires the trigger, the automation waits until the right moment, then sends the SMS. The SMS itself can go via Twilio directly, or via Retell’s Create Outbound SMS API if you want it inside Retell.
You only need a chat agent if you want AI to handle the replies (e.g. customer texts back “reschedule to Thursday”). For pure one-way reminders and review prompts, no agent is needed.
Two quick heads up: Retell SMS is US numbers only right now, and sending from your own number needs A2P approval, which usually takes 2 to 3 weeks.
Russell
Hi there,
Thank you for the detailed questions. We reviewed the current Retell capabilities, and below is a concise overview of what is supported and the recommended approach.
1. Staging Environment & Production Parity
Retell supports Agent Versioning and Environment Tags, including staging and prod. A specific agent version can be assigned to each environment, and environment-specific dynamic variables can be configured without duplicating the agent. This is useful for testing changes before promoting them to production. (Retell AI)
For strict isolation of telephony resources, billing, concurrency, and call data, we would recommend confirming the appropriate workspace setup with Retell Support rather than assuming the staging tag provides complete infrastructure isolation.
2. Backchanneling / Filler Words
Frequent “um,” “uh,” or similar sounds can generally be reduced by optimizing the agent’s voice/delivery instructions and avoiding prompts that encourage excessive hesitation or overly casual speech.
For example:
Speak naturally but clearly. Avoid unnecessary filler words such as “um,” “uh,” “you know,” or similar hesitation sounds. Keep responses concise and direct.
We would also recommend testing different supported voices if the behavior continues.
3. Voicemail Detection
Retell provides a dedicated voicemail_reached disconnection reason when voicemail is detected. agent_hangup and user_hangup simply indicate who/what ended the call and should not automatically be treated as confirmed voicemail outcomes. (Retell AI)
Retell also handles IVR detection separately, with an ivr_reached outcome. If the desired behavior is to terminate when an IVR is detected, IVR hangup should be configured accordingly. Voicemail and IVR detection currently operate during the first three minutes of the call. (Retell AI)
For validation, we recommend monitoring the call’s disconnection_reason through the Dashboard/API and comparing it with the actual call recording/transcript.
4. Scalable Architecture Review
Absolutely. We would be happy to review the proposed architecture and provide feedback around concurrency, telephony, webhooks, custom functions, and overall scalability.
For a detailed architecture review, the Retell Support/Solutions Engineering team would be the appropriate channel.
5. API-Based Staging Testing
Yes. Retell supports API-based testing.
For example, POST /v2/create-web-call can be used to create web calls programmatically. You can specify an agent version and, for Response Engine agents, pass dynamic variables. For Conversation Flow agents, you can also specify the starting node using current_node_id. (Retell AI)
This makes web calls a useful option for automated testing before running larger-scale phone-call tests.
Retell also provides an Agent Playground API that can resolve a specific agent version or environment tag, which can be useful for programmatic response testing. (Retell AI)
6. Transfer & IVR Handling
Retell provides native transfer functionality for phone calls, including cold transfer, warm transfer, and agentic warm transfer. Transfer destinations can be configured using phone numbers, SIP URIs, dynamic variables, and extensions. (Retell AI)
For external IVR systems, the appropriate approach depends on the specific IVR and telephony provider. If the current workaround involves sending DTMF digits after transfer, we would recommend reviewing the exact flow and SIP/telephony setup before replacing it with a native approach.
Overall, Retell provides the core capabilities needed for versioned staging, API-based testing, voicemail/IVR handling, and call transfers. The exact setup should be validated against your current telephony configuration and use case.
If you can share your current architecture or the specific IVR/voicemail flow that is causing issues, we can review it and suggest the most suitable approach.