Hello retell team! In recent weeks we’ve noticed an uptick in the agent misspelling caller info even when it’s clearly spelled out by the caller. For example, the caller will state their name as “Anallely, a-n-a-l-l-e-l-y” and the agent will confirm then capture Anayeli in the following extract variable node, ignoring the callers spelling.
This especially happens during email capture, which is troublesome for sending automated messages after the call ends.
Hey @george1 we pulled call_2965d816879e5c901f122e531ac and the agent config:
The caller spelled a-n-a-l-l-e-l-y and the letters came through cleanly as discrete tokens on the ASR side. The miss is at the Extract Name dynamic-variable step: the LLM normalized those letters into the phonetically similar dictionary name ‘Anayeli’, and that propagated into the email (cortezanayeli38@gmail.com). The Collect Name readback then used the dictionary form (‘A N A Y E L I’), so the caller’s ‘Yes’ confirmed the wrong spelling rather than the letters they actually spoke.
This is a known LLM behavior when a spelled-out form is less common than a similar dictionary word — the model treats the spelled letters as a hint rather than as the literal target.
What we’d suggest changing (in priority order):
Primary fix — Extract Name variable description. The strongest lever is the description on the Extract Name extract_dynamic_variables node. It needs to explicitly tell the LLM that when the caller spells letters, the captured value must be those exact letters concatenated (e.g., ‘a-n-a-l-l-e-l-y’ → ‘Anallely’), not a phonetically similar dictionary name. Something like: “If the caller spells their name letter-by-letter, capture the exact sequence of letters they spoke as the name. Do not substitute a phonetically similar dictionary name. If the caller says both a spoken form and a spelling, the spelling is authoritative.” We didn’t pull the current description text in-run, so the edit should be applied to whatever it currently says.
Collect Name readback. Update the Collect Name node prompt so the readback uses the exact letter sequence the caller just spelled and asks for confirmation of that sequence specifically — not a re-spelling of the normalized form. Same change on Collect Email for the local-part.
Hardening levers (do not address the primary mechanism, but reduce surface area):
language is currently multi. If your traffic is predominantly English, en routes ASR/TTS through English-tuned models. ASR was clean on this call, so this is hedging, not the fix.
Boosted Keywords (Realtime Transcription Settings) operates on the ASR layer. Since ASR transcribed the letters correctly here, boosting NATO phonetics wouldn’t have changed this specific outcome — only worth doing if you also see ASR-side letter misreads on other calls.