Your FCR is 73%. Your ops team is celebrating. And your customers are quietly finding alternatives.
My take: I have looked at FCR data across dozens of Asterisk-based call centers. The teams with the highest FCR numbers often have the worst repeat-contact rates. That is not a paradox — it is a measurement failure baked into how the industry defines "resolved."
The gap between a green dashboard and a deteriorating customer base is what happens when you optimize for the benchmark instead of the outcome.
The 70% Myth: Where It Came From and Why It Stuck
First Call Resolution is one of the most cited metrics in the call center industry. SQM Group puts the "world-class" FCR threshold at 80%, while most surveys place the average between 70-75%. So organizations set 70% as the target, hit it, and move on.
The problem: that number measures whether a call was logged as resolved. It does not measure whether the customer's problem was actually solved.
Those are not the same thing. Not even close.
In Asterisk environments, this is especially problematic. The CDR (Call Detail Records) system tracks call disposition — ANSWERED, NO ANSWER, BUSY, FAILED — but knows nothing about whether the customer's issue was resolved. Your Asterisk CDR reporting might show a clean ANSWERED record for a call where the agent just said "let me check and call you back" and never did.
My take: The 70% benchmark survives because it is easy to hit. Any team that closes tickets aggressively can report 70% FCR. That does not make it meaningful.
How Standard FCR Targets Break Your Asterisk Operation
1. They reward closure, not resolution
When agents know their performance is judged on FCR, they close calls. A customer calls about a billing discrepancy — the agent apologizes, makes a goodwill credit, and marks the issue resolved. The credit posts incorrectly next month. The customer calls again. That second call never gets linked to the first.
Your FCR stays clean. Your customer's trust does not.
In Asterisk, you can see this pattern in CDR data. Here is the query that exposes it:
-- Find "resolved" calls followed by callbacks from the same number within 7 days
SELECT
a.src AS caller_number,
a.calldate AS first_call,
b.calldate AS callback,
EXTRACT(EPOCH FROM (b.calldate - a.calldate)) / 3600 AS hours_between,
a.dstchannel AS first_agent,
b.dstchannel AS callback_agent
FROM cdr a
JOIN cdr b ON a.src = b.src
AND b.calldate > a.calldate
AND b.calldate < a.calldate + INTERVAL '7 days'
AND b.disposition = 'ANSWERED'
WHERE a.disposition = 'ANSWERED'
AND a.dst IN (SELECT extension FROM queue_members)
AND a.calldate > NOW() - INTERVAL '30 days'
ORDER BY hours_between ASC
LIMIT 50;This query finds every "resolved" call that generated a callback within a week. Run it on your CDR database — the results are usually uncomfortable.
2. They punish agents who do the right thing
Consider an agent who identifies that a customer's recurring issue stems from a configuration error three levels deep. Fixing it properly takes 12 minutes and a warm transfer to tier-2. Another agent offers a workaround in 4 minutes and marks it resolved.
By FCR standards, the second agent performed better. By any meaningful standard, the first agent is your best employee.
Your operator performance tracking should account for this. Look at resolution durability, not just first-call closure rate.
3. They make complex calls look like failures
A single FCR rate applied to billing disputes, technical faults, account escalations, and simple information requests is statistically meaningless.
- —60% FCR on multi-system technical issues? Outstanding.
- —90% FCR on basic FAQ calls? Unremarkable.
- —Average them together? You learn nothing.
This is why your call center KPIs need segmentation by queue. In Asterisk, each queue represents a different contact type — segment your FCR accordingly:
; queues.conf — separate queues enable per-type FCR tracking
[billing-support]
strategy=leastrecent
timeout=30
wrapuptime=15
member => SIP/1001
member => SIP/1002
[technical-tier1]
strategy=fewestcalls
timeout=45
wrapuptime=30 ; longer wrap for complex issues
member => SIP/2001
member => SIP/2002
[account-changes]
strategy=ringall
timeout=20
wrapuptime=10
member => SIP/3001With separate queues, you can measure FCR per contact type rather than blending everything into one meaningless number.
4. They ignore customer effort
A customer who gets their issue "resolved" after 18 minutes on hold, two transfers, and three verification loops experienced something very different from a customer who resolved the same issue in 5 minutes. The FCR metric treats them identically.
My take: Customer effort is the hidden variable that separates companies that grow from companies that churn. A "resolved" call with high effort is worse than an unresolved call where the agent was honest about timelines. Customers forgive delays — they do not forgive runarounds.
Measure effort through call abandonment patterns and handle time distribution. The combination tells you more than FCR ever will.
What FCR Actually Measures (And Its Blind Spots)
FCR, in its raw form, answers one narrow question: did the customer call again within a defined window about the same issue?
That window matters enormously. Organizations using a 7-day lookback report FCR 10-15 percentage points higher than those using 30 days — for the same operational reality.
Here is how to calculate your true FCR from Asterisk CDR data with different windows:
-- True FCR comparison: 7-day vs 14-day vs 30-day windows
WITH first_contacts AS (
SELECT
src,
MIN(calldate) AS first_call,
dcontext AS queue_context
FROM cdr
WHERE disposition = 'ANSWERED'
AND calldate > NOW() - INTERVAL '60 days'
AND dcontext LIKE '%queue%'
GROUP BY src, dcontext,
DATE_TRUNC('day', calldate)
),
callbacks AS (
SELECT
fc.src,
fc.first_call,
fc.queue_context,
COUNT(CASE WHEN c.calldate < fc.first_call + INTERVAL '7 days' THEN 1 END) AS callbacks_7d,
COUNT(CASE WHEN c.calldate < fc.first_call + INTERVAL '14 days' THEN 1 END) AS callbacks_14d,
COUNT(CASE WHEN c.calldate < fc.first_call + INTERVAL '30 days' THEN 1 END) AS callbacks_30d
FROM first_contacts fc
LEFT JOIN cdr c ON fc.src = c.src
AND c.calldate > fc.first_call
AND c.calldate < fc.first_call + INTERVAL '30 days'
AND c.disposition = 'ANSWERED'
AND c.dcontext = fc.queue_context
GROUP BY fc.src, fc.first_call, fc.queue_context
)
SELECT
queue_context,
COUNT(*) AS total_first_contacts,
ROUND(100.0 * COUNT(CASE WHEN callbacks_7d = 0 THEN 1 END) / COUNT(*), 1) AS fcr_7day,
ROUND(100.0 * COUNT(CASE WHEN callbacks_14d = 0 THEN 1 END) / COUNT(*), 1) AS fcr_14day,
ROUND(100.0 * COUNT(CASE WHEN callbacks_30d = 0 THEN 1 END) / COUNT(*), 1) AS fcr_30day
FROM callbacks
GROUP BY queue_context
ORDER BY total_first_contacts DESC;If your 7-day FCR is 78% but your 30-day FCR is 61%, you do not have a 78% resolution rate. You have a 61% resolution rate with a flattering measurement window.
The Three Metrics That Replace FCR
The goal is not "resolved on first call." The goal is "right first time." That distinction requires different dimensions.
1. Repeat Contact Rate with Cause Linkage
Repeat contact rate is more honest than FCR because it counts the customer experience, not the agent's classification.
-- Repeat contact rate by agent: who generates the most callbacks?
SELECT
first_call.dstchannel AS agent,
COUNT(DISTINCT first_call.src) AS unique_callers,
COUNT(DISTINCT callback.src) AS callers_who_called_back,
ROUND(100.0 * COUNT(DISTINCT callback.src) / NULLIF(COUNT(DISTINCT first_call.src), 0), 1) AS repeat_rate_pct
FROM cdr first_call
LEFT JOIN cdr callback ON first_call.src = callback.src
AND callback.calldate > first_call.calldate
AND callback.calldate < first_call.calldate + INTERVAL '14 days'
AND callback.disposition = 'ANSWERED'
WHERE first_call.disposition = 'ANSWERED'
AND first_call.calldate > NOW() - INTERVAL '30 days'
AND first_call.dcontext LIKE '%queue%'
GROUP BY first_call.dstchannel
HAVING COUNT(DISTINCT first_call.src) >= 10
ORDER BY repeat_rate_pct DESC;This is the query that changes minds. When supervisors see that Agent A has 75% FCR and 35% repeat contact rate while Agent B has 68% FCR and 12% repeat contact rate — the conversation shifts from "who closes calls" to "who actually solves problems."
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.
2. Contact Reason Segmentation
Track FCR separately by contact type. Each has a different natural rate, a different root cause when it fails, and requires a different intervention.
In Asterisk, your queues are your segmentation. Configure separate queues for each contact type and measure independently.
| Queue | Natural FCR | Alarm Threshold | Notes |
|---|---|---|---|
| billing-support | 75-85% | < 65% | High volume, usually straightforward |
| technical-tier1 | 50-65% | < 40% | Expected escalations to tier-2 |
| account-changes | 85-95% | < 75% | Process-driven, should be high |
| complaints | 40-55% | < 30% | Often requires follow-up |
My take: If you have one queue for everything, your FCR is useless. Split your queues first, then measure. The investment in queue architecture pays for itself in analytics clarity.
3. Resolution Durability Score
This is the metric I wish more teams used. It combines FCR with a longer lookback to score how "durable" each resolution is:
-- Resolution durability: percentage of calls with NO callback in 30 days
-- Grouped by agent to find your most effective resolvers
SELECT
agent_channel,
total_calls,
no_callback_30d,
ROUND(100.0 * no_callback_30d / total_calls, 1) AS durability_score,
avg_handle_time_sec
FROM (
SELECT
a.dstchannel AS agent_channel,
COUNT(*) AS total_calls,
COUNT(CASE WHEN b.src IS NULL THEN 1 END) AS no_callback_30d,
ROUND(AVG(a.billsec)) AS avg_handle_time_sec
FROM cdr a
LEFT JOIN cdr b ON a.src = b.src
AND b.calldate > a.calldate
AND b.calldate < a.calldate + INTERVAL '30 days'
AND b.disposition = 'ANSWERED'
WHERE a.disposition = 'ANSWERED'
AND a.calldate BETWEEN NOW() - INTERVAL '60 days' AND NOW() - INTERVAL '30 days'
AND a.dcontext LIKE '%queue%'
GROUP BY a.dstchannel
HAVING COUNT(*) >= 20
) sub
ORDER BY durability_score DESC;Agents with high durability scores and slightly above-average handle times? Those are your best people. They take the extra minute to solve problems correctly — and it shows in 30-day outcomes.
The Cost of Bad FCR: A Real Number
Every false "resolved" call costs money when the customer calls back. Here is the math:
| Variable | Value |
|---|---|
| Monthly calls | 5,000 |
| Reported FCR | 73% |
| True FCR (30-day window) | 58% |
| Calls misclassified as resolved | 750 |
| Average cost per call | $4.50 |
| Monthly cost of false FCR | $3,375 |
| Annual cost | $40,500 |
That $40,500 does not include the customer lifetime value destroyed by repeat contacts. Research from the Effortless Experience (Dixon, Toman, DeLisi) shows that each additional contact about the same issue reduces customer loyalty by 10-15%.
For a 50-agent call center handling 5,000 calls per month, fixing the 15-point gap between reported FCR and true FCR pays for itself in the first quarter.
Asterisk Configuration for Better FCR Measurement
Your Asterisk configuration directly affects your ability to measure FCR accurately. Here are the configs that matter:
Caller ID Linking
Enable reliable caller identification so repeat contacts can be tracked:
; sip.conf or pjsip.conf — preserve original caller ID
[general]
sendrpid=yes
trustrpid=yes
; Queue member settings
[queue-agent](!)
setinterfacevar=yes ; expose MEMBERINTERFACE for trackingWrapup Time Configuration
Give agents enough wrapup time to properly document resolutions. Rushed wrapup = bad FCR data:
; queues.conf — wrapup time per queue type
[billing-support]
wrapuptime=15 ; 15 seconds for straightforward issues
[technical-tier1]
wrapuptime=45 ; 45 seconds for complex technical issues
; agents need time to document the actual resolution,
; not just mark "resolved" to get the next call
[complaints]
wrapuptime=60 ; full minute for complaint documentationMy take: Most Asterisk installations set wrapuptime=0 or wrapuptime=5. This is why FCR data is garbage — agents rush through disposition because the next call is already ringing. Give them 30-45 seconds. The data quality improvement alone justifies it.
CDR Custom Fields for Resolution Tracking
Use Asterisk's CDR custom fields to capture resolution status:
; extensions.conf — set resolution status via DTMF or dialplan
[macro-queue-wrapup]
exten => s,1,Set(CDR(resolution)=${WRAPUP_STATUS})
exten => s,n,Set(CDR(contact_reason)=${QUEUE_CONTEXT})
exten => s,n,Set(CDR(agent_notes)=${AGENT_NOTES})This gives you per-call resolution data that you can query alongside the callback analysis above.
Building a Real FCR Dashboard
A useful FCR dashboard shows these five things on one screen:
- —FCR by queue — not blended, never blended
- —Repeat contact rate by agent — the honesty metric
- —Resolution durability trend — 30-day trailing, by week
- —Callbacks per hour heatmap — when do false resolutions surface?
- —Cost of repeat contacts — the CFO cares about this number
Your supervisor dashboard should surface these alongside real-time queue health from your wallboard. The combination gives supervisors both tactical (right now) and strategic (this month) visibility.
Astervis provides all five views out of the box — with automatic callback linking, per-queue segmentation, and agent-level durability scoring. No SQL queries required.
The Bottom Line
FCR is not a bad metric — it is a badly measured one. The 70% benchmark is lazy, the 7-day window is flattering, and the single blended number is useless.
Here is what to do instead:
- —Split your queues by contact type — billing, technical, account, complaints
- —Extend your lookback to 30 days — accept the drop, it is revealing reality
- —Track repeat contacts by agent — find your real problem solvers
- —Measure resolution durability — the 30-day no-callback rate
- —Give agents proper wrapup time — 30-45 seconds minimum per queue
The benchmark was never the point. Customers who do not call back because their problem was genuinely solved — that is the point.
Related reading:
- —Your Average Handle Time Is Lying — another metric that distorts reality when measured wrong
- —5 Call Center KPIs That Actually Drive Revenue — the metrics that matter alongside FCR
- —Call Abandonment Rate: Why the 5% Benchmark is a Lie — the companion piece on misleading benchmarks
- —How to Monitor Asterisk Queues in Real-Time — the foundation for per-queue FCR tracking
- —Asterisk Operator Performance Tracking — agent-level metrics beyond FCR
- —Call Center Agent Burnout — why punishing agents for low FCR backfires
- —The Complete Guide to Asterisk Call Center Optimization — the big picture
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.