Robert Dugger — Dev Blog

Tag: list-management

  • How to Automate List Management in Telesero (Vicidial)

    Telesero and Vicidial don’t have a native API for list management. Swapping lists in and out of active campaigns is a manual operation — someone logs into the interface, pulls up the campaign, identifies which lists need rotation, and makes the changes by hand. Here’s how to automate that process so the dialer manages its own list queue throughout the day.

    ## The Manual List Management Problem

    A dialer running multiple campaigns needs its lists rotated regularly. Lists exhaust over time — contact rate decays as penetration increases, lead quality degrades with age, and the same numbers start appearing across multiple campaigns. Leaving an exhausted list in rotation burns agent time on dead dials.

    The manual version of this is a daily (or multiple times daily) task: check performance metrics, identify lists that have crossed the threshold for rotation, swap them out, load fresh lists. Done by hand, this requires someone with access to the dialer interface and enough operational context to make the right calls.

    Automated list management replaces that manual loop with a system that monitors performance, detects when a list crosses a rotation threshold, and makes the swap without human intervention — on a schedule that keeps the dialer healthy throughout the operating window.

    ## How Automated List Balancing Works

    Without a native API, the automation drives the Telesero or Vicidial web interface directly — the same interface a human operator would use, navigated programmatically using browser automation.

    The system runs continuously during the operating window. On each cycle it reads the dashboard, extracts the current performance metrics for each active list, applies the rotation logic, and makes any necessary swaps. Between cycles, it waits.

    **The rotation logic has priority tiers:**

    Lists that were recently deactivated but subsequently converted — a lead called while active booked after the list was rotated out — get highest priority. These lists have demonstrated value that wasn’t fully captured.

    Lists with high conversion that have gone inactive come next. They should re-enter the active rotation before lists that haven’t proven their value.

    Lists the operator has manually queued for rotation follow. The system respects the operator’s judgment but doesn’t require the operator to execute the swap.

    Finally, performance-based rotation handles lists that have crossed the exhaustion threshold — contact rate below the floor, penetration above the ceiling — without any manual intervention required.

    **What stays in human hands:** the configuration — which thresholds trigger rotation, which lists are eligible for automatic swapping, which campaigns the automation manages. Decisions about list quality, lead source, and strategy remain with the operator. The automation executes the mechanical work.

    ## The Complication: Browser Automation Breaks in Specific Ways

    This is where most attempts at Telesero automation fail.

    Telesero and Vicidial are web applications built for human interaction. They load pages dynamically, display loading indicators, and update elements asynchronously. Browser automation that doesn’t account for this produces silent failures that look like successful operations.

    **The specific failure mode:** when Telesero shows a loading indicator between actions — a spinner after clicking a button, a delay while a campaign refreshes — naive automation proceeds to the next step before the previous one has completed. The click lands on the wrong element, or on an element that isn’t ready. The list appears to have been swapped. It hasn’t.

    You don’t always find out until the next performance check shows the same exhausted list still active.

    **The correct approach uses explicit wait conditions on every interaction** — not time.sleep() calls that wait a fixed number of seconds regardless of what’s happening, but waits that check for specific page states before proceeding. The automation should know when a page has finished loading, not just hope it has.

    The second fragility is interface changes. Telesero and Vicidial update their interfaces, and browser automation is coupled to the specific element selectors it targets. When an update changes the structure of a page, selectors that worked yesterday stop working today. The automation needs to be built with this in mind — element selectors documented, a test suite that surfaces breakage before it affects production, and a process for updating selectors when the interface changes.

    ## What the Implementation Requires

    **A browser automation layer.** Selenium or Playwright both work for Telesero. Playwright has better explicit wait primitives and handles modern web applications more reliably. The choice matters less than the discipline in how waits are implemented.

    **A performance monitoring layer.** The automation needs current performance metrics for each active list to make rotation decisions. This means reading the dashboard on each cycle — parsing the metrics that Telesero displays — rather than maintaining a separate tracking system that could drift from actual dialer state.

    **A configuration layer.** Rotation thresholds, eligible campaigns, operating window hours, and grace period settings should be configurable without modifying the automation code. The system should be operable by someone who understands the dialer operation but not the Python code.

    **A grace period after resets.** When a campaign reset occurs — clearing attempt history, resetting list positions — the automation should pause before making any rotation decisions. Metrics immediately post-reset don’t reflect steady-state performance, and rotating lists based on post-reset data produces bad decisions.

    **A test suite.** Browser automation that lacks tests is fragile by design. Core behaviors — threshold detection, swap logic, grace period handling, priority tier ordering — should have coverage that runs before any deployment. This is the difference between an automation that runs reliably for months and one that silently breaks after the first interface update.

    ## Frequently Asked Questions

    **Does this work for Vicidial as well as Telesero?**
    Telesero is built on Vicidial, so the interface is similar. The automation approach is the same — browser automation driving the web interface. Specific element selectors will differ between versions and installations, but the architecture is directly transferable.

    **What happens if the automation makes a bad swap?**
    The operator retains full manual override. Any list the automation swaps can be manually reversed through the normal interface. The automation’s swap history should be logged — timestamp, which list was rotated out, which was rotated in, which threshold triggered it — so any unexpected behavior is traceable.

    **Can the automation handle multiple campaigns simultaneously?**
    Yes, but each campaign should be managed sequentially within each cycle rather than in parallel. Concurrent operations against the same Telesero interface create contention — two automation processes trying to interact with the same elements at the same time produces unpredictable results.

    **What’s the operating window?**
    The automation runs during a defined operating window — typically from when the floor opens to when it closes. Outside that window, it’s idle. Start and end times are configurable.

    **How does it handle lists added after the automation starts?**
    New lists that appear in the interface during the operating window are picked up on the next monitoring cycle. The automation doesn’t need to be restarted when list inventory changes.

    ## If You’d Rather Have This Running

    I build automated list management systems for Telesero and Vicidial operations. If you want the browser automation, the rotation logic, the grace period handling, and the test coverage set up correctly — start here: rfditservices.com/intake.html

    The first conversation is free.

  • How to Monitor Dialer List Health in Convoso

    Your list is degrading right now. Aged leads, disconnected numbers, leads that already converted on a different campaign, numbers that hit DNC since you imported them — all of them are burning dial attempts and suppressing your contact rate. Here’s how to build the monitoring layer that surfaces this before it collapses your numbers.

    ## Why List Health Degrades Faster Than You Think

    A fresh lead list has a predictable contact rate. As it ages, that rate decays — but not linearly. The first pass reaches the easiest contacts. Each subsequent pass hits harder-to-reach numbers, people who’ve already heard the pitch, numbers that have gone stale since import. The decay curve accelerates as penetration increases.

    Most Convoso operations notice this as “the list is getting old” and respond by ordering more inventory. The actual problem usually sits earlier: the campaign’s penetration rate wasn’t being tracked, import hygiene missed duplicates against existing leads, and the warning signs were invisible until the contact rate had already collapsed.

    A 10% drop in contact rate over a week is expensive. A 30% drop is a bad week. Neither one is a surprise if you’re monitoring the right signals before they hit.

    ## What List Health Monitoring Tracks

    The metrics that matter, in roughly the order they’ll help you:

    Penetration rate by campaign. What percentage of imported leads have been attempted at least once? This is the leading indicator — the one that gives you time to act. When penetration reaches a threshold, you need new inventory in the pipeline before the campaign goes hungry, not after agents are sitting idle. Convoso doesn’t surface penetration rate prominently in its standard reporting. You have to calculate it from the data the API exposes.

    Contact rate by lead age. Track conversion not just in aggregate but broken down by how long ago a lead was imported: leads attempted in week one, week two, week three since import. The decay curve tells you when a list is effectively exhausted from a productivity standpoint, even if numbers technically remain. Most operations have more “leads” than viable leads — the monitoring makes that distinction visible.

    Lead aging distribution in active campaigns. A campaign can look healthy on aggregate while its active pool is dominated by weeks-old records. Breaking it down by import age surfaces this before it becomes a contact rate problem.

    Cross-campaign duplicate exposure. A number active across multiple campaigns creates agent confusion, customer frustration, and wasted attempts. Deduplication at import catches most of this; monitoring catches what slipped through and surfaces it before it compounds.

    ## The Complication: Convoso Shows You the Past

    Convoso’s built-in reporting is backward-looking. It shows you what your contact rate was yesterday, what it was last week, how many dials converted over any given period. That data is genuinely useful for trend analysis, period comparisons, and reporting to management.

    It doesn’t tell you what your contact rate is going to be in two hours if the list doesn’t change.

    The monitoring that prevents a bad afternoon is penetration rate tracking updated in near-real time, not an end-of-day summary. When a campaign’s available-to-dial leads drop below a threshold, you want to know while there’s still time to load new inventory and have it processing before the afternoon push — not the following morning when the opportunity is already gone.

    Building that leading indicator requires pulling data Convoso doesn’t surface in standard dashboards. A scheduled pull from the API at regular intervals, tracking available lead count by attempt history, gives you the penetration picture as it develops. Cross that with contact rate by lead age and you have a system that surfaces degradation while there’s still time to respond.

    The second complication is at import time. A list that wasn’t scrubbed against existing leads, recent DNC additions, and disconnected numbers before it loaded starts its decay already in progress. Monitoring will surface this — you’ll see the contact rate compress faster than expected for a fresh list — but prevention is cheaper than remediation. Import hygiene automation that runs before the first dial is the companion to monitoring that makes the numbers meaningful.

    ## What the Monitoring Layer Looks Like in Practice

    A scheduled data pull from the Convoso API capturing campaign-level lead counts, attempt history, and contact rates at regular intervals. This doesn’t require a dedicated monitoring platform — the API exposes the data and a scheduled script can collect and log it reliably.

    A dashboard that surfaces threshold violations. A Google Sheets integration works for most SMB contact centers: data lands in a structured format, conditional formatting flags penetration thresholds, and a shared sheet gives ops managers visibility without requiring a new tool. Slack alerts on threshold crossings add a push notification for the signals that need immediate attention.

    Defined thresholds calibrated to your operation. The metrics that signal a list health problem aren’t universal — the right numbers come from your own historical baselines. But the framework is consistent across operations:

    – Contact rate significantly below your historical baseline: urgent flag — the list is exhausted or degraded and is burning agent time without result
    – Contact rate in a healthy range for your vertical and lead source: the target for a well-managed list with appropriate aging
    – Conversion rate below a minimum threshold: list quality problem — leads aren’t converting at a rate that justifies continued dialing; source quality or aging is the likely cause
    – Conversion rate at or above your operational target: the performance level a fresh, properly sourced list should sustain

    Establish your own baselines from the first few weeks of monitored data. The monitoring layer tells you when you’re deviating from those baselines — the thresholds you set determine when deviation triggers an alert.

    Import hygiene automation. Pre-import scrubbing against your existing lead pool and DNC sources reduces the decay rate before the first attempt. This is prevention rather than monitoring, but it’s the step that makes the monitored numbers worth tracking.

    ## Frequently Asked Questions

    Does Convoso have any built-in penetration tracking?
    Convoso shows attempt counts and disposition breakdowns, but not penetration rate as a campaign-level health metric calculated against total imported leads. You derive it from the data the API exposes — available leads versus total leads in the campaign.

    How often does the monitoring need to run?
    For most operations, regular intervals give you enough resolution to catch degradation while there’s still time to act. Running it more frequently is possible but usually doesn’t change the response time meaningfully.

    What if we’re pulling from multiple lead sources with different quality profiles?
    The monitoring should track by source where possible, not just by campaign. A list from one source may have a different expected decay curve than another. Blending them without source tagging makes the contact rate signal harder to interpret.

    ## If You’d Rather Have This Running

    I build monitoring layers for contact centers using Convoso and similar platforms. If you want penetration tracking, contact rate dashboards by lead age, and threshold alerting set up correctly — start here: rfditservices.com/intake.html

    The first conversation is free.

← rfditservices.com