Skip to main content

​
Turn on AMD and voicemail drop on a dialer campaign

The dialer can answer one question on every leg it dials — did a person pick up, or an answering machine? — and act on it before your agents ever hear a ring. With AMD (answering-machine detection) on, a machine landing is caught in the first seconds of the call: the leg hangs up (or plays a recorded message into the customer’s voicemail inbox) and the contact goes back to the retry pool. Your agents only ever get bridged to humans. This guide walks the full loop: what AMD can detect on Orbit, enabling it per campaign, attaching a voicemail-drop message, what happens on the call leg when the detector fires, where to read the outcomes, and how to tune sensitivity against a real sample of calls. Use it together with Launch an outbound dialer campaign (list prep, pacing, dispositions) and the dialer API reference (full parameter list).

​
1. What AMD does on Orbit

AMD runs on each dialed leg once the far end picks up. Every landing classifies into one of these outcomes: Three things fall out of the machine branches (everything except human, no_answer, and silence):
  • The attempt’s outcome is set to amd_detected, which buckets into your retry policy’s machine_silence entry — an AMD machine landing does not count against max_abandon_rate.
  • The contact flips back to pending and becomes eligible to re-dial after about four hours (a machine landing at 9am is often a human at 1pm); it does not consume a dial attempt from the contact’s attempt count.
  • If your workspace has webhook endpoints subscribed to call.hit_voicemail, one fires for every machine/screening/fax landing with the detected type, so downstream integrations can re-queue or log the landing without polling.
ios_call_screening and ios_live_voicemail matter on US consumer traffic: on iOS 17+ devices with Silence Unknown Callers on, the phone itself answers and screens — a greeting-only classifier would label that a connected human and bridge an agent to a leg nobody is on. Orbit’s detection surfaces it explicitly and treats it as non-human.

​
2. Enable AMD on a campaign

AMD is two fields on the campaign: amd_enabled turns the detector on, and amd_sensitivity sets how aggressive the machine classification is. Send them at create time:
Or flip it on for an existing campaign with PATCH /api/v1/dialer/campaigns/{id} and the same two fields. Sensitivity picks the confidence bar. Every machine classification arrives with a confidence score. amd_sensitivity sets the minimum score a machine result must clear before the dialer honors it — a result below the bar is treated as human and bridges normally, so the dialer always errs toward connecting a live agent rather than hanging up on a person. Leave amd_sensitivity unset and the campaign gets legacy behavior: every machine classification is honored regardless of confidence. If you set it, set amd_enabled: true too — sensitivity has no effect on a campaign where AMD is off. The trade-off you’re managing. Detection takes a moment of listening after pickup, so a human answer on an AMD campaign carries a short delay before the bridge completes — that’s the price of not bridging voicemails. Higher sensitivity shrinks the effective wait (it commits to “machine” sooner) but hangs up on some real people; lower sensitivity is safer for humans and tolerates a few machines reaching agents.

​
3. Attach a voicemail-drop message

A voicemail drop plays a recorded message into the customer’s voicemail inbox when AMD detects a machine, instead of hanging up silently. Attach it with voicemail_message_url on the campaign:
Asset requirements:
  • Publicly fetchable over HTTPS. The voice platform fetches the URL at call time — no auth headers, no signed URLs that expire mid-campaign. A plain CDN or object-storage public URL is the right home.
  • Audio format. Host a common format the voice platform can play (MP3 or WAV). Serve it with a matching Content-Type.
  • Length. Keep it tight — a complete, natural-sounding message in 20–30 seconds. It plays into the customer’s voicemail recording: identify yourself, state the purpose, and give a callback number. Anything essential in the first second can be lost under the beep, so lead naturally, not with your most important word.
Voicemail drop is for agent-driven campaigns only. Setting voicemail_message_url on an agentless campaign is rejected with 422 VOICEMAIL_DROP_FORBIDDEN_AGENTLESS — an agentless (broadcast) campaign already plays its message on every answer through broadcast_message_url, human detection or not. Use broadcast_message_url there; it covers the voicemail case too, because the broadcast plays after pickup regardless of what answered.

​
4. What happens on the leg when the detector fires

When detection completes, the platform answers with an instruction for the call leg, per outcome:
  • Human heard — the leg continues untouched and bridges to the agent. If the campaign records calls, a recording disclosure is spoken to the answered party first, then the bridge completes.
  • Machine confirmed — with a voicemail drop attached, the leg plays your audio into the voicemail inbox, then hangs up. Without one, it hangs up immediately.
  • Below the sensitivity bar — the leg is treated as human and bridges normally, even though the classifier leaned machine.
