Robert Floyd Dugger — Writing

Tag: list-management

  • How to Automate Lead List Import in Convoso

    Convoso’s manual list import is a CSV upload through the interface — one file at a time, one campaign at a time. If your operation receives new lead files regularly from vendors or internal sources, that manual process is a recurring bottleneck that automation eliminates. Here’s how to build scheduled, automated list import with the hygiene checks that protect every campaign before the first dial goes out.

    ## The Manual Import Problem

    Manual list import in Convoso has two failure modes.

    The first is operational: someone has to do it. New leads sitting in a shared drive because the person who handles imports is busy, out, or forgot is a dialing opportunity that’s been missed. At the start of a day, a campaign that needed fresh inventory isn’t getting it because the list is still unimported.

    The second is compliance: manual imports rarely include pre-import hygiene. A CSV arrives from a vendor, someone uploads it to Convoso, and the campaign starts dialing. The list hasn’t been checked against the Federal DNC registry, state DNC lists, the litigator database, or your own internal opt-outs. The compliance exposure starts with the first dial.

    Automated import handles both. Lists arrive, get processed, get scrubbed, and land in Convoso ready to dial — on schedule, with documentation.

    ## How Automated Import Works

    The import pipeline runs on a schedule. When a new list file arrives at a defined location — a cloud storage bucket, a shared network folder, or a vendor SFTP drop — the pipeline picks it up, processes it, and imports it into the correct Convoso campaign.

    **The pipeline stages:**

    **1. Intake.** Monitor the source location for new files. When a file appears, validate it — expected columns, no encoding issues, minimum record count. A malformed file should fail loudly before reaching any subsequent stage.

    **2. Pre-import hygiene.** Scrub the list before it touches Convoso:
    – Deduplicate against leads already active in the target campaign
    – Check against your internal opt-out list
    – Check against the Federal DNC registry
    – Check against state DNC lists for relevant states
    – Check against the litigator database (Blacklist Alliance, Contact Center Compliance, or equivalent)

    Records that hit any of these checks are removed from the import set and logged with the reason. What remains is a clean list.

    **3. Import.** Use the Convoso API to create or append to a list in the target campaign. The API supports programmatic list management — you’re not screen-scraping the upload interface.

    **4. Post-import confirmation.** Verify the record count in Convoso matches the expected post-hygiene count. If the counts don’t match, the pipeline fails loudly rather than assuming the import completed correctly.

    **5. Logging.** Record the file name, source, timestamp, pre-hygiene count, post-hygiene count, removals by reason, and the Convoso list ID the records landed in.

    ## The Complication: Compliance Exposure Starts at First Dial

    The sequence matters. The hygiene checks have to happen before import, not after.

    A list imported to Convoso without pre-scrubbing starts accumulating compliance exposure from the moment the first dial goes out. If a litigator’s number is on the list, that dial is already a liability — it can’t be undone retroactively by a DNC removal after the fact. The call happened. TCPA violations attach to completed calls, not pending ones.

    The trap most operations fall into: they have a DNC removal process for numbers that come in after the campaign is running, but no systematic pre-import scrubbing. The removal process handles complaints; it doesn’t prevent them.

    **The correct sequence:**

    1. Receive the list
    2. Run all hygiene checks
    3. Remove flagged records and log the reason
    4. Import only the clean remainder
    5. Document the hygiene run with timestamps

    This is prevention, not remediation. The list that enters Convoso should already be clean — the hygiene run is the proof.

    **The litigator list specifically:** most automated import pipelines check Federal DNC and stop there. The litigator database is a separate scrub against numbers held by serial plaintiffs. These numbers aren’t on any opt-out list. They’re clean by standard DNC criteria and still represent the highest TCPA litigation risk in your list. Pre-import scrubbing against Blacklist Alliance, Contact Center Compliance’s Litigator Scrub, or an equivalent is the check most operations miss.

    ## What the Architecture Requires

    **A file watcher or scheduler.** The trigger for import automation depends on how lists arrive. If vendors drop files to a cloud storage bucket, a storage trigger can initiate the pipeline when a new file appears. If files arrive on a schedule, a cron job or scheduled Cloud Run job works. If files come from an SFTP server, a polling job checks the server on a defined interval.

    **A normalization layer.** Vendor lists arrive in different formats, column orders, and encodings. A normalization step before hygiene checking converts every input to a consistent internal format — E.164 phone numbers, standardized column names, UTF-8 encoding.

    **Hygiene API integrations.** Each hygiene check requires an API call to the relevant service. The pipeline needs valid credentials for each service and should handle API failures gracefully — a hygiene service that’s temporarily unavailable should pause the import, not skip the check.

    **Convoso API integration.** List creation and record upload use the Convoso API. The integration needs valid credentials and should validate the upload response against the expected record count.

    **Logging to durable storage.** Every import run should produce a log entry that’s retained. If a compliance question arises months later about a specific number, the log should show when it was imported, which hygiene checks it passed, and which campaign it landed in.

    ## Frequently Asked Questions

    **Does Convoso support programmatic list management through the API?**
    Yes. The Convoso API includes endpoints for list creation, record addition, and campaign assignment. The interface upload is the most visible path, but the API supports the same operations at scale without manual steps.

    **What if a vendor sends the same number on multiple lists?**
    The deduplication stage catches this — numbers already present in the target campaign are excluded from the new import with the reason logged. If the same number appears multiple times in a single incoming file, that’s caught during normalization before any API calls are made.

    **How does the pipeline handle files from multiple vendors with different formats?**
    Each vendor source gets a normalization configuration — a mapping from that vendor’s column names and format to the internal standard. New vendor sources require a new normalization config, not changes to the core pipeline logic.

    **What happens if the Convoso API import partially succeeds?**
    The post-import record count check catches this. If Convoso confirms fewer records than the pipeline sent, the run is flagged as incomplete rather than successful. The remaining records can be retried without re-running hygiene on the already-imported subset.

    ## If You’d Rather Have This Running

    I build automated list import pipelines for contact centers using Convoso — with the pre-import hygiene, the record count validation, and the audit logging that makes every import defensible. Start here: rfditservices.com/intake.html

    The first conversation is free.

  • 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