Voicemail Detection Integration for Contact Centers

Written by: Matt Beucler, CEO, Plura AI

Key Voicemail Detection Takeaways for High-Volume Teams

• Voicemail detection classifies answered calls as human or machine within seconds and helps AI predictive dialers stay within the FCC’s 3% abandoned-call limit.
• Plura AI performs detection on its own FCC-licensed carrier with SHAKEN/STIR verification, real-time DNC scrubbing, and stateful cross-channel memory.¹
• Async AMD lets AI voice agents begin speaking immediately while detection runs in the background, which removes dead air and preserves conversation context.
• Key configuration parameters, including speech threshold, speech-end threshold, beep band, and silence timeout, must be tuned per campaign type to keep false positives under 5%.³
• Experience carrier-grade voicemail detection and cross-channel memory in your own stack by talking with Plura AI.

How Answering Machine Detection Works in Contact Centers

Answering machine detection (AMD) analyzes the first seconds of audio after a call connects and classifies the answer as a live human or a machine. Two primary signal groups drive this classification: tone detection and voice activity detection (VAD).

Tone detection identifies machine beeps, fax tones, busy tones, and in-band DTMF signals. VAD isolates human speech from background noise and measures temporal patterns including rhythm, silence gaps, and speech energy. Traditional rule-based AMD systems such as Asterisk’s AMD() function apply fixed thresholds for initial silence, greeting length, word count, and after-greeting silence to produce a binary human or machine verdict.⁴

Carrier-owned detection reduces dead air compared with third-party CPaaS wrappers because the classification runs at the origination layer, not through an intermediary API. Manual voicemail detection wastes several seconds per call on average. AMD systems recover that time at scale, which can translate into substantial productivity gains depending on team size, dial rates, voicemail incidence, and agent costs.

Industry data shows that a large percentage of outbound sales calls go to voicemail. Machine detection therefore becomes a core operational requirement for high-volume outbound programs.

Voicemail Detection for AI Voice Agents

AI voice agents introduce a classification challenge that static dialers do not face. The agent may already be speaking by the time AMD returns its verdict. While traditional dialers can wait for AMD results before connecting agents, AI voice agents must handle mid-call reclassification cleanly.

Plura AI voicemail detection runs asynchronously on its FCC-licensed carrier, so the AI voice agent can begin speaking immediately while detection completes in the background. This approach removes dead air for live humans and keeps the experience natural.

When classification occurs mid-call, Plura’s stateful conversation database preserves the full context of what was said before the voicemail verdict arrived. If the call is reclassified as machine after the agent has started speaking, the session tears down the live connection and routes to a compliant voicemail drop without losing the lead record. If the call is confirmed human, the agent continues with full memory of the opening exchange.

This cross-channel memory extends beyond a single call. An AI voice agent that texted a lead at 9 a.m. picks up the noon call already knowing what was discussed, what offers were made, and what objections were raised. Competing tools typically do not preserve that context across channels by default.

Book a live demo with Plura to see stateful voicemail detection and cross-channel memory in a production environment.

Configuring Voicemail Detection for Predictive Dialers

Production configuration for a predictive dialer AMD integration follows a consistent sequence across providers. The steps below reflect Plura’s REST-based configuration flow.

1. Set async_amd to true to prevent dead air on live answers while detection runs in the background.
2. Configure machine_detection to Enable for predictive dialer use cases where the goal is connecting live humans to agents immediately. Use DetectMessageEnd only when the goal is leaving a complete voicemail message after the greeting finishes.
3. Set speech_threshold to 2000 ms for residential and mobile campaigns. Raise to 2400–3000 ms for B2B campaigns where business greetings are longer.
4. Set speech_end_threshold to 1400 ms as a starting baseline. Raise to 2000–3000 ms if false positives on paused voicemail greetings are high.
5. Configure the AMD webhook endpoint to receive AnsweredBy values and branch call routing accordingly.
6. Enable beep detection in the 800–1200 Hz band with a 150 ms minimum duration for voicemail drop campaigns.
7. Set machine_detection_silence_timeout to 3000 ms to return unknown when no speech or machine signal appears within the window, which avoids premature classification.

A minimal Plura REST call that enables async AMD looks like this:

POST /v1/calls { "to": "+15551234567", "from": "+15559876543", "machine_detection": "Enable", "async_amd": true, "async_amd_status_callback": "https://yourapp.com/amd-result", "machine_detection_speech_threshold": 2000, "machine_detection_speech_end_threshold": 1400, "machine_detection_silence_timeout": 3000 } 

