Robert Dugger — Dev Blog

Tag: dialer

  • How to Build a Contact Center Performance Dashboard in Google Sheets

    Google Sheets can replace most of what contact center analytics platforms charge thousands of dollars for — if it’s set up correctly. Here’s how to build a live performance dashboard that surfaces list health, contact rate trends, and swap candidates without expensive software or a data team.

    ## What the Manual Alternative Looks Like

    Most contact centers running Telesero, Vicidial, or similar dialers track performance in spreadsheets already — but manually. The morning pull takes significant time: open the dialer reports, copy the numbers, paste them into the sheet, update the color coding, figure out which lists are underperforming, decide what to swap.

    By the time that’s done, the data is already hours old and the decisions being made are based on what happened yesterday, not what’s happening now.

    A properly structured Sheets dashboard with automated data ingestion eliminates the manual pull and gives the floor real visibility into list health across every active campaign — updated automatically on a schedule.

    ## What the Dashboard Tracks

    The metrics that matter for daily list management, structured into views that surface decisions rather than just data:

    **Health grid.** Every active list, color-coded by current performance state. At a glance: which lists are healthy, which are degrading, which need attention before the next session. The color isn’t manual — it’s calculated from the data and updates automatically when new records come in.

    **Trend panel.** Contact rate and conversion rate over a rolling window, per list. The decay curve tells you when a list is exhausting faster than usual, which is often a lead quality signal rather than a dialing strategy problem. A list that was converting well last week and is declining this week deserves different treatment than one that’s been flat for a month.

    **Swap candidates panel.** Lists ranked by swap priority — organized by performance state, time since last swap, and current metrics — so the decision of what to rotate next is structured rather than intuitive. The panel separates lists by priority tier and preserves the operator’s manual queue order while surfacing data-driven alternatives.

    ## The Architecture

    **Two data sources, one workbook.** A summary sheet holds aggregated metrics per list. A daily records sheet holds per-session performance data. Both connect to the same Google Sheets workbook, and the dashboard views are built on top of them.

    **Automated ingestion.** A scheduled script — running on a consistent cadence before the floor opens — pulls performance data from your dialer system, writes it to the appropriate sheet, and updates the timestamp. When the ops manager opens the dashboard in the morning, the data is already there. The morning pull is gone.

    **Calculated health states.** Rather than manual color coding, health states are calculated from the data. A list’s state (healthy, degrading, exhausted, recovering) is derived from its recent contact rate, conversion rate, time since last active session, and comparison against its own historical baseline — not against a fixed threshold applied to every list equally.

    **Swap scoring.** Each list gets a swap score that combines its current performance metrics, time in the active rotation, and recency of last swap. The score determines the ranked order in the swap candidates panel.

    ## The Complication: The Spreadsheet Isn’t the Automation

    The most common failure mode for teams that “automate” in Google Sheets is building sophisticated formulas and thinking that’s enough.

    It isn’t.

    Formulas calculate from data that’s already in the sheet. If the data gets there manually — someone opens the file and pastes in yesterday’s numbers — you haven’t automated anything. You’ve automated the calculation but not the collection. The bottleneck moved from “calculate” to “paste.”

    The automation that actually eliminates the morning pull is a scheduled script that writes data to the sheet before anyone opens it. Python with the Google Sheets API, or Google Apps Script on a time-based trigger, both work. The key requirement is that the sheet is populated before the floor opens — not refreshed when someone opens it.

    **The second complication is scale.** Google Sheets handles dozens of lists and hundreds of records well. As the list count grows and the history accumulates, formula complexity increases, multi-user edit conflicts emerge, and query times slow down. At a certain scale, the Sheets layer stops being the right tool for the data storage problem — it remains useful as a presentation layer, but the data should live somewhere faster underneath it.

    Knowing when you’ve hit that ceiling is useful information. A dashboard that performs well at your current scale and starts showing signs of strain as you grow is telling you something about where the next investment should go.

    ## Frequently Asked Questions

    **Does this work if our dialer doesn’t have a direct API?**
    The data ingestion approach depends on what your dialer exposes. Most systems (Telesero, Vicidial, Convoso, Five9) have either a direct API or a report export that can be automated. If direct API access isn’t available, scheduled report exports that get parsed and loaded work as an alternative, though with more fragility.

    **Can multiple people use the dashboard simultaneously?**
    Yes — the dashboard is read-only for most users. The automated script that writes data should be the only process making edits to the data sheets. Read-only access across a team works fine in Sheets at any scale.

    **How do we handle lists that are temporarily deactivated?**
    Deactivated lists should remain in the data set with their deactivation timestamp noted, not be removed. A list that gets deactivated and subsequently converts — someone who was called while active books an appointment after being removed from rotation — should surface in the swap candidates panel at elevated priority. The dashboard logic needs to track deactivated status explicitly to handle this correctly.

    **What’s the maintenance overhead?**
    Once the ingestion script and dashboard formulas are set up, maintenance is low — primarily keeping API credentials current and updating the list of active campaigns as your operation changes. A well-built implementation handles new lists automatically when they appear in the data source.

    ## If You’d Rather Have This Built

    I build performance dashboards for contact centers — Sheets-based for operations at current scale, with an eye toward what the architecture looks like when the operation grows. If you want the ingestion script, the health grid, and the swap candidates panel set up correctly — start here: rfditservices.com/intake.html

    The first conversation is free.

  • How to Forecast End-of-Day Call Center Performance

    By mid-afternoon, you can know where your floor will close by end of day — accurately enough to make the remaining hours a decision, not a guess. Here’s how intraday performance forecasting works and what it takes to build it.

    ## The Problem With Yesterday’s Numbers

    Most contact centers have end-of-day metrics. Dials, connects, conversion rate against target. Those numbers are accurate, useful for trend analysis, and arrive the next morning.

    By the time you see them, the day is already over.

    The decisions that drive outcomes happen during the day — in real time, when hours remain to influence the result. Do you push harder in the final stretch? Adjust campaign priority? Pull a server that’s underperforming? Those decisions get made in the afternoon with one question underneath all of them: where are we going to close?

    If you’re answering that question with yesterday’s data and experienced intuition, you’re working with an information deficit that compounds every day it stays open.

    ## How Intraday Forecasting Works

    The system records dial conversion rates at regular intervals throughout the business day. Not a snapshot at end of day. A continuous read of how the floor is performing as it performs.

    Every morning, before the floor opens, the model retrains. It processes the intraday conversion patterns from previous days — how conversion tends to develop through the morning, when it typically accelerates, when it softens, how afternoon performance differs from morning — and calibrates to the current operation’s historical data.

    As the day runs, the forecast updates on a regular schedule. Each update incorporates actual conversion data that’s come in, narrowing the prediction window.

    By mid-afternoon, with hours remaining, the model’s error range has compressed enough that the closing metric is predictable within an actionable range. Not a rough estimate. A forecast with a documented accuracy track.

    **What this changes in practice:**

    Before the forecasting system, the afternoon conversation was backward-looking: here’s where we are, here’s where we were yesterday, here’s the gap. The decision about the next few hours was judgment — experienced judgment, but judgment without a forward projection.

    After the forecasting system, the afternoon conversation is forward-looking: here’s where we are, here’s where we’re going to close, here’s what the remaining hours need to produce to change that number. The judgment still applies. But it’s informed by a projection that’s been validated against actual outcomes rather than intuition alone.

    That’s a different kind of management posture. You’re not reacting to what happened — you’re positioned in front of what’s about to happen.

    ## The Complication: Point Estimates Break When You Need Them Most

    The obvious version of intraday forecasting — average dial conversion rate over recent days, extended to end of day — works in normal conditions and breaks exactly when conditions are abnormal.

    Days after holidays follow different patterns than regular days. Days with agent attrition don’t produce the same intraday curve as fully-staffed days. A mid-day list quality shift — new inventory loading into an active campaign in the afternoon — changes the conversion trajectory in ways a backward-looking average can’t capture.

    A point estimate that’s wrong on the days that matter most is useless. Operations managers stop trusting a forecast that fails them when they need it, which is precisely when conditions are unusual.

    **The correct implementation produces a confidence interval, not just a point estimate.**

    A point estimate says: we’ll close at X conversions.

    A confidence interval says: we’ll close between X and Y conversions, based on current trajectory and historical variance.

    The confidence interval tells you two things the point estimate doesn’t. First, it tells you when the day is trending outside normal bounds — when the interval is wider than usual, the model is operating in territory with less historical precedent, which is a signal to pay attention. Second, it tells you when a result is well-constrained versus genuinely uncertain — a narrow interval with hours remaining means the outcome is largely determined; a wide interval means the remaining time is more variable than usual.

    **Additional inputs that improve accuracy:**

    Day-of-week weighting. Each day’s patterns should be compared to its own history, not the full week averaged together. The model needs to know what kind of day it is.

    Agent count as a real-time input. Utilization affects conversion. A floor running below normal staffing has a different conversion profile than a full floor, and the model needs to account for that explicitly rather than absorbing it as noise.

    ## What Building This Requires

    **A data collection layer.** Conversion rates pulled from your dialer API at regular intervals throughout the day, stored with timestamps. Convoso’s API supports this; a scheduled script on a consistent cadence collects the signal reliably.

    **A retraining pipeline.** Each morning, before the floor opens, the model fits to historical intraday patterns. The features that matter most: time of day, day of week, agent count, and recent conversion velocity. A well-structured ML regression model with the right features outperforms a complex one with the wrong ones — the goal is a forecast accurate enough to act on, not a showcase of modeling sophistication.

    **Validation tracking.** The model’s predicted closing range logged against actual outcomes, daily. This is how you know when the model is drifting and needs recalibration, and it’s how you build the track record that makes the forecast worth trusting. A model you’ve been validating for several months has a credibility that a newly deployed model doesn’t.

    **A delivery layer.** The forecast needs to appear where ops managers look — a dashboard, a scheduled Slack message, a Google Sheets integration. A forecast nobody sees is the same as no forecast.

    ## Frequently Asked Questions

    **How accurate is the forecast by mid-afternoon?**
    Accurate enough to make the remaining hours actionable rather than reactive. The exact precision depends on your operation’s historical variability — a stable floor with consistent staffing and consistent list quality will have tighter forecast intervals than one with high day-to-day variance. The value isn’t in the precision of the number — it’s in the direction and whether you’re trending toward or away from target.

    **Does this require machine learning expertise to build?**
    The approach is an ML regression model with appropriate feature engineering — time of day, day of week, recent velocity, agent utilization. The complexity is in getting the features right and building the validation discipline, not in the modeling approach itself.

    **What data do I need to start?**
    Historical intraday data at the interval you want to forecast at — ideally several months of regularly sampled conversion rates. If that data isn’t archived, starting with collection now and building the model after accumulating enough history is the right sequencing.

    **Can this work if our staffing varies a lot day to day?**
    Yes, but agent count needs to be an explicit input to the model rather than something it absorbs implicitly. Days with unusual staffing should be labeled as such in the training data so the model can account for the pattern, rather than treating them as noise.

    ## If You’d Rather Have This Built

    I build intraday performance forecasting for contact centers. If you want the data collection, the retraining pipeline, and a confidence-interval forecast that surfaces where your floor will close before the last hours are gone — 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.

  • Automating Most of My Job: I Didn’t Want to Babysit a Dialer Forever

    I Didn’t Want to Babysit a Dialer Forever

    The unglamorous version of data administration is a lot of watching. Watching a dialer load leads. Watching a queue fill and drain. Watching the same manual processes run the same way they’ve always run because no one has had time to change them.

    I didn’t want to do that indefinitely.

    The first experiments were messy. Early Google Gemini API calls combined with Python Selenium — browser automation that could handle the dialer interactions I was tired of doing myself. The code was fragile, the model was still finding its footing, and the results weren’t perfect. But they were good enough to prove something: the repetitive parts of this job could be handled by something that wasn’t me.

    That realization changed what I built next.

    The Telesero Balancer is the clearest example — a live system that handles the distribution logic I used to manage manually. Convoso tools that shave seconds off agent workflows at scale. Brownbook Tools for the data sourcing problem. External partnerships that bring in raw lead data without someone manually pulling it.

    None of these have a clean ROI number attached. I haven’t measured hours saved per week and multiplied by fifty-two. What I can say is that the class of work I was doing when I started — the babysitting — occupies a fraction of the same time, and what replaced it is more interesting.

← rfditservices.com