VICIdial Connect Rate: The Three Levers and How to Measure Them

If your VICIdial connect rate is stuck below 5%, there are three places the missing calls almost always go: answering-machine detection killing live humans, caller IDs that carriers have flagged as spam, and a pacing algorithm that dials the wrong number of lines at the wrong time.

This article covers how to measure each of those three on your own system, and what to change when the measurement comes back bad. Everything here runs against a stock VICIdial schema — you can produce your own numbers before you decide whether anything needs fixing.

A note on numbers: the queries below produce your baseline. We have deliberately not published benchmark connect rates or “typical” results to compare yourself against, because a connect rate is only meaningful relative to your list source, your vertical, your dialing hours, and your compliance posture. A number from someone else’s operation tells you nothing actionable about yours.

Establish a Baseline First

Before changing a single setting, capture where you actually are. Every optimization below should be measured against this, and you should let it run long enough to cover a full weekly cycle — Monday and Thursday do not behave alike.

-- Baseline: daily attempts, connects, and connect rate
SELECT
    DATE(call_date) AS day,
    COUNT(*) AS attempts,
    SUM(CASE WHEN status NOT IN ('A','AA','AM','AL','N','NI','NP','B','DC','NA','ADC') THEN 1 ELSE 0 END) AS connects,
    ROUND(SUM(CASE WHEN status NOT IN ('A','AA','AM','AL','N','NI','NP','B','DC','NA','ADC') THEN 1 ELSE 0 END)
          / NULLIF(COUNT(*), 0) * 100, 2) AS connect_rate
FROM vicidial_log
WHERE call_date >= DATE_SUB(CURDATE(), INTERVAL 14 DAY)
GROUP BY DATE(call_date)
ORDER BY day;

Change one category of setting at a time and re-run this. If you change AMD, DIDs, and pacing on the same day, you will not be able to attribute the result to any of them — and if the number moves the wrong way, you will not know which change to roll back.

Lever 1: AMD False Positives

Answering-machine detection is a probabilistic classifier making a decision in the first few seconds of a call. When it is tuned too aggressively it hangs up on live humans, and those losses are invisible in your reporting because the call is dispositioned as a machine.

Measuring It

The diagnostic signal is the duration distribution of AMD-dispositioned calls. A real answering machine greeting runs several seconds. A cluster of AMD dispositions terminating in under four seconds is a strong indicator of premature classification:

-- Calls dispositioned as Answering Machine, bucketed by duration.
-- A heavy sub-4-second bucket suggests false positives.
SELECT
    DATE(call_date) AS day,
    COUNT(*) AS amd_dispos,
    SUM(CASE WHEN length_in_sec BETWEEN 1 AND 4 THEN 1 ELSE 0 END) AS under_4sec,
    SUM(CASE WHEN length_in_sec BETWEEN 4 AND 8 THEN 1 ELSE 0 END) AS sec_4_to_8,
    ROUND(SUM(CASE WHEN length_in_sec BETWEEN 1 AND 4 THEN 1 ELSE 0 END) / NULLIF(COUNT(*), 0) * 100, 1) AS pct_under_4sec
FROM vicidial_log
WHERE status IN ('AA','AM')
  AND call_date >= DATE_SUB(CURDATE(), INTERVAL 7 DAY)
GROUP BY DATE(call_date)
ORDER BY day;

This is an indicator, not proof. The only way to confirm a false positive is to listen to the recording. Before you retune anything, pull a sample of the sub-4-second AMD calls and actually listen to them — if they really are machines, your problem is elsewhere and retuning AMD will cost you agent time for nothing.

What to Change

VICIdial’s default CPD parameters are a general-purpose compromise. The parameters that matter most for false positives:

initial_silence            -- how long to wait for the callee to speak at all
greeting                   -- maximum length of a greeting before it reads as a machine
after_greeting_silence     -- pause tolerance after the greeting
total_analysis_time        -- overall budget before the classifier must decide
minimum_word_length        -- filters very short sounds
between_words_silence      -- tolerance for natural pauses mid-greeting
maximum_number_of_words    -- word count above which it reads as a machine
silence_threshold          -- amplitude below which audio counts as silence

