Retell Voicemail Detection Not Working? 6 Real Causes

The Retell community forum has a steady drip of threads with this title. Most end with a support rep writing "escalated to the team" and no follow-up. So here's the short version, matched to the symptom you're probably seeing:

Check them in that order. The first one is a two-minute API call and it explained every real voicemail in my own data.

I pulled every call from my Retell account with POST /v2/list-calls, kept the outbound ones, and grepped the caller side of each transcript for greetings like "leave a message," "not available" and "buzón de voz." The calls span 18 agents: client builds for a personal injury intake team and a spa, my own Orus assistant, and a lot of tests.

Zero calls ended as voicemail_reached. That sounds like a broken detector. It wasn't. The two calls that really reached a mailbox both went through my Orus assistant, an agent I created over the API, and its voicemail_option was null. Detection never ran.

One of them is the best argument I have for turning it on. The greeting said, in Spanish, that the call had been forwarded to voicemail. My agent then read its own task instruction into a family member's mailbox: "Call him and tell him this joke, say it in a fun and friendly way." Word for word, the prompt, recorded forever. It cost 7 cents. The embarrassment was free.

One more trap: call_analysis.in_voicemail was true on both calls. That flag comes from post-call analysis of the transcript. It tells you the call landed in voicemail after the fact. It doesn't mean live detection fired, so don't use it to grade your detector. Count disconnection_reason instead.

Per Retell's voicemail docs, new blank agents made in the dashboard start with detection on and "Hang up if reaching voicemail" selected. That default doesn't apply to existing agents, imported agents, transfer agents, or anything created through the API. In the API reference, setting voicemail_option to null disables detection, and null is what you get if you never send it.

Check it in one call:

curl -s https://api.retellai.com/get-agent/$AGENT_ID \
  -H "Authorization: Bearer $RETELL_API_KEY" | jq '.voicemail_option, .ivr_option'

Two nulls means you have no voicemail handling and no IVR handling. Here's what I set now:

{
  "voicemail_option": {
    "action": {
      "type": "static_text",
      "text": "Hi {{first_name}}, it's Sophia with {{company}}, returning your request. Call us back at {{callback_number}}. Again, {{callback_number}}."
    }
  },
  "ivr_option": {
    "action": { "type": "hangup" }
  },
  "begin_message_delay_ms": 1500,
  "ring_duration_ms": 35000
}

The action can be hangup, static_text (spoken as written, with dynamic variables), or prompt (the LLM writes the message from your instructions). The API spec also lists a bridge_transfer type the docs don't describe yet, and an optional detection_prompt of up to 2,000 characters if you want to redefine what counts as voicemail. Remember to publish the version your phone number points at. You can also override everything per call through agent_override.agent on Create Phone Call, which is handy for A/B testing a message.

Because you told it to speak first. Detection works off what it hears, and if the agent launches its opener the instant the line connects, it's talking over the very audio the classifier needs. A July 2026 forum thread documents it well: a conversation-flow agent ran its whole pitch into mailboxes, and adding a detection_promptdidn't help. What did help was a two-word first line ("Hey [name]!") and a pause. Detection started firing reliably.

The cost was real people. The pause felt dead, and one test caller hung up after about seven seconds. That's the trade-off, and I don't think there's a setting that removes it. You're choosing who gets the awkward moment.

My default for outbound: let the user speak first.People answering a cell phone say "hello?" within a second, and that word is the best signal the detector will ever get. If you must speak first, use begin_message_delay_ms(0 to 5,000) and keep it near 1,000 to 1,500. If the pause makes your humans bail, that's the same problem as an agent that keeps interrupting, just in reverse.

A lot. In an April 2026 thread, an agent set to en-USwas calling Spanish (+34) numbers and kept missing voicemails. Retell support's explanation: detection relies on speech recognition to transcribe the greeting, and an English model couldn't transcribe Spanish greetings, so the classifier had no usable text.

