I think I erased your last message. I’ll give the outbound a try
I believe it was:
call_2cc83184b42efa7e3ff02bf64f8
If not, I can try it again and send you a new call ID
Here’s the one I just tried
call_58933d47215abb7965ee29197cc
@VirtualAP escalated with team.
Thank you very much!
Hey @VirtualAP looked at call_58933d47215abb7965ee29197cc. The retest actually hit the same agent version (v68) with the same hardcoded transfer destination +1 787 587 6789 (Puerto Rico), so it failed for the same reason as the first call. I can see newer versions on this agent already.
One thing to do:
- On the phone number
+1 575 587 7857, update the inbound agent version to the published one. Right now it’s pinned to v68. You can do this in Dashboard → Phone Numbers → select the number → change the agent version dropdown.
Thank You
Hi @mark1 I tried changing the agent’s version and still no transfer is possible
It’s hard to pinpoint without a bit more detail, but there are a few things that trip most people up.
First, transfers don’t work from the dashboard test or a web call. You need to call your agent from an actual phone to test it, so if you’ve only been testing in the browser, that could be the whole issue.
Also double check that your transfer number is in E.164 format, like +14155551234, with no spaces, dashes, or parentheses.
Another common one is that the prompt never tells the agent when to use the tool. Adding transfer_call isn’t enough on its own. Try adding a clear line to your prompt like “If the caller asks to speak to a person, call the transfer_call function,” and make sure the tool’s description explains when it should be used too.
If you imported your own number through Twilio or another SIP trunk, call transfer also has to be enabled on the trunk. Numbers bought directly through Retell don’t need this.
Hey @VirtualAP
We looked at the most recent calls on this agent to confirm what happened after the version was changed:
On the first retest at 17:09 UTC on September 29 (call_650967a036b857f24e032d6e677), the call was still served by v113 and the Transfer Call tool failed in roughly 7 milliseconds with the same “Transfer destination is not supported” error, just like before.
On the second call at 17:21 UTC that same day (call_d29e134b1a434b453052e62bb77), the version change did take effect and the call was served by v114, but the caller never actually requested a transfer, so Transfer Call was never invoked on that call.
That is probably why it felt like “nothing works”: the first attempt failed on v113, and the next call did not reach the transfer step.
The underlying issue is unchanged, as mentioned earlier: on both v113 and v114, the Transfer Call destination is a Puerto Rico number.
Best Regards.