Every few months someone asks me to fix an abandon rate. The conversation almost always opens the same way: the number is too high, counsel is unhappy, and the proposed fix is to dial less aggressively.
Dialing less aggressively will lower the number. It will also cost a third of the connects. And in more than half the cases I've looked at, it treats a symptom that isn't the disease.
Two populations, one metric
An abandon, in the sense the regulation cares about, is a call where a human picked up and no agent was there. That's the thing you're supposed to keep rare.
But the number most dashboards show you is a bucket, and the bucket also contains calls the dialer classified as answered-by-human and then dropped — including the ones where the classification was wrong in the other direction. Answering-machine detection sits upstream of the abandon metric. When AMD is mistuned, it moves calls between categories, and the abandon rate moves with it for reasons that have nothing to do with pacing.
The two failure modes look identical on a summary report and need opposite fixes:
- Genuine abandons. Pacing is outrunning agent availability. Real fix: pacing.
- AMD misclassification. Live humans are being scored as machines and dropped, or machines are being passed to agents and dispositioned as drops. Real fix: detection thresholds.
If you tune pacing to fix the second one, you pay for it in connects and the underlying problem stays.
Separate them before you touch anything
Before changing a single pacing parameter, split the bucket. Pull your dropped calls and group them by the disposition path they took rather than looking at the aggregate:
SELECT status, COUNT(*) AS calls
FROM vicidial_log
WHERE call_date >= NOW() - INTERVAL 7 DAY
GROUP BY status
ORDER BY calls DESC;
That's the crude version and it's usually enough to see the shape. What you're looking for is the ratio between drops and machine dispositions, and whether it's stable across campaigns. It rarely is. One campaign calling mobiles at 6pm and another calling landlines at 10am will have genuinely different machine populations, and a single global AMD setting cannot be right for both.
The tell
Here's the diagnostic I trust most, and it costs nothing but time: pull fifty recordings of calls the system dropped as machines and listen to them.
Not a report. The actual audio.
If a meaningful fraction are humans saying "hello" — and on a mistuned system it is routinely a quarter of them — you do not have a pacing problem. You have a detection problem that is both inflating your abandon rate and burning real contacts. Fixing it improves compliance and connects at the same time, which is not a trade-off you get offered often.
If they're genuinely all machines, then the abandon rate is real, and now you can go tune pacing knowing you're solving the right thing.
Why the default settings betray you
AMD defaults are tuned for an average that describes nobody. The detection window that works for a landline population answering with a two-word greeting is wrong for mobiles with carrier voicemail that opens with three seconds of silence. Greeting length, initial silence, and the gap before the beep all vary by market, by device type, and by time of day.
So the honest answer to "what should my AMD settings be" is that nobody can tell you from outside your data. What they can tell you is the method: sample your own recordings, label them by hand, and tune against the labelled set. A few hundred calls is enough to move the needle substantially, and it takes an afternoon.
What to do on Monday
- Split drops from machine dispositions and look at them per campaign, not in aggregate.
- Pull fifty dropped-as-machine recordings and listen. Count the humans.
- If humans are in there, tune detection against labelled audio before you touch pacing.
- Only then, if the abandon rate is still real, rebuild pacing against measured agent-availability curves — per campaign.
- Put the abandon rate on a daily report. The teams that get surprised by this number are the ones seeing it quarterly.
The uncomfortable part is that step two is manual and nobody wants to do it. It is also the step that decides whether the next three are aimed at anything real.