If failures cluster on one country code or one slice of your list, check language before anything else. For bilingual US lists (I build a lot of English/Spanish flows in Texas), either split agents by language or turn on multilingual so a Spanish carrier greeting still turns into words.

Because a phone menu isn't voicemail. Retell classifies IVRs separately, and a call it labels as IVR won't trigger the voicemail hangup. You need ivr_option with a hangup action (it ends the call with ivr_reached).

My audit had one of these and it's a good illustration. A conversation-flow agent dialed a restaurant line and got the "press one to speak with a team member" menu. The LLM replied with the text "[Pressing 1 to reach a team member. Waiting quietly...]". It had no DTMF tool, so nothing was pressed. The menu said "Nothing has been selected" and started over. The call ran 52 seconds and died on inactivity, 12.8 cents for nothing.

Writing "[Pressing 1]" is not pressing 1. If you want to navigate menus, give the agent a real press-digit capability. If you don't, turn IVR hangup on. Same rule I use for warm transfers: a voicemail reached after a transfer is outside detection, because the 3-minute window starts when the first call connects and time spent in menus or talking to a person eats into it.

The "leave a message" action waits for the agent's turn to speak, and there's no documented "wait for the beep" option. On long custom greetings the turn can come early. In the July thread, messages started five to six seconds before the beep, so the mailbox kept only the back half.

Write for that. Put nothing important in the first sentence, then say the name and the callback number, then repeat the number. That's why my static_text above says the number twice. I also prefer static_text over promptfor this: a generated message is one more place for the model to improvise, and I've already heard what my agent improvises into a mailbox.

This one surprised me. On the busiest lead follow-up agent in my account, 74 of 78 calls ended as dial_no_answer with zero connected seconds. That agent had voicemail hangup configured, and it never fired, because nothing ever answered.

The reason is ring_duration_ms. It defaults to 30,000 (30 seconds), accepts 5,000 to 300,000, and covers both outbound ring time and transfer ring time. Most US mobile lines roll to voicemail somewhere around 20 to 30 seconds of ringing, though it varies by carrier and by each person's own setting. With a 30-second timer you're right on the edge, so plenty of calls can end just before a mailbox would have picked up.

So decide on purpose.If voicemails are worthless for your offer, shorten the ring to around 20 seconds and retry later; you'll skip most mailboxes and pay nothing for them. If a message is the point (appointment reminders, warm callbacks), push it to 35 or 40 seconds and let detection handle the rest. Either way, the ring timer is part of your voicemail strategy whether you set it or not.

The last bucket is plain silence. Four test calls on a spa agent connected, picked up about three seconds of audio on the caller channel (I checked the recordings with ffmpeg), then nothing for close to a minute. No words transcribed, no detection, and the agent kept asking "are you still there?" until inactivityended it. I can't tell you if those were people, short greetings or carrier screens. Neither could the detector. For outbound, lower end_call_after_silence_ms(default is 10 minutes, minimum 10 seconds) to something like 20 seconds so silent calls don't run up minutes.

Web calls can simulate a greeting, but they never reach a real mailbox or a real menu, so do the real thing:

1. Call three of your own phones with the call declined: one iPhone, one Android, one landline or Google Voice.
2. Set one with a custom recorded greeting and leave one on the carrier default.
3. Call a business with a known IVR, like a restaurant's main line.
4. Repeat each in the other language your list uses.
5. Pull the calls and check disconnection_reason: you want voicemail_reached and ivr_reached, and a recording where the message lands after the beep.

Then run the same audit I did on live traffic every week. A detector that worked in testing and shows zero voicemail_reachedin production is the signal to go back to the top of the table. If you're still setting up the basics, my Retell AI setup guide and the roofing outbound build cover the rest of the agent config.

How I checked this: call counts, outcomes, costs and agent settings come from my own Retell account through the API on October 14, 2026, covering outbound calls from February 9 to August 11, 2026. Field names, ranges and defaults are from Retell's voicemail guide and API reference read the same day. Forum quotes are user reports, not official docs.