Reading the AMD Log Report to See What AMD Actually Decided

You cannot tune answering machine detection (AMD (answering machine detection)) by guessing. You need to see what it actually decided on real calls, and that is what the AMD Log Report is for. It shows the results of the built-in detection function on calls placed from your dialers, so you can compare what AMD thought against what really answered. This is the single most useful screen for fixing detection.

Where to find it

The AMD Log Report lives in the reports section of the admin site, alongside the other call and carrier (Carrier) logs. Open it, pick a date range and the campaign (Campaign) you care about, and run it. You want a window with enough volume to be meaningful, so a full day of dialing rather than a handful of calls.

What the results mean

Each logged call carries an AMD result. The main ones are HUMAN, when detection believes a live person answered, and MACHINE, when it believes it reached a recording. There is also NOTSURE, the result for calls AMD could not confidently classify. By default, HUMAN and NOTSURE calls go to agents, while MACHINE calls get hung up or sent to a message depending on your campaign settings.

The report ties each result to the call, so you can line it up against the recording and the disposition (Disposition) the call ended with. That pairing is the whole value: it tells you not just what AMD decided but whether it was right.

flowchart TD
  A[Open AMD Log Report] --> B[Pick campaign and date range]
  B --> C[See result per call]
  C --> D{Compare to recording}
  D -->|Machine logged but human| E[False positive]
  D -->|Human logged but machine| F[False negative]
  D -->|Matches reality| G[Tuning is correct]
  E --> H[Loosen detection]
  F --> I[Tighten detection]

Spotting the two failure modes

Read the log with two questions. First, how many calls logged as MACHINE were actually people? Those are false positives, and each one is a live answer (Live answer) you threw away. If you see a pattern of them, your detection is too tight, and our guide on fixing AMD false positives covers the direction to loosen.

Second, how many calls logged as HUMAN were really machines? Those are false negatives that wasted an agent (Agent) on a voicemail greeting. A lot of them means detection is too loose and needs tightening.

Use the report to set agent routing

The log also informs how you route calls. If you decide to override the default and define which AMD statuses go to agents, you build those status-and-response rules from what you see in this report. Look at the spread of results across your real traffic, then decide which ones are safe to send to agents and which to divert. The report shows the statuses your system is actually producing, which is the only sound basis for those rules.

When you change an AMD parameter, the loop always comes back here. Make one change, dial, then pull the report again and see if the mix of results moved the way you wanted. For the parameters themselves, read our AMD Asterisk parameters guide, and for the whole detection picture, the AMD and CPD complete guide.

Reading the log is straightforward; keeping the dialer it runs on healthy is the harder part. VICIfast manages the AMD application, logging, and reports so the numbers you read are reliable. See VICIfast pricing to get a managed dialer with detection logging that works.