A worked human bridge (campaign records calls):
  1. Contact answers → detection identifies a human.
  2. The recording disclosure plays to the called party.
  3. The leg bridges to the next ready agent, and the campaign’s normal script/flow takes over.
A worked machine landing (drop attached):
  1. Voicemail greeting answers → detection identifies a machine at or above the sensitivity bar.
  2. The wait briefly overlaps the greeting; then your recorded message plays in full into the voicemail inbox.
  3. The leg hangs up; the attempt closes as amd_detected; the contact re-enters the retry pool.

​
5. Read the outcome of every attempt

Machine and human landings are observable from three surfaces:
  • Attempt outcome. AMD machine landings close the attempt with outcome: "amd_detected"; ring-outs close as no_answer. Per-attempt AMD detail (amd_result and amd_confidence) is also exposed on the direct-dial voice surface — GET /api/v1/voice/calls/{id}/amd returns the detection decision for a call you placed with amd: true on POST /voice/calls, and the call list items carry the same two fields.
  • Webhooks. Subscribe an endpoint to call.hit_voicemail and every machine, screening, or fax landing POSTs to your endpoint with the detected type, numbers, and timestamp — the signal to build a same-day redial or suppression flow on.
  • The live console. The campaign’s live stats (dialer live console) count machine landings in the disposition mix, so you can watch the machine share of a campaign as it dials.
And the compliance math: amd_detected lands in the retry policy’s machine_silence bucket and does not count as an abandoned call in max_abandon_rate terms — AMD hangups and abandoned calls are different things, and the abandon ceiling only watches the latter.

​
6. Tune sensitivity against a real sample

Start every campaign at medium, then tune from evidence:
  1. Run roughly 100 answered legs at medium.
  2. Listen to the false positives. A false positive is a call AMD classified as a machine but a human actually answered — those contacts got hung up on (or got the voicemail drop played at them). In a recording-enabled campaign, sample the recordings of amd_detected attempts and count how many were really people.
  3. Act on the asymmetry:
    • False positive cost — a real human hears a machine hangup or a voicemail message spoken at them. For sales outreach this is the expensive mistake: you burned a warm answer. If your sample shows real humans in the amd_detected bucket, drop to low.
    • False negative cost — a real voicemail box bridges to an agent (or, unattended, plays your message into the void). The cost is seconds of agent time or an AI turn. If machines are still bridging through at medium, step to high.
  4. Re-sample after each change — sensitivity shifts interact with your audience’s carrier mix and iOS share, so re-check the same 100-call sample after you move the setting.
Consumer-heavy US lists with a large iPhone share should expect more ios_call_screening/ios_live_voicemail landings; those are always handled as non-human regardless of sensitivity, so they don’t factor into the bar.

​
7. Compliance: AMD hangups are not abandons

AMD’s auto-hangup on a machine landing is separate from the TCPA abandonment rules — the abandon-rate ceiling (3% over 30 days) measures answered-live calls where no agent connected, not calls the platform hung up after detecting a machine. The voicemail drop itself is a prerecorded-message delivery and travels under your campaign’s telemarketing consent posture like any prerecorded call: the contact list must carry the right opt-in for the content the drop plays. See the TCPA compliance checklist and RMD robocall mitigation for the tenant-owned controls around both. Machine landings recycle contacts into the retry pool on a roughly four-hour timer — pair that with your campaign’s quiet-hours enforcement (covered here) so retries never land outside the permitted calling window.

​
Worked example: payment reminders with a recorded drop

A billing team wants to call 5,000 past-due accounts, reach every human with an agent, and leave a recorded “your payment is due, call us back” message on every voicemail — without burning agent time on answering machines.
Expected behavior:
  1. Each answered leg classifies. Humans bridge to the next ready collections agent after the short detection pause.
  2. Voicemail boxes (and fax tones, iOS screening, iOS Live Voicemail) hear the recorded reminder played into their inbox, then the leg hangs up.
  3. Those contacts recycle as pending roughly four hours later and re-dial automatically until they connect, exhaust retries, or are dispositioned.
  4. After the first ~100 answered legs, the team samples recordings of the amd_detected bucket: if a couple of real people got the drop, they PATCH the campaign down to amd_sensitivity: "low"; if voicemails are still bridging to agents, they step up to "high".
If the same reminder needs to go out with no agents at all, that is an agentless broadcast campaign — put the audio in broadcast_message_url instead (see the voice broadcasts guide); voicemail_message_url is rejected there.