Twilio AMD Modes and Thresholds

Twilio’s AMD exposes two primary operational modes with distinct webhook payloads.⁴

MachineDetection=Enable returns AnsweredBy quickly with values including human, machine_start, fax, or unknown. This mode suits predictive dialers where the goal is connecting live humans to agents with minimal delay. Twilio AMD returns results within several seconds after call answer using default configuration values.

MachineDetection=DetectMessageEnd waits for the full greeting to finish and returns more specific labels: machine_end_beep, machine_end_silence, or machine_end_other. This mode applies when the goal is leaving a complete voicemail message after the greeting ends. The MachineDetectionTimeout parameter applies only in this mode, with a default of 30 seconds.

Twilio’s parameter naming differs slightly from Plura’s but follows the same logic. The provider reports that its customers often adjust these baseline values 10–15% lower for mobile-heavy campaigns to account for shorter greetings.

Voicemail Detection Configuration Across Providers

Provider	Mode	Key Parameters	Webhook Payload Example
Plura AI	Async Enable / DetectMessageEnd	speech_threshold: 2000 ms, speech_end_threshold: 1400 ms, async_amd: true, beep band: 800–1200 Hz	{"AnsweredBy": "human", "CallSid": "CA..."}
Twilio	Enable / DetectMessageEnd	MachineDetectionSpeechThreshold: 1800–2000 ms, MachineDetectionSpeechEndThreshold: 1400–1500 ms, MachineDetectionSilenceTimeout: 3000 ms	{"AnsweredBy": "machine_end_beep", "CallSid": "CA..."}
Retell	Provider-delegated AMD	machineDetectionTimeout: 30 s, machineDetectionSpeechThreshold: 2400, machineDetectionSpeechEndThreshold: 1200	{"call_status": "voicemail", "call_id": "..."}
ElevenLabs	Transcript-based secondary detection	Detection window: 2–4 s, AI/ML model on Mel spectrogram, confidence threshold: 0.65	{"voicemail_detected": true, "confidence": 0.91}
RingCentral	Event-driven via webhook polling	Native webhooks where emitted, virtual webhooks via polling for providers without native event support	{"eventType": "CallConnected", "telephonyStatus": "Voicemail"}

AMD Webhook Handling Examples

Production webhook handling must account for all four AMD outcome states. The following JSON examples reflect standard payload structures for each outcome, with retry logic for unknown results.

Human detection:

POST /amd-result { "CallSid": "CA1234567890abcdef", "AnsweredBy": "human", "CallStatus": "in-progress" } // Action: Connect call to AI voice agent or live agent queue 

Machine start detection:

POST /amd-result { "CallSid": "CA1234567890abcdef", "AnsweredBy": "machine_start", "CallStatus": "in-progress" } // Action: Hang up immediately or wait for machine_end_beep if DetectMessageEnd mode 

Machine end beep detection:

POST /amd-result { "CallSid": "CA1234567890abcdef", "AnsweredBy": "machine_end_beep", "CallStatus": "in-progress" } // Action: Play pre-recorded voicemail drop (15-20 seconds), then hang up 

Unknown result with retry logic:

POST /amd-result { "CallSid": "CA1234567890abcdef", "AnsweredBy": "unknown", "CallStatus": "in-progress" } // Action: Treat as human (bias toward live connection), log for review // Retry: If call persists beyond 8 seconds with no speech, reclassify as machine // Max retries: 1 secondary classification attempt before defaulting to human 

Voicemail Detection Best Practices for AI Agents

1. Bias uncertain results toward human. Uncertain AMD results should route to an agent to avoid abandoned-call violations under the FCC’s 3% per-campaign limit. A false positive that hangs up on a live person is more damaging than a false negative that wastes a few seconds of agent time.
2. Tune parameters per campaign, not globally. B2B campaigns require longer human-greeting tolerance than B2C campaigns because business greetings are often longer. Apply separate threshold profiles for residential, mobile, and business line campaigns.
3. Conduct weekly recording audits. Weekly audits of machine-dispositioned call recordings identify threshold drift and carrier-specific anomalies before they compound into compliance exposure.
4. Apply a 2-second post-answer buffer. A 2–4 second AMD detection window balances classification reliability against live-caller hang-up risk. Starting detection immediately after answer increases false positives on calls where the human pauses before speaking.
5. Keep voicemail drop messages under 20 seconds. Shorter voicemails often achieve higher callback rates compared to longer messages. A 15–20 second message that names the prospect, states one specific reason for calling, and provides a direct callback number is widely considered effective.
6. Use async AMD for all AI voice agent deployments. Asynchronous detection allows the AI agent to begin speaking immediately while analysis runs in the background. This setup enables graceful mid-conversation transitions if voicemail is later identified.

