@AI Evy Hi Retell Support, We're using warm transfers, and we’ve noticed that all failed transfers return the same generic tool result: {"status":"Transfer failed due to an error.. Please inform the customer that the transfer did not go through and offer to try again or assist them directly."} This happens whether the call is declined, reaches voicemail, or fails due to a technical issue. Issue: The main agent has no way to know why the transfer failed. We can't differentiate between voicemail, decline, or error in real time or in post-call analysis. This limits our ability to train agents and provide accurate responses to customers. Request: Could you provide a way to: Distinguish between failure types (declined, voicemail, error, etc.) Include the reason in the tool result or via webhook metadata, so agents can respond accordingly. This would help improve agent behavior and overall call experience. Thanks!Hi Retell Support, We're using warm transfers, and we’ve noticed that all failed transfers return the same generic tool result: {"status":"Transfer failed due to an error.. Please inform the customer that the transfer did not go through and offer to try again or assist them directly."} This happens whether the call is declined, reaches voicemail, or fails due to a technical issue. Issue: The main agent has no way to know why the transfer failed. We can't differentiate between voicemail, decline, or error in real time or in post-call analysis. This limits our ability to train agents and provide accurate responses to customers. Request: Could you provide a way to: Distinguish between failure types (declined, voicemail, error, etc.) Include the reason in the tool result or via webhook metadata, so agents can respond accordingly. This would help improve agent behavior and overall call experience. Thanks!

Thanks for tagging me @Vako-SV. I'll look through relevant sources and get back to you shortly.

@AI Evy Hello Retell Support, I am building an agent that uses an Inbound Webhook (via Make.com) to inject dynamic data into the call. My webhook response passes a custom variable called department_ledger (containing a list of department names and their corresponding E.164 phone numbers for the current shift) into the dynamic_variables object. My Goal: I want to use the "Transfer Call" tool with Dynamic Routing to select the correct phone number from this variable, rather than hardcoding numbers in the tool definition. My Questions: Variable Access: Does the "Dynamic Routing" prompt in the Transfer Call tool have access to the dynamic_variables I passed via the inbound webhook? Can I reference {{department_ledger}} directly in that routing prompt? Prompt Logic: If I instruct the Dynamic Routing prompt to "Extract the phone number for the [Department] from the {{department_ledger}} variable and transfer the call," will it execute correctly? Best Practice: Is there a better way to dynamically pass a transfer destination (phone number) at runtime without the LLM hallucinating the number? Thank you for your help.

The LLM will parse the variable content and extract the appropriate number. ## 3. Best Practice to Avoid Hallucination To minimize the risk of the LLM hallucinating phone numbers: [(4) ]() - Use explicit trigger words and clear instructions in your prompt—list specific conditions that map to specific actions - Store the phone number in a dynamic variable before transfer and update it programmatically, then have the Call Transfer Node use that variable as the transfer target [(3) ]() - Ensure phone numbers are in E.164 format (e.g.,

+12137771234

) when setting the transfer target A more reliable approach is to use a custom function that looks up the department and returns the exact phone number, then stores it in a dynamic variable that the transfer node uses. This removes the LLM from the number selection process entirely.

@AI Evy You are a strict execution engine. Do not guess. Your ONLY source of truth is the variable: {{department_ledger}} INSTRUCTIONS: 1. Review the conversation history to find the specific Department Name the Agent just promised to transfer to (e.g., "I will connect you to HR"). 2. Search the {{department_ledger}} list for that exact Department Name. 3. Extract the E.164 phone number associated with that department. 4. Transfer the call to that exact phone number. CRITICAL: - If the ledger says "Status=Don't Transfer" for that department, DO NOT transfer. - If the phone number is missing, DO NOT transfer. - Only transfer if you find a valid "+1..." number. is this good prompt for transfer call tool if i use dynamic routing? if not which will be best?

Thanks for the follow-up, @Vako-SV. I'll get back to you soon.

@AI Evy I am experiencing a critical issue with the call_transfer (Warm Transfer) flow where the outbound transfer leg persists even after the caller (User) has hung up. This is resulting in "Ghost Calls" to our staff. The Scenario: Main Agent initiates a Warm Transfer to a Human Representative. While the transfer is ringing (or connecting), the User hangs up (Leg A disconnects). The Issue: The Agent continues to ring the Human Representative (Leg B). The Human Rep answers the call. The Transfer Agent is active but goes silent or unresponsive because the User is no longer there to be connected. The Evidence (Logs): Main Call ID (User Leg): call_e15b29aee3aeb034f4a566b12f2 Warm Transfer Call ID (Outbound Leg): call_0edeb5296493f2bc929bdcee Impact: Our Nursing and HR teams are answering calls from the AI, only to find dead air or a confused Agent. This is wasting staff time and billing for unnecessary minutes. Request: Please investigate why the Outbound Transfer Leg is not terminating immediately upon the Inbound User Leg's disconnection. We need a configuration change or a fix to ensure that if the User hangs up, the Transfer attempt is aborted instantly. We are using a Single Prompt setup for the Main Agent and a separate Single Prompt for the Transfer Agent. Looking forward to your fix. Thanks

Thanks for the follow-up, @Vako-SV. I'll get back to you soon.