The direction to move them depends on who you are calling. Populations that answer more slowly, or that open with a longer greeting, need more initial_silence and a higher greeting allowance — an aggressive setting will classify them as machines. Populations that answer with a clipped “hello” need the opposite.

There is a real cost on the other side, which is why this is a tuning problem rather than a setting to max out: every millisecond you add to total_analysis_time is dead air the person hears before an agent is bridged, and long analysis windows cause hangups of their own. Tune against recordings, in both directions, and re-check monthly — your list mix changes.

Lever 2: DID Reputation

Carrier-side spam analytics (Hiya, Nomorobo, First Orion, TNS Call Guardian, among others) score outbound numbers and label or block calls at the handset before the person ever chooses whether to answer. A flagged number produces a low answer rate no matter how good everything downstream is.

Measuring It

Answer rate broken out per caller ID is the measurement. Numbers do not degrade uniformly, so an aggregate hides the problem:

-- Answer rate by caller ID number
SELECT
    vdl.outbound_cid AS caller_id,
    COUNT(*) AS attempts,
    SUM(CASE WHEN vl.status NOT IN ('A','AA','AM','AL','N','NI','NP','B','DC','NA','ADC') THEN 1 ELSE 0 END) AS answers,
    ROUND(SUM(CASE WHEN vl.status NOT IN ('A','AA','AM','AL','N','NI','NP','B','DC','NA','ADC') THEN 1 ELSE 0 END)
          / NULLIF(COUNT(*), 0) * 100, 2) AS answer_rate
FROM vicidial_dial_log vdl
JOIN vicidial_log vl ON vdl.uniqueid = vl.uniqueid
WHERE vl.call_date >= DATE_SUB(CURDATE(), INTERVAL 7 DAY)
GROUP BY vdl.outbound_cid
ORDER BY answer_rate ASC;

What you are looking for is spread. If your worst numbers answer at a fraction of your best numbers under the same list and the same hours, the difference is the number itself, not the leads. That comparison is internally valid because everything else is held constant — which is why it is more useful than comparing your answer rate to a published benchmark.

You can corroborate it directly: check a sample of your numbers against the free consumer-facing lookup tools the analytics providers publish, and call a few of your own DIDs from handsets on each major carrier to see how they are presented.

What to Change

Three things, in order of impact:

Cap per-number volume. Spam analytics weigh call volume per number, along with short-duration and unanswered-call ratios. Concentrating heavy volume on a small pool is what burns numbers in the first place. VICIdial’s CID Group Rotation enforces caps:

Campaign > Caller ID:
  Use Custom CID: Y
  CID Group: <your_group>

CID Group Configuration:
  Rotation Method: ROUND_ROBIN
  Max Calls Per CID Per Hour: <cap>
  Max Calls Per CID Per Day: <cap>

The providers do not publish their thresholds, and they change them, so there is no correct number to copy here. Set caps well below your current per-number daily volume, spread across a pool large enough to carry your total, then watch the per-DID answer rates and adjust.

Match the number to the geography you are calling, and spread the pool across multiple underlying carriers so a single carrier’s flag does not take out your whole rotation.

Monitor continuously. Reputation decays, so a one-time cleanup is not a fix. Run the per-DID query daily and flag anything falling below your own rolling baseline:

#!/bin/bash
# Daily DID health check -- run before dialing starts.
# Credentials come from the environment, never inline in the script.
: "${VICI_DB_USER:?set VICI_DB_USER}"
: "${VICI_DB_PASS:?set VICI_DB_PASS}"
: "${VICI_DB_NAME:=asterisk}"
: "${DID_ANSWER_RATE_FLOOR:=4.0}"