Compare plans and rates side by side at plura.ai/pricing to see how Plura’s carrier-owned AMD integrates with your outbound stack.

False-Positive Control and Beep-Detection Timing

False positives in voicemail detection occur when a live human is classified as a machine and the call is dropped or routed to a voicemail drop. Teams should keep the false-positive rate under 5% and run weekly reviews of call recordings to confirm that the threshold holds across carriers and campaign types.

Symptom	Likely Cause	Tuning Action
High false positives (live callers dropped)	SpeechThreshold too low, detection window too short	Increase startAtSeconds to 3–4 s and raise speechThreshold to 3000–4000 ms
High false negatives (voicemails reaching agents)	SpeechThreshold too high, greeting length tolerance too wide	Decrease speechThreshold or increase check frequency (frequencySeconds minimum 2.5 s)
Beep not detected on voicemail systems	Frequency band too narrow or minimum duration too long	Widen band to 500–1200 Hz and reduce minimum duration to 100 ms
DTMF tones triggering false machine classifications	IVR keypad tones within beep detection band	Route early DTMF to a separate IVR state and raise minimum beep duration to 250 ms

Beep detection targets the characteristic tone that voicemail systems play at the end of their greeting. This tone typically falls in the 800–1200 Hz range and lasts 200–500 ms. For production deployments, a -28 dB detection threshold with a 100 ms minimum duration covers most North American carrier patterns. O2’s double-beep pattern requires a 250 ms minimum to avoid splitting the signal into two separate detections.

Carrier-specific timing variations are material. EE/BT Mobile voicemail greetings run 3.5–5.0 seconds with 1,000 Hz beeps. Vodafone runs 2.8–4.2 seconds with 1,050 Hz beeps. O2 runs 3.0–4.5 seconds with 900 Hz double beeps. Default settings applied to international traffic can produce elevated misclassification rates. Per-carrier threshold profiles are the production standard for any multi-market outbound operation.

Common AMD Pitfalls in Production

Four technical failure modes account for most AMD accuracy problems in production deployments.

Beep timing mismatches. AMD systems configured for a 5-second analysis window miss beeps that arrive at 6–8 seconds on carriers with longer greetings. Setting beepMaxAwaitSeconds to 25–30 seconds prevents premature message playback that gets cut off before the recording tone.

Compressed codec loss. Compressed codecs such as G.729 discard waveform detail and raise AMD false-positive rates. Native G.711 pass-through without carrier-side transcoding preserves the full 64 kbps audio stream required for accurate spectral analysis. Teams should verify codec negotiation at the SIP trunk level before tuning AMD parameters.

Late 200 OK signaling. Sloppy answer supervision, late 200 OK signaling, or ringback bleeding into the answered stream shifts audio relative to AMD timers and corrupts classification measurements. This issue typically occurs at the carrier level and does not resolve through threshold tuning alone. It requires SIP signaling inspection at the trunk.

Compliance impact on abandoned-call calculations. The FCC defines an abandoned call as one answered by a live person where no agent connects within 2 seconds of the person’s completed greeting.² AMD false positives that hang up on live humans count toward this limit. Operations running near the threshold should audit AMD accuracy weekly and bias uncertain results toward human to maintain headroom.

Plura Voicemail Detection in Your Outbound Stack

Plura voicemail detection runs on its own FCC-licensed carrier rather than a third-party CPaaS wrapper. SHAKEN/STIR caller ID verification authenticates every outbound call at the carrier level, and real-time DNC scrubbing checks every number before dial. The following checklist covers integration steps specific to Plura’s platform.

