> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Turn on AMD and voicemail drop on a dialer campaign

> Stop burning agent time on voicemails — enable answering-machine detection on a dialer campaign, pick a sensitivity, attach a recorded voicemail-drop message, read the human/machine outcome on every attempt, and tune the sensitivity loop.

# 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](/guides/outbound-dialer-campaign) (list prep, pacing, dispositions) and the [dialer API reference](/api-reference/endpoints/dialer) (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:

| AMD outcome | What happened on the leg | What the dialer does |
| - | - | - |
| `human` | A live person answered. | The leg continues — it bridges to an agent (or into your script / voice agent) untouched. |
| `machine` | A recorded voicemail greeting answered. | Treated as a non-human landing: play the voicemail drop if one is configured, then hang up. |
| `machine_beep_detected` | The voicemail beep was detected after the greeting. | Same handling as `machine`. |
| `ios_call_screening` | An iPhone's Call Screening feature answered and is playing its synthesized screening greeting. | Non-human landing — the leg is treated like a machine, so an unattended campaign never pins a live agent on a screened call. |
| `ios_live_voicemail` | An iPhone's Live Voicemail feature answered and is transcribing the greeting in real time. | Non-human landing, same handling as `machine`. |
| `fax` | A fax tone (CNG) answered. | Non-human landing, same handling as `machine`. |
| `no_answer` | The ring timed out with no pickup. | The attempt records `no_answer` and the contact follows your retry policy. |
| `silence` | The line connected but nobody spoke within the detection window. | Treated like a human landing — the call continues rather than hanging up on someone who answered quietly. |

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](/api-reference/endpoints/webhooks) 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:

```bash theme={null}
curl -X POST "https://api.orbit.devotel.io/api/v1/dialer/campaigns" \
  -H "X-API-Key: dv_live_sk_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Q4 collections outreach",
    "mode": "progressive",
    "caller_id_e164": "+18005551234",
    "amd_enabled": true,
    "amd_sensitivity": "medium"
  }'
```

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.

| `amd_sensitivity` | Behaviour | Good fit |
| - | - | - |
| `low` | Conservative — only high-confidence machines are hung up. Occasionally bridges a real voicemail to an agent. | Sales outreach and other human-heavy campaigns where losing a real answer is the expensive mistake. |
| `medium` | Balanced. The default to start from. | Most campaigns. |
| `high` | Aggressive — catches more machines, with more false positives on humans. | Payment reminders, appointment confirmations, and other unattended or broadcast-style traffic where catching machines matters more than the occasional missed human. |

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:

```bash theme={null}
curl -X PATCH "https://api.orbit.devotel.io/api/v1/dialer/campaigns/dcm_your_campaign_id" \
  -H "X-API-Key: dv_live_sk_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{ "voicemail_message_url": "https://cdn.example.com/audio/q4-collections-reminder.mp3" }'
```

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](/guides/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](/guides/tcpa-compliance-checklist-tool) and [RMD robocall mitigation](/guides/compliance-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](/guides/outbound-dialer-campaign)) 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.

```bash theme={null}
curl -X POST "https://api.orbit.devotel.io/api/v1/dialer/campaigns" \
  -H "X-API-Key: dv_live_sk_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Past-due payment reminders — October",
    "mode": "progressive",
    "caller_id_e164": "+18005550987",
    "amd_enabled": true,
    "amd_sensitivity": "medium",
    "voicemail_message_url": "https://cdn.example.com/audio/payment-reminder-callback.mp3",
    "recording_enabled": false
  }'
```

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](/guides/voice-broadcasts)); `voicemail_message_url` is rejected there.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.