Building an Outbound Ops Dashboard: Architecture, Data Sources, and Layout Decisions

Who Uses an Ops Dashboard and What They Need to See

The ops dashboard serves three roles simultaneously, often on the same team:

The network operator needs SIP trunk health, channel concurrency, carrier error rates, and PDD trending across markets. When a carrier has an outage, they need to see it in under 60 seconds and have enough data to isolate the affected route.

The campaign operations lead needs real-time campaign status across all active campaigns: abandon rates, connect rates, DID pool health, agent utilisation by campaign, and list penetration velocity. They need to catch problems fast enough to intervene before they compound into compliance violations or wasted list spend.

The technical manager needs a 30-day health view: uptime, error rate trends, infrastructure cost per connected minute, and the leading indicators that predict problems before they become incidents. They review this weekly, not in real time.

One dashboard cannot serve all three views simultaneously. Build three views on one data platform: a live view (10-second refresh), a daily view (5-minute refresh), and a trend view (daily snapshots).

The Technology Stack for a Production Ops Dashboard

A production ops dashboard for an outbound call center has four layers:

Data ingestion. CDR events arrive via the telephony API (or from a local CDR database if your media server writes them locally). Channel state data is polled from your media server's management API or consumed from a real-time event stream. Agent state arrives from your dialer platform's API or WebSocket feed. Infrastructure metrics (CPU, memory, network on media servers) arrive from a standard metrics agent (Prometheus node_exporter, Datadog, or equivalent).

Aggregation and storage. A time-series database handles the high-frequency metrics (Prometheus/VictoriaMetrics for infrastructure metrics; a columnar store or Redis for CDR-derived rolling metrics). A relational store holds the campaign and agent configuration data that provides dimension context.

Query and compute layer. Aggregation logic runs in a small service that computes the KPIs your dashboard needs: rolling abandon rates, per-DID answer rates, carrier error percentages, and so on. This service consumes from the storage layers and exposes computed metrics via HTTP or WebSocket. Do not compute KPIs in the dashboard frontend — frontend computation on every browser refresh does not scale.

Dashboard frontend. Grafana is the standard choice for technical ops dashboards. It connects natively to Prometheus, most SQL databases, and many time-series stores. Custom panels can be built using the Grafana plugin system. For non-technical audiences, Metabase or a custom React dashboard may be more appropriate. The UnlimCall API can serve as a direct data source for Grafana via the JSON datasource plugin.

Live View: The Eight Panels That Matter

For the live view with 10-second refresh, eight panels provide comprehensive operational coverage:

1. Active SIP channels (gauge + sparkline). Current count against provisioned capacity. Sparkline shows the last 15 minutes. Red zone above 85 % capacity.

1. SIP error rate by carrier path (heatmap or table). One row per active carrier route, one column per SIP error code category (4xx, 5xx, network timeout). Updated every 60 seconds.

1. Abandon rate by campaign (bar chart). One bar per active campaign. Color-coded: green < 2.0 %, yellow 2.0–2.8 %, red > 2.8 %. This is the FTC compliance view.

1. Connect rate by campaign (bar chart, same layout). Side-by-side with abandon rate. A campaign with falling connect rate and stable abandon rate has a list problem. Falling connect rate with rising abandon rate has a pacing problem.

1. DID health status (table). All active DIDs with their 60-minute rolling answer rate versus 7-day same-hour baseline. DIDs more than 12 pp below baseline highlighted in yellow; more than 20 pp highlighted in red.

1. Agent utilisation by campaign (grouped bar). Ready, on-call, wrap-up, and break states. The on-call bar should be 80–90 % of total logged-in time on a productive predictive campaign.

1. PDD trending (line chart). Average post-dial delay for the last 60 minutes, broken by destination country. A sudden PDD increase to a specific country is often the first signal of a carrier routing problem before SIP errors start accumulating.

1. Infrastructure health (status grid). Green/yellow/red indicators for: media server, database, Redis/cache, the telephony API, and any external services (CRM, recording storage). Links to individual service dashboards.

Trend View: The Six Panels for Weekly Review

The trend view runs on daily snapshots, displayed as 30-day time series:

1. Calls attempted vs. connected (volume and rate)
2. Abandon rate trend by campaign
3. Average AHT by campaign and week
4. DID pool rotation rate (how many DIDs retired vs. provisioned)
5. Carrier error rate by route (weekly aggregate)
6. Cost per right-party contact, trended (on flat-rate pricing this is monthly_cost / RPC_count, straightforward)

Connecting the Ops Dashboard to Your Alerting System

The ops dashboard and the alerting system share the same underlying data. The dashboard visualises what alerting quantifies. Build them from the same aggregation layer rather than maintaining two separate metric pipelines.

When an alert fires, the notification should deep-link to the relevant panel in the ops dashboard — not to the dashboard homepage. The on-call operator needs to land on the carrier error rate heatmap when they get a carrier outage alert, not navigate from a homepage to find the right panel under pressure.

The Cost of Building vs. Buying

Commercial call center analytics platforms — NICE, Verint, Five9 Analytics, Genesys Cloud Analytics — offer pre-built dashboards but charge $15–$60 per seat per month as an add-on over their base platform cost. For a 50-seat floor, that is $750–$3,000 per month in analytics tooling alone, on top of telephony costs.

A Grafana-based ops dashboard running on a small VM (4 vCPU, 8 GB RAM handles most workloads under 500 agents) costs under $50 per month in infrastructure. The build investment is 2–4 weeks of engineering time and produces an asset you own and extend without recurring per-seat licensing.