Optimize VICIdial dial ratios and AMD for better connection rates

01 / 09

Fast answer

Choose one campaign and compare the same date range before and after one change. Record attempts, answered calls and the exact definition of an answer; do not attribute a change to one cause without supporting evidence.

Dial level and AMD can both affect call outcomes, but a falling status share has other possible causes. Compare consistent windows and use labeled, authorized test calls to assess whether AMD classified a human or machine correctly.

This is the measurement layer on top of two other guides. What a dial method is and how MANUAL, RATIO, and adaptive pacing actually work is covered in VICIdial dialing modes and pacing: manual, ratio and adaptive. What AMD is and how to test a candidate threshold against a labeled sample is covered in Tune AMD without burning good leads. This guide assumes both and focuses on one question: once pacing and AMD are both live, how do you tell which one is costing you connected calls, and what do you change first.

Dial level controls pacing; AMD classifies answered audio; DROP and other statuses record outcomes according to the installed configuration. Their counts are useful indicators, not direct proof of the caller’s experience.

02 / 09

Connect rate, answer rate, and drop rate are three different numbers

Define each metric before calculating it. The human_answered flag is a status configuration flag, not a direct observation that a human reached an agent. DROP share here means DROP-labeled rows divided by selected log rows; a carrier answer timestamp is a separate signal.

Do not average these across dates or campaigns that used different auto_dial_level or AMD settings. Averaging hides exactly the thing you are trying to find: which lever moved the number, and when.

If this campaign defines its own status overrides in vicidial_campaign_statuses, its human_answered value takes priority over the system default in vicidial_statuses for the same status code; check both tables rather than assuming the system default applies everywhere.

03 / 09

Step 1 — Measure your baseline from vicidial_log and vicidial_carrier_log

Freeze an explicit baseline before changing anything. Choose server-time start/end boundaries, record the timezone and keep the upper bound exclusive. Match staffing, list mix, route and status definitions; a longer baseline may describe variation but is not the live stop monitor.

The example dates and DNCLAB campaign below are placeholders for an approved test record. Run it in the authorized root context from the read-only-account lesson or use sudo mysql; do not make its root0600 option file readable to ordinary users.

SELECT vl.campaign_id, COUNT(*) AS selected_log_rows, SUM(COALESCE(cs.human_answered,ss.human_answered)='Y') AS human_answered_flag_rows, SUM(vl.status='DROP') AS drop_status_rows, SUM(vl.status IN ('AA','AM','AL')) AS machine_status_rows, ROUND(100.0*SUM(COALESCE(cs.human_answered,ss.human_answered)='Y')/NULLIF(COUNT(*),0),2) AS human_answered_flag_share_percent, ROUND(100.0*SUM(vl.status='DROP')/NULLIF(COUNT(*),0),2) AS drop_status_share_percentFROM vicidial_log vlLEFT JOIN vicidial_statuses ss ON ss.status=vl.statusLEFT JOIN vicidial_campaign_statuses cs ON cs.campaign_id=vl.campaign_id AND cs.status=vl.statusWHERE vl.campaign_id='<CAMPAIGN_ID>' AND vl.call_date >= '<START_SERVER_TIME>' AND vl.call_date < '<END_SERVER_TIME>'GROUP BY vl.campaign_id;

• Save a baseline window that ends before the effective change.
• Record the clock/timezone, staffing, route/list population and status definitions.
• Use labeled call evidence for AMD accuracy; status shares alone cannot supply it.

04 / 09

How dial level and AMD interact to create or destroy connected calls

Dial level and AMD can affect different parts of the call path. Raising auto_dial_level may place more calls relative to available agents; a DROP status is a configured outcome and needs additional evidence before it can be described as a human abandonment.

AMD can classify an answered greeting as a machine and send it according to the campaign’s configured action. A misclassification is possible, but a machine status alone does not prove that a human answered; use labeled test audio to evaluate it.

A rise in DROP or machine-labeled statuses can identify where to investigate. Neither a status nor an answer timestamp alone proves a human was misclassified; compare authorized audio or labeled test calls.

05 / 09

Step 2 — Raise dial level in evidenced steps with a stop threshold

Approve the operator and numeric stop rule before a pacing change. Define the live counter, denominator and window separately from the historical query. The operator watches fresh events; a week of earlier calls must not dilute a new failure.

Use a bounded test and one setting change. Full-shift observations may support a later comparison only after the immediate safety gates remain satisfied; they never require waiting through a breached stop threshold.