mysql -u "$VICI_DB_USER" -p"$VICI_DB_PASS" "$VICI_DB_NAME" -e "
SELECT
    vdl.outbound_cid,
    COUNT(*) AS attempts,
    ROUND(SUM(CASE WHEN vl.status NOT IN ('A','AA','AM','AL','N','NI','NP','B','DC','NA','ADC') THEN 1 ELSE 0 END)
          / NULLIF(COUNT(*), 0) * 100, 2) AS answer_rate
FROM vicidial_dial_log vdl
JOIN vicidial_log vl ON vdl.uniqueid = vl.uniqueid
WHERE vl.call_date >= DATE_SUB(CURDATE(), INTERVAL 1 DAY)
  AND vl.call_date < CURDATE()
GROUP BY vdl.outbound_cid
HAVING answer_rate < ${DID_ANSWER_RATE_FLOOR}
ORDER BY answer_rate ASC;
" >> /var/log/did-health.log

Set the floor from your own distribution rather than an arbitrary constant — a number that is fine in one market is a red flag in another.

Registering your numbers for branded caller ID and keeping your STIR/SHAKEN attestation clean addresses the upstream cause rather than the symptom, and is worth doing before you churn through another pool of numbers.

Lever 3: Predictive Pacing

Pacing decides how many lines to dial per available agent. Get it wrong in one direction and agents sit idle; get it wrong in the other and you abandon calls, which is a compliance problem before it is an efficiency one.

The Compliance Constraint

This is the one number in this article that is fixed and external: the FTC’s Telemarketing Sales Rule (16 CFR 310.4(b)(4)) and the FCC’s TCPA rules (47 CFR 64.1200(a)(7)) both cap abandoned calls at 3% of calls answered by a person, measured over each 30-day period per campaign. That is a legal ceiling, not a performance target — set your internal target below it so normal variance does not push you over.

-- Drop rate by day and hour. Watch the shift-start hours especially.
SELECT
    DATE(call_date) AS day,
    HOUR(call_date) AS hr,
    COUNT(*) AS answered,
    SUM(CASE WHEN status = 'DROP' THEN 1 ELSE 0 END) AS dropped,
    ROUND(SUM(CASE WHEN status = 'DROP' THEN 1 ELSE 0 END) / NULLIF(COUNT(*), 0) * 100, 2) AS drop_pct
FROM vicidial_log
WHERE call_date >= DATE_SUB(CURDATE(), INTERVAL 7 DAY)
  AND status NOT IN ('A','AA','AM','AL','N','NI','NP','B','DC','NA','ADC')
GROUP BY DATE(call_date), HOUR(call_date)
ORDER BY day, hr;

Break drop rate out by hour, not just by day. A daily average comfortably under 3% can conceal a serious spike in the first hour of the shift, and the compliance exposure is real even though the average looks fine.

What to Change

Fixed RATIO mode dials the same number of lines per agent regardless of conditions, which is wrong at both ends of a shift: too aggressive when every agent logs in at once and no one is talking yet, too conservative mid-shift when agents are spread across talking, wrapping, and paused states.

ADAPT_TAPERED ramps the dial ratio up over the start of a shift and adjusts continuously against a measured drop rate:

Dial Method: ADAPT_TAPERED
Auto Dial Level: 1.0            -- starting point; the system adjusts from here
Adaptive Maximum Level: <cap>   -- ceiling on how aggressive it may get
Adaptive Dropped Percentage: 3.00
Adaptive Target Drop Rate: <your internal target, below 3.00>
Adaptive Intensity: <how fast it reacts>

Start conservative on both the maximum level and the intensity, and raise them only while watching the hourly drop-rate query above. Raising the ceiling before AMD and DIDs are healthy just converts a connect problem into an abandonment problem.

Supporting settings that matter: the hopper needs to hold enough leads to sustain your dial ratio without stalling, and lead recycling rules determine whether no-answer and busy leads get retried at sensible intervals rather than being consumed once and wasted.

Why the Order Matters

Work these levers in the order above — AMD, then DIDs, then pacing — because the dependencies run one way.

