A manager reviews yesterday's reports. Response time looks fine. Meanwhile, the queue has 150 calls, agents are stressed, and every fifth customer hangs up. By the time the morning report lands, the damage is done.
My take: I have worked with dozens of Asterisk call centers. The ones running on daily reports consistently make worse decisions than the ones with even basic real-time visibility. The gap is not about having more data. It is about having the right data at the right moment.
That is the difference between monitoring and real-time monitoring. The first is post-mortem analysis. The second is a live pulse that lets you intervene when intervention still matters.
The 5 Metrics That Actually Matter
You do not need 50 charts. You need 5. Every additional metric on the main screen dilutes attention from the ones that drive decisions.
1. Average Handle Time (AHT)
Average call duration plus after-call work time.
2026 benchmarks by industry:
| Industry | AHT Range | What Drives It |
|---|---|---|
| B2B Services | 4-7 min | Straightforward queries, documented products |
| Telecom | 6-10 min | Account changes, billing disputes |
| Banking | 8-12 min | Compliance requirements, verification steps |
| Tech Support | 10-15 min | Troubleshooting, remote access, multi-step fixes |
One long call is not a problem. The problem is when the 30-minute rolling average creeps up and nobody notices for two hours.
In Asterisk, you can track AHT in real-time from queue_log:
-- Rolling 30-minute AHT from queue_log
SELECT
queuename,
ROUND(AVG(data2::int + data3::int)) AS aht_seconds,
COUNT(*) AS calls_completed
FROM queue_log
WHERE event IN ('COMPLETEAGENT', 'COMPLETECALLER')
AND time > NOW() - INTERVAL '30 minutes'
GROUP BY queuename
ORDER BY aht_seconds DESC;The data2 field is hold time, data3 is talk time. Add them for total handle time. If you want wrapup included, configure wrapuptime in queues.conf and track the gap between COMPLETEAGENT and the next UNPAUSE event.
My take: AHT obsession is the #1 mistake I see in call centers. Managers pressure agents to cut calls short, which tanks first call resolution and increases repeat contacts. An agent who spends 12 minutes solving a problem permanently is more valuable than one who spends 4 minutes creating a callback. Track AHT for awareness — not as a target.
2. Service Level (SLA)
Percentage of calls answered within the target time. Standard: 80% of calls answered within 20 seconds (the 80/20 rule).
SLA drops fast. From 85% to 72% in 10 minutes — that is a signal to act immediately, not a data point to discuss tomorrow.
-- Real-time SLA since shift start
WITH answered AS (
SELECT
queuename,
callid,
MIN(CASE WHEN event = 'ENTERQUEUE' THEN time END) AS entered,
MIN(CASE WHEN event = 'CONNECT' THEN time END) AS connected
FROM queue_log
WHERE time > DATE_TRUNC('day', NOW()) + INTERVAL '8 hours'
GROUP BY queuename, callid
HAVING MIN(CASE WHEN event = 'CONNECT' THEN time END) IS NOT NULL
)
SELECT
queuename,
COUNT(*) AS total_answered,
COUNT(CASE WHEN EXTRACT(EPOCH FROM (connected - entered)) <= 20 THEN 1 END) AS within_target,
ROUND(100.0 * COUNT(CASE WHEN EXTRACT(EPOCH FROM (connected - entered)) <= 20 THEN 1 END) / COUNT(*), 1) AS sla_pct
FROM answered
GROUP BY queuename;Configure Asterisk to track this properly:
; queues.conf — SLA tracking requires accurate timestamps
[support-queue]
servicelevel=20 ; define SLA target (20 seconds)
autofill=yes ; prevents single-call queue processing
joinempty=yes ; let calls queue even if no agents (tracks true demand)
leavewhenempty=no ; keep them in queue for accurate abandon trackingThe servicelevel parameter tells Asterisk what your SLA target is, which feeds into queue_log data and AMI events. Without it, you are calculating SLA externally without Asterisk knowing what "on time" means.
3. Abandon Rate
Percentage of callers who hung up before reaching an agent. Normal: 3-8%. Above 10% — you have a capacity problem.
A jump from 5% to 15% in a single hour means one of three things:
- —Not enough agents (most common)
- —Trunk failure sending calls to a dead queue
- —IVR misconfiguration routing calls to the wrong place
-- Abandon rate by hour, last 24 hours
SELECT
DATE_TRUNC('hour', time) AS hour,
queuename,
COUNT(CASE WHEN event = 'ABANDON' THEN 1 END) AS abandoned,
COUNT(CASE WHEN event IN ('CONNECT', 'ABANDON', 'EXITWITHTIMEOUT') THEN 1 END) AS total,
ROUND(100.0 * COUNT(CASE WHEN event = 'ABANDON' THEN 1 END)
/ NULLIF(COUNT(CASE WHEN event IN ('CONNECT', 'ABANDON', 'EXITWITHTIMEOUT') THEN 1 END), 0), 1) AS abandon_pct
FROM queue_log
WHERE time > NOW() - INTERVAL '24 hours'
AND event IN ('CONNECT', 'ABANDON', 'EXITWITHTIMEOUT')
GROUP BY hour, queuename
ORDER BY hour DESC;My take: The industry 5% benchmark is lazy. What matters is abandon rate by queue and by time-of-day. A 3% overall rate can hide a 15% rate during lunch hours when staffing drops. We wrote more about this in why the 5% benchmark is a lie.
Reduce perceived wait time with queue announcements:
; queues.conf — announcements that reduce abandonment
[support-queue]
announce-frequency=45 ; position update every 45 sec
announce-holdtime=once ; estimated wait on entry
announce-position=yes ; "You are caller number 3"
periodic-announce=custom/hold-message ; branded hold message
periodic-announce-frequency=604. Occupancy Rate
Agent utilization — the percentage of time agents spend handling calls versus waiting.
Healthy range: 70-85%.
Below 70% means agents are idle — you are overstaffed for current volume. Above 85% means agents have no breathing room between calls — burnout is coming.
The hidden trap: Center-wide occupancy is 75%, which looks healthy. But drill into teams: Team A is at 30% (overstaffed), Team B is at 95% (burning out). The average hides the problem.
-- Per-agent occupancy, current shift
WITH agent_events AS (
SELECT
agent,
event,
time,
LEAD(time) OVER (PARTITION BY agent ORDER BY time) AS next_event_time
FROM queue_log
WHERE time > DATE_TRUNC('day', NOW()) + INTERVAL '8 hours'
AND event IN ('CONNECT', 'COMPLETEAGENT', 'COMPLETECALLER', 'PAUSE', 'UNPAUSE')
)
SELECT
agent,
ROUND(100.0 * SUM(CASE
WHEN event = 'CONNECT' THEN EXTRACT(EPOCH FROM (COALESCE(next_event_time, NOW()) - time))
ELSE 0 END)
/ EXTRACT(EPOCH FROM (NOW() - DATE_TRUNC('day', NOW()) - INTERVAL '8 hours')), 1) AS occupancy_pct
FROM agent_events
GROUP BY agent
HAVING EXTRACT(EPOCH FROM (NOW() - DATE_TRUNC('day', NOW()) - INTERVAL '8 hours')) > 0
ORDER BY occupancy_pct DESC;5. Wait Time (Average Speed of Answer)
How long customers wait before an agent picks up.
| Wait Time | Customer State | Your Action |
|---|---|---|
| 0-30 sec | Satisfied, normal | None needed |
| 30-60 sec | Getting impatient | Monitor trend |
| 60-120 sec | 30-40% will abandon | Escalate staffing |
| 120+ sec | Almost no one waits | Emergency response |
Wait time is the most visceral metric — it is what customers feel. SLA is a management abstraction. Wait time is the customer's experience.
How to Implement: 4 Steps
Step 1: Choose the Right Tool
Not all monitoring tools are equal. For Asterisk environments, you need:
- —Direct PBX integration — no manual data imports, no CSV parsing
- —Sub-5-second latency — minutes-old data is not real-time
- —Configurable alerts — thresholds that match your specific queues
- —Historical context — real-time data with 24-hour lookback
Most teams start with Grafana + custom queries against queue_log. This works until you need drill-down, alerts, and agent-level views — then the custom SQL approach collapses under maintenance burden.
The tool landscape: QueueMetrics is the legacy option (Java-based, CHF 8/agent/month). Asternic is another choice but lacks real-time capability. Grafana is free but requires significant custom work. Astervis provides all five metrics out of the box with 3-second refresh.
Tired of guessing what's happening in your queues?
Astervis gives you 30+ real-time charts, operator KPIs, and CRM integration for your Asterisk PBX. Self-hosted. Install in 5 minutes. From $119/mo flat — unlimited operators.
Step 2: Configure Alerts Properly
Three tiers, three channels:
| Severity | Trigger | Channel | Who |
|---|---|---|---|
| Critical | SLA < 70%, Abandon > 12% | SMS + phone | Shift manager |
| Warning | AHT rising 20%+, team at 95% occupancy | Slack/Teams | Team lead |
| Informational | Trends at end of shift | Operations |
In Asterisk, you can trigger alerts via AMI events:
; extensions.conf — custom alert on queue overflow
[queue-alerts]
exten => s,1,Set(QWAIT=${QUEUE_WAITING_COUNT(support-queue)})
exten => s,n,GotoIf($[${QWAIT} > 15]?critical)
exten => s,n,GotoIf($[${QWAIT} > 8]?warning)
exten => s,n,Hangup()
exten => s,n(warning),UserEvent(QueueWarning,Queue:support-queue,Waiting:${QWAIT})
exten => s,n,Hangup()
exten => s,n(critical),UserEvent(QueueCritical,Queue:support-queue,Waiting:${QWAIT})
exten => s,n,System(/usr/local/bin/send-sms-alert.sh "Queue critical: ${QWAIT} waiting")
exten => s,n,Hangup()My take: The biggest mistake is setting thresholds too tight. SLA < 85% triggering 15 alerts per day means everyone ignores them within a week. Set critical alerts for genuine emergencies, not mild deviations. Alert fatigue kills faster than missed metrics.
Step 3: Role-Based Dashboards
Different roles need different views:
| Role | What They See | Update Frequency |
|---|---|---|
| Executive | Overall SLA, daily trend, cost per call | Every 5 minutes |
| Shift Manager | All 5 metrics, per-queue drill-down, alert history | Every 3-5 seconds |
| Team Lead | Per-agent AHT, occupancy, call outcomes | Every 10 seconds |
| Agent | Personal stats, queue position (limited view) | Every 30 seconds |
The supervisor needs all the detail. The executive needs a single number and a color. Do not show the executive 6 widgets — show them one SLA number and whether it is green.
For the supervisor-specific setup, see our complete supervisor dashboard guide. For team-facing displays, see the wallboard setup guide.
Step 4: Connect Data to Action
The dashboard is not the destination — it is the trigger. Every red threshold should map to a specific action:
- —High abandon rate → activate overflow routing to backup queue
- —Rising AHT → listen to recent calls, identify if a new issue type is flooding in
- —Agent occupancy > 90% → pull agents from outbound campaigns
- —SLA dropping → trigger callback offer for queued callers
; queues.conf — automatic callback when wait exceeds threshold
[support-queue]
context=queue-callback ; route to callback context on timeout
timeout=120 ; 2 minutes max wait before callback offerWithout predefined playbooks, real-time data just creates real-time anxiety.
3 Mistakes That Kill Monitoring Programs
Mistake 1: AHT Obsession
Every call center I have audited tracks AHT. Most of them use it wrong.
Managers push agents to cut calls short. Agents rush through conversations, miss the root cause, and the customer calls back. AHT looks great. First Call Resolution is quietly dying.
Fix: Track AHT alongside FCR and repeat-contact rate. If AHT goes down but callbacks go up, your agents are not getting faster — they are getting worse.
Mistake 2: Static Alert Thresholds
Tuesday at 2 PM has different normal ranges than Saturday at 8 AM. A static "SLA < 80%" alert fires constantly during predictable peak hours and never fires during the slow periods when something actually breaks.
Fix: Time-based thresholds. Peak hours get wider tolerance. Off-peak gets tighter monitoring. Or use anomaly detection — alert when metrics deviate from the pattern for that specific day and hour.
Mistake 3: Dashboard Without Playbook
You see Tuesday afternoons are consistently tough. Every Tuesday, the team scrambles. Nothing changes.
Fix: Every insight must map to a scheduled action. Tuesday is tough → pre-schedule two extra agents for Tuesday 1-5 PM. Proactive staffing beats reactive scrambling every time.
Implementation Checklist
Score yourself:
| Question | Yes/No |
|---|---|
| Can you see queue depth right now, in under 5 seconds? | |
| Are critical alerts configured with the right thresholds? | |
| Do managers make staffing decisions from the dashboard? | |
| Are you tracking quality (FCR), not just speed (AHT)? | |
| Does every red alert have a documented response playbook? | |
| Are dashboards role-specific (exec vs supervisor vs lead)? |
3+ "no" answers = you are losing money every day you delay implementation.
Get Started
Astervis connects to your Asterisk PBX and delivers all 5 metrics in under 5 minutes. No Grafana configuration, no custom SQL, no Java dependencies.
- —30+ real-time charts with 3-second refresh
- —Configurable color thresholds per queue
- —Audio and visual alerts on critical deviations
- —Role-based dashboards for executives, supervisors, and team leads
- —Operator performance tracking built in
Related reading:
- —Call Center Supervisor Dashboard Guide — the 6-widget layout for shift managers
- —Asterisk Call Center Wallboard Guide — team-facing displays
- —5 Call Center KPIs That Drive Revenue — choosing what to measure
- —First Call Resolution: Why 70% Is Wrong — the quality metric most dashboards miss
- —Your AHT Is Lying — why speed metrics mislead
- —Call Abandonment: Why 5% Is a Lie — rethinking abandon thresholds
- —Agent Burnout and Monitoring — when your dashboard causes the problem
- —Fix Asterisk Call Drops — troubleshooting trunk failures
Stop guessing. Start monitoring.
See your Asterisk call center's real performance — queue wait times, agent activity, trunk usage, and 30+ charts. Self-hosted on your server. Install in 5 minutes. No credit card required.
From $119/mo flat. Unlimited operators. 14-day free trial.