1. Confirm FCC-licensed carrier routing is active on your Plura account. Voice originates on Plura’s domestic infrastructure, not a third-party CPaaS, which keeps AMD and caller ID verification at the carrier layer.
2. Enable SHAKEN/STIR caller ID verification on all outbound campaigns via the Plura compliance dashboard so every call presents a verified identity where supported.¹
3. Configure real-time DNC scrubbing against federal and state DNC registries before enabling the AI predictive dialer. This step reduces the risk that blocked numbers enter your outbound rotation.
4. Set async_amd: true and machine_detection: Enable in your Plura outbound call configuration to activate carrier-level AMD for live-answer campaigns.
5. Point async_amd_status_callback to your AMD webhook endpoint and implement branching logic for human, machine_start, machine_end_beep, and unknown outcomes so each result follows a clear path.
6. Configure the stateful conversation database to log AMD outcome, call timestamp, and lead token on every dial so cross-channel context is preserved for follow-up via AI SMS or AI voice agent.
7. Apply per-campaign threshold profiles using the parameter table above. Avoid a single global default across residential, mobile, and B2B campaigns.
8. Enable the Plura compliance engine to support TCPA posture, DNC handling, SOC 2 controls, HIPAA-related workflows, ISO-aligned processes, and GDPR-related data handling on outbound contact strategies.¹ Customers remain responsible for their own compliance obligations and certifications.
9. Schedule weekly AMD recording audits using Plura’s conversation intelligence layer to verify that the false-positive rate stays under 5% and that carrier behavior has not shifted.
10. Review retry logic and limit voicemail drop attempts to three per campaign with minimum 4-hour spacing between attempts 1 and 2, and 24-hour spacing between attempts 2 and 3.

Plura’s power dialer and multi-line dialing capabilities share the same stateful database, so AMD outcomes feed directly into the lead prioritization model for subsequent dials. Operators replacing legacy systems such as a Vici Dial alternative inherit this cross-channel memory without additional integration work.⁴

Review the full platform capabilities and per-minute rates at plura.ai/pricing.

Frequently Asked Questions

What is AMD in calling?

AMD stands for answering machine detection. A predictive dialer or AI voice agent analyzes the first seconds of audio after a call connects and classifies the answer as a live human or a machine. AMD systems measure initial silence, greeting length, word count, speech energy patterns, and tone presence to produce a classification. The result determines whether the call routes to a live agent, connects to an AI voice agent, or triggers a voicemail drop. Modern AMD implementations combine audio signal analysis, human speech pattern recognition, timing characteristics, and carrier signal detection to reach detection accuracy above 95%.³

How do I reduce false positives in voicemail detection?

False positives occur when a live human is classified as a machine and the call is dropped or routed to a voicemail drop. The primary tuning levers are the speech threshold and the detection window. Raising the speech threshold to 3000–4000 ms accommodates longer human greetings such as those from business receptionists. Increasing the detection start delay to 3–4 seconds allows humans who pause before speaking to register as live. Biasing unknown results toward human rather than machine prevents borderline cases from counting against the FCC’s 3% abandoned-call limit. Weekly recording audits of machine-dispositioned calls identify carrier-specific patterns that require separate threshold profiles.

What is the difference between MachineDetection=Enable and DetectMessageEnd?

MachineDetection=Enable returns an AnsweredBy result quickly with values such as human, machine_start, fax, or unknown. This mode suits predictive dialers where the goal is connecting live humans to agents with minimal delay. MachineDetection=DetectMessageEnd waits for the full voicemail greeting to finish and returns more specific labels such as machine_end_beep, machine_end_silence, or machine_end_other. This mode applies when the goal is leaving a complete voicemail message after the greeting ends. The MachineDetectionTimeout parameter applies only in DetectMessageEnd mode and defaults to 30 seconds.

How does beep detection work in voicemail detection systems?

Beep detection identifies the characteristic tone that voicemail systems play at the end of their greeting, which signals that recording has begun. This tone typically falls in the 800–1200 Hz frequency range and lasts 200–500 ms. The detection system monitors the audio stream for energy in this band above a configured threshold, typically around -28 dB, for at least the minimum duration. When a beep is confirmed, the system triggers the voicemail drop message. Carrier-specific variations affect beep frequency and duration. Some carriers use double-beep patterns that require a longer minimum duration setting to avoid splitting the signal into two separate detections.

What compliance considerations apply to automated voicemail drops?

The FCC’s February 2024 Declaratory Ruling described AI-generated voices as an artificial or prerecorded voice under the Telephone Consumer Protection Act (TCPA).² Automated voicemail drops triggered by AMD therefore fall within the same general TCPA framework as other prerecorded calls. The FCC also stated in November 2022 that ringless voicemail deposits to wireless phones constitute a call under the TCPA.² Campaigns using voicemail detection to trigger automated drops should be reviewed against federal TCPA requirements, the National Do Not Call Registry, and applicable state laws, which vary by state. Organizations should consult qualified legal counsel to evaluate the specific consent, disclosure, and calling-hour requirements that apply to their campaigns.

How does async AMD prevent dead air on live calls?

Synchronous AMD blocks call progression until analysis completes, typically 2–5 seconds, which creates silence that live callers often interpret as a robocall and hang up. Asynchronous AMD allows the

---