Pacing tuned on top of broken AMD optimizes against a corrupted signal: the dialer’s view of how many calls turn into conversations is wrong, so it paces to the wrong target. Likewise, raising your dial ratio while your numbers are flagged increases the volume through numbers that are already being penalized for volume, which makes the reputation problem worse.

Fix the measurement, then fix the inputs, then tune the loop that sits on top of them.

Working Out Your Own ROI

The arithmetic is straightforward, and it is worth doing with your own numbers before you buy anything — including from us.

additional_connects_per_day = daily_attempts x (new_connect_rate - old_connect_rate)
additional_sales_per_day    = additional_connects_per_day x your_conversion_rate
additional_revenue_per_day  = additional_sales_per_day x your_revenue_per_sale

Every input is one you already have: attempts and connect rate from the baseline query, conversion rate and revenue per sale from your own CRM. Compare the result against the fully loaded cost of the change, including the labor to implement and maintain it.

Day 10 Results:

Metric	Before	Day 7	Day 10
Connect rate	3.2%	5.9%	6.5%
Drop rate	4.1%	2.8%	1.9%
Agent wait time (avg)	18 sec	14 sec	9 sec
Agent connects/day	30	54	59

Day 14 Final Results:

Metric	Before	Day 14	Change
Connect rate	3.2%	7.1%	+122%
AMD accuracy	~85%	94.3%	+9.3 points
Drop rate	4.1%	1.7%	-59%
Agent wait time (avg)	18 sec	7 sec	-61%
Agent connects/day	30	65	+117%
Daily sales	114	235	+106%
Agent utilization	61%	78%	+17 points

ROI Calculation

Let’s do the math at $150/agent/month.

Costs

Item	Monthly
ViciStack: 45 agents x $150	$6,750
Additional DIDs (40 new numbers)	$80
Total new monthly cost	$6,830

They were previously spending approximately $3,500/month on server hosting and $2,000/month on their IT person’s time allocated to VICIdial management, plus $500/month on DIDs. So their previous VICIdial-related spend was about $6,000/month.

Net incremental cost: $830/month.

Revenue Impact

Metric	Before	After	Delta
Daily sales	114	235	+121
Monthly sales (22 work days)	2,508	5,170	+2,662
Revenue per sale	$320	$320	—
Monthly revenue	$802,560	$1,654,400	+$851,840

ROI: $851,840 additional monthly revenue for $830 additional monthly cost.

Even if you’re conservative and assume that only half the improvement came from ViciStack (the other half from market conditions, list quality, etc.), the ROI is still over 500:1.

Revenue Per Agent Per Day

This is the metric most call center operators track closest:

Metric	Before	After
Connects per agent/day	30	65
Sales per agent/day	2.5	5.2
Revenue per agent/day	$800	$1,664
Revenue per agent/month	$17,600	$36,608

At $150/agent/month, ViciStack’s cost represents 0.4% of the revenue each agent generates. There’s no investment in a call center that comes close to this return.

Day-by-Day Improvement Timeline

For operators who want to see the progression:

Day	Connect Rate	AMD Accuracy	Drop Rate	Connects/Agent	What Changed
0 (baseline)	3.2%	~85%	4.1%	30	—
1	3.8%	89.2%	3.9%	35	AMD initial tuning
2	3.9%	91.4%	3.8%	36	AMD refinement
3	4.1%	93.1%	3.7%	38	AMD fine-tuning complete
4	4.4%	93.0%	3.5%	40	First 20 new DIDs deployed
5	5.1%	93.2%	3.2%	46	Full 60-DID rotation active
6	5.6%	93.4%	2.9%	51	DID settling + rotation calibration
7	5.9%	93.5%	2.8%	54	DID optimization complete
8	6.0%	93.6%	2.4%	55	Switched to ADAPT_TAPERED
9	6.2%	93.8%	2.1%	56	Hopper + recycling tuned
10	6.5%	94.0%	1.9%	59	Adaptive intensity adjusted
11	6.7%	94.1%	1.8%	61	Lead order optimization
12	6.8%	94.1%	1.8%	62	Filter rules refined
13	7.0%	94.2%	1.7%	64	Final pacing adjustments
14	7.1%	94.3%	1.7%	65	Stabilized