1. Freeze the baseline and original setting.2. Name the live counter/window/denominator,operator and numeric stop rule.3. Record the effective change time; start a fresh post-change interval.4. Stop immediately at the rule or an unexpected call; restore and verify.5. Compare matched frozen intervals only after the test is complete.

• Watch only the named fresh-event window for the immediate stop.
• Record each configuration effective time; do not mix increments.
• Restore the original setting promptly if the threshold is crossed.

06 / 09

How AMD misclassification burns good leads

Campaign settings including am_message_exten, amd_send_to_vmx, cpd_amd_action and amd_type affect the configured handling of machine classifications. Inspect the installed version and campaign, then use authorized labeled audio to assess possible misclassification.

A and AA are different recorded classifications. An agent-selected machine status and an AMD-selected machine status are both observations that can be wrong; verify classification accuracy against labeled audio.

Compare the AA trend with setting changes, but do not infer accuracy from the trend alone. Check eligible dial statuses to understand whether a lead can be retried, and validate actual behavior in a controlled test.

SELECT DATE(call_date) AS call_day, COUNT(*) AS total_calls, SUM(status = 'AA') AS dialer_machine_status_rows, SUM(status = 'A') AS agent_machine_status_rows, ROUND(100 * SUM(status = 'AA') / COUNT(*), 2) AS machine_status_share_percentFROM vicidial_logWHERE campaign_id = '<CAMPAIGN_ID>'  AND call_date >= CURDATE() - INTERVAL 14 DAYGROUP BY call_dayORDER BY call_day;

• Confirm the exact date of any AMD threshold or amd_type change before reading this trend
• Treat AA as AMD's classification, not confirmed proof of a machine

07 / 09

Step 3 — What to change first when connect rate is low

Use the same frozen-window query for two comparable intervals: for example two completed shifts with equal boundaries, matching staffing and one unchanged configuration per interval. Keep the baseline output; changing the query’s end date later does not replace it.

For a calendar-week comparison use two completed seven-day windows. The example below ends at midnight today and excludes today’s partial day; replace it with explicit timestamps for a shift test. Pacing versus AMD is decided from the status trend plus staffing, route and labeled-audio evidence, not from a single percentage.

sudo mysql --defaults-file=/etc/vicidial-readonly.cnf -e "SELECT IF(call_date < CURDATE()-INTERVAL 7 DAY,'earlier_7_days','later_7_days') AS period, COUNT(*) AS selected_log_rows, SUM(status='DROP') AS drop_status_rows, SUM(status='AA') AS amd_machine_status_rows, ROUND(100.0*SUM(status='DROP')/NULLIF(COUNT(*),0),2) AS drop_status_share_percent FROM vicidial_log WHERE campaign_id='<CAMPAIGN_ID>' AND call_date>=CURDATE()-INTERVAL 14 DAY AND call_date<CURDATE() GROUP BY period;"

• Separate completed-period analysis from live stop monitoring.
• Check effective setting time, staffing and route/list mix for each period.
• Use the actual descriptive aliases; do not relabel a status-flag share as measured human connection.

08 / 09

Weekly metrics to watch

Recheck consistently defined status shares against the same campaign and comparable periods. A change in a status flag share is an investigation signal, not proof of connection rate or cause.

• human_answered_flag_share_percent for matched windows: a configured status proxy.
• drop_status_share_percent among the selected outbound log rows; not a legal abandonment-rate definition.
• AA/AM/AL shares, plus A separately, checked against the actual AMD change date.
• Provider answer/duration and labeled test evidence only after column semantics/units are validated.
• Exact configuration effective timestamps, including changes not reflected by campaign_changedate.

09 / 09

Troubleshoot, rollback, and know when to stop

Rerun the baseline with the same scope and status definitions. Compare changes with staffing, carrier conditions and the timing of pacing or AMD changes; correlation alone does not prove cause.

If an authorized test must be rolled back, restore the documented previous campaign or AMD setting through the appropriate administration workflow, then verify the stored value and monitor the same status measures. A return to an earlier trend is not guaranteed.

Stop at the threshold agreed before the test or when unexpected results require investigation. Record the result and any rollback as completed only after verification.

SELECT campaign_id, dial_method, auto_dial_level, amd_type, cpd_amd_action, campaign_changedateFROM vicidial_campaignsWHERE campaign_id = '<CAMPAIGN_ID>';