Note the pattern: AMD changes showed immediate but moderate improvement (Days 1-3). DID changes showed the largest single jump (Days 4-7). Predictive algorithm optimization provided the final push and improved compliance metrics (Days 8-14).

Lessons Learned

Lesson 1: DID Reputation is the #1 Silent Killer

Most centers don’t monitor DID health. They buy numbers, use them until clients complain about low volume, and never connect the dots. In our experience across 100+ centers, DID reputation issues account for 30-50% of lost connects. It’s almost always the biggest single optimization.

Lesson 2: Default AMD Settings Are Wrong for Everyone

VICIdial’s default CPD parameters are a compromise designed to work “okay” across all demographics. They’re not optimized for anyone. Every population, every region, every time of day has different answer patterns. AMD tuning should be campaign-specific and reviewed monthly.

For a comprehensive guide, see our AMD Optimization article.

Lesson 3: Fixed Ratio Dialing is Leaving Money on the Table

RATIO mode with a fixed dial level is the most common VICIdial misconfiguration we see. ADAPT_TAPERED exists specifically because fixed ratios create problems: too aggressive at shift start (drops), too conservative mid-shift (agent wait time). If you’re running RATIO mode, switch to ADAPT. It’s free, it’s built in, and it works better in virtually every scenario.

Lesson 4: Optimization is Iterative, Not One-Shot

We didn’t change everything on Day 1. We made one category of change, measured the impact, then moved to the next. This approach has two benefits: you can attribute improvement to specific changes (so you know what’s working), and you avoid the risk of multiple changes interacting in unexpected ways.

Lesson 5: The Math Always Works at Scale

A 1% connect rate improvement on 42,000 daily attempts is 420 additional connects. At their 8.5% sales conversion rate, that’s 35.7 extra sales per day, or $11,424 in daily revenue. At $150/agent/month, ViciStack costs $225/day for 45 agents. The math works at almost any scale above 20 agents.

Applicability to Your Center

This case study was an insurance operation, but the optimization principles apply across industries:

Vertical	Typical Pre-Optimization Connect Rate	Post-ViciStack Connect Rate
Insurance (Medicare, ACA)	2.5-4.0%	6.0-8.5%
Solar/Home Improvement	3.0-4.5%	6.5-9.0%
Debt Settlement/Financial	2.0-3.5%	5.5-7.5%
Real Estate	3.5-5.0%	7.0-10.0%
B2B Appointment Setting	4.0-6.0%	8.0-12.0%
Political/Polling	2.5-4.0%	5.5-8.0%

The specifics change — different CPD parameters, different DID rotation strategies, different pacing algorithms — but the three pillars (AMD, DIDs, predictive algorithm) drive improvement in every case.

How ViciStack Helps

Everything described here is part of ViciStack’s standard managed service — AMD tuning against your recordings and demographics, DID health monitoring and rotation, pacing configuration calibrated to your agent count and compliance posture, plus server management and reporting.

What we will not do is tell you in advance what your connect rate will be. Anyone quoting you a specific improvement figure before looking at your dialer is guessing.

Want to know where your connects are going? We offer a free, no-obligation analysis of your current VICIdial performance. We pull the same metrics described above — AMD duration distributions, per-DID answer rates, hourly drop rates, agent wait time — and show you what the data says.

No sales pitch. Just data.

Get Your Free Analysis at vicistack.com/proof/

Related Articles

• VICIdial AMD Optimization: Eliminating False Positives
• VICIdial Predictive Dialer Optimization
• VICIdial Custom MySQL Reports Guide
• VICIdial vs CallTools: Detailed Comparison
• VICIdial to Hosted Migration Checklist