80%
Helpdesk default
Closed after one touch
70%
Net of repeats
No return within seven days
65%
Strict one-touch
No repeat and no transfer
1.45
Contacts per issue
At 70% FCR
What is the first contact resolution formula?
FCR = issues resolved on the first contact ÷ issues raised × 100.
Two words carry the weight. The denominator is issues, not contacts: a customer who emails, then rings, then emails again about the same refund is one issue with three contacts, and counting it three times buries the failure in volume. And "resolved on the first contact" means the customer didn't need to come back, which you can only know after waiting. An issue closed at 3pm and reopened the next morning was never resolved on first contact, whatever the ticket said at 3pm.
That waiting period is the repeat contact window. It is the one setting every FCR number depends on, and most reports never state it.
At a glance
One formula, one month, three honest FCR numbers
What does FCR look like on one month?
Take Harbor & Pine's 6,000 new issues across chat, email and phone in a month. The helpdesk reports 4,800 of them as closed after a single touch, so the dashboard reads 80%.
Now apply a seven-day window. 600 of those 4,800 customers contacted the team again about the same thing within a week: some replied on the same thread, more opened a fresh ticket or rang instead. That leaves 4,200 issues that genuinely ended at the first contact, or 70%.
Then decide about transfers. 300 of the remaining 4,200 were resolved during the first contact, but only after the customer was passed from the person who picked up to someone who could help. Count those and FCR is 70%. Exclude them, as a strict one-touch definition does, and it is 3,900 of 6,000, or 65%.
| Definition | Resolved first time | FCR |
|---|---|---|
| Closed after one touch (helpdesk default) | 4,800 | 80% |
| No repeat contact within seven days | 4,200 | 70% |
| No repeat, and no transfer inside the contact | 3,900 | 65% |
All three are honest arithmetic on the same month. Only the last two describe what the customer experienced, and the gap between 80% and 65% is fifteen points of definition, not performance. The rest of this post uses the 70% figure: net of repeats, with transfers counted and reported beside it.
The window is a setting, and it moves the number on its own. Here is the same month read with four different windows.
The same month, four repeat windows
- 24 hours76.5%210 repeats caught
- 72 hours72.8%430 repeats caught
- 7 days70.0%600 repeats caught
- 14 days68.0%720 repeats caught
Most of the repeats arrive early. Nearly three quarters of the seven-day total, 430 of 600, had come back inside 72 hours, which is why a 24-hour window looks so flattering: it misses the customer who tried the fix the next evening and found it didn't work.
What counts as the first contact?
The first time the customer reached you about this issue, on any channel. Three traps catch most teams.
Channel switches. A customer who gets no joy from chat and picks up the phone is the most common repeat contact there is, and a per-channel report can't see it, because each channel's queue only sees its own tickets. Phone FCR looks fine, chat FCR looks fine, and the customer had to try twice. Match repeat contacts on the customer, not the ticket: email address or phone number, across every channel, inside the window.
One issue, three contacts, three channels
- Contact 1 · Chat · Mon 10:04Asks where a refund is. Told it takes 5–7 days.
- Contact 2 · Phone · Wed 16:20Rings: the refund hasn't arrived. Told to wait.
- Contact 3 · Email · Sat 09:12Emails a screenshot. A person finds the refund failed.
Each channel's report sees one contact and calls it resolved. The customer saw one issue that took three tries and six days.
The window itself. Too short and the customer who tried your answer on Tuesday and found it didn't work on Thursday counts as a success. Too long and an unrelated question a fortnight later counts against the first one. Seven days is a common choice for general support; billing or delivery issues sometimes need longer. Pick one, write it beside the number, and don't change it, because changing it breaks every trend line you have.
Transfers. A transfer inside the same call or chat is still the first contact from the customer's side: they didn't have to come back. It is still a cost, and a sign that routing put the issue in front of the wrong person. Count transfers if you like, but report the transfer rate next to FCR so the definition can't hide them. In the worked month that is 300 of 6,000 issues, or 5%.
| Situation | First contact resolved? | Why |
|---|---|---|
| Answered in chat, no further contact within seven days | Yes | The issue ended at the first contact |
| Answered in chat, customer rings two days later about the same thing | No | A repeat inside the window, on another channel |
| Transferred within the same call, then solved | Yes, but report it | The customer didn't have to come back; routing cost a transfer |
| Email thread with four replies, never reopened | Yes | One contact, one thread, nothing started again |
| Customer writes again three weeks later about something new | Yes | Outside the window, and a different issue |
| AI agent answered, customer came back the next day | No | The same rule as for a person |
Does an AI resolution count as first contact resolution?
Yes, if the customer's issue was solved and they didn't come back inside the window. The customer doesn't care who answered. But an AI-handled conversation brings two traps of its own.
The first is the label. An AI conversation that ended without a person is not the same as one that resolved anything, and a customer who closes the chat window in frustration looks identical to one who got their answer, until they turn up on the phone. Apply the same repeat window to AI conversations as to human ones, and treat an AI conversation that handed over to a person as a transfer.
The second is the mix. Say 1,500 of the 4,200 first-contact resolutions in the example were simple questions, such as order status or a password reset, and when Harbor & Pine turned on its AI agent, the agent took those 1,500 issues. 1,350 stay answered; 150 customers come back and reach the team. The human desk now sees 4,500 issues, of which 2,700 are resolved first time: its FCR drops from 70% to 60%, and nobody on the team got any worse. Combined FCR is (1,350 + 2,700) ÷ 6,000 = 67.5%.
What happens to FCR when the AI takes the easy issues
- Human FCRBefore70%4,200 of 6,000After60%2,700 of 4,500
- AI FCRBeforeNo AI yetAfter90%1,350 of 1,500
- Combined FCRBefore70%4,200 of 6,000After67.5%4,050 of 6,000
Report three numbers, not one
AI FCR, human FCR and combined FCR, all on the same window. The human figure falls when the easy issues move to the AI; the combined figure tells you whether the customer is better off.
In that example the combined figure fell 2.5 points, because 150 AI answers didn't hold. Those 150 are the most useful list in the report: the topics where the answer needs fixing. Fix the answers behind them and combined FCR climbs back past where it started. If half of the 150 had held, it would have been (1,425 + 2,700) ÷ 6,000 = 68.75%; all of them, back to 70%, with 1,500 issues off the team's desk. The containment, deflection and resolution post works through the same distinction for AI-only metrics.
How does FCR relate to AHT, CSAT and deflection?
Average handle time. Every repeat contact is another handle time. With an AHT of 6.8 minutes and failed issues taking 2.5 contacts on average, 70% FCR means 0.7 × 1 + 0.3 × 2.5 = 1.45 contacts per issue, or 9.9 minutes of agent time per issue. Cut AHT by 10% to 6.1 minutes by rushing calls, lose ten points of FCR, and it is 0.6 + 0.4 × 2.5 = 1.6 contacts, or 9.8 minutes per issue. The handle time report improves, the minutes per issue barely move, and 600 more customers had to get back in touch. Work your own figure out with the average handle time calculator, then multiply it by contacts per issue.
Faster calls, same minutes, more customers chasing
- Contacts per issue
- 1.45
- Minutes per issue
- 9.9
- Issues that needed a repeat
- 1,800
- Contacts per issue
- 1.6
- Minutes per issue
- 9.8
- Issues that needed a repeat
- 2,400
CSAT. Customers who had to come back rate you lower, so FCR is usually the strongest single driver of satisfaction a support team controls. Watch the survey timing, though: a CSAT survey sent the moment a ticket closes catches the customer before they know whether the fix worked. Score it with the CSAT calculator, and split the result by whether the issue needed a second contact. The CSAT vs NPS post works through the survey side.
Deflection. Net deflection and FCR share a definition problem: both subtract the customers who came back. Use one window for both, and the deflection rate calculator and your FCR report will agree about how many issues really ended at the first answer.
First response time. An SLA on first response says how fast you replied, not whether the reply ended it. A quick reply that asks the customer for their order number is fast and is not resolution. Read the SLA calculator and FCR side by side.
What is a good first contact resolution rate?
A common rule of thumb puts a healthy FCR for a general support queue somewhere around 70% to 75%, measured net of repeat contacts. A figure above 90% more often means a loose definition than an exceptional team, and a figure below 60% usually points at routing, missing knowledge or policies that force a callback. The benchmark matters less than your own month against your own previous month, on a definition that doesn't change.
What can Wiredesk tell you about first contact?
When a conversation ends, Wiredesk reads the transcript once and files a summary, a topic, the customer's sentiment and one of four outcomes: resolved, handed to you, message taken or abandoned. The analytics page shows a resolution rate (resolved conversations as a share of those with an outcome) beside the previous period, along with the handover rate and the median time to a person.
That resolution rate is per conversation, and it is a model's reading of the transcript, so treat it as the gross figure. Wiredesk doesn't check whether the same customer came back. The conversations export carries the channel, contact, start time, outcome and topic of each conversation, and repeats can be joined on contact.
How far that join reaches depends on how the customer got in touch. A call is keyed by phone number and an email by address. An anonymous website chat is keyed to the visitor's browser and exports as "Web visitor", so it joins with nothing else. A chat from a verified visitor, whose email your site signs, is filed under that email address, so their chats and emails share one contact. Withheld caller IDs all share one label. So the file can net repeats within phone, within email, and across chat and email for signed-in customers, but it can't tie a call to an email from the same person.
How do you measure first contact resolution in Wiredesk? Step by step
Step 1: Start from the resolution rate on Analytics
Open Analytics and pick a range: 7, 30 or 90 days. The resolution rate in the Results band is resolved conversations as a share of those with an outcome, beside the same length of time before it. It is the gross, per-conversation ceiling on your AI FCR: the true figure can only be lower once repeats come out.

Step 2: Open a contact to see their history
Contacts lists the people who have been in touch, most recent first: an email address, a phone number or a chat visitor. Open one and you see their conversations, newest first, with the channel, agent and topic of each. Two conversations on the same topic a few days apart is a repeat contact; you don't need a report to spot one.

On an FCR report, that customer is one issue, not three, and it wasn't resolved on the first contact. Measured channel by channel, the same history could pass for three first-contact resolutions.
Step 3: Export the conversations and find the repeats
On Conversations, choose Export CSV. In a spreadsheet, sort by contact and start time, then flag every conversation whose contact started another one within seven days. Check the topics match before you count it: a customer asking about returns on Monday and sizing on Friday has two issues, not a repeat. Remember the limits from the section above: an anonymous chat exports as "Web visitor", and a call is always its own contact, so a chat followed by a call is two contacts.
Step 4: Split AI, human and combined
Conversations with the outcome Resolved and no repeat in the window are AI first-contact resolutions. Handed to you is a transfer: if the person who took over solved it and the customer didn't come back, it counts toward combined FCR, reported beside the transfer rate. Your helpdesk's own data covers the issues your team handled without the agent.
Step 5: Fix the answers that didn't hold
The repeats behind AI conversations are your worklist. Where the agent got stuck on Analytics lists the topics where the agent took a message instead of answering; the repeats add the topics where it answered and the answer didn't hold. Open each conversation, correct the answer in the agent's knowledge, and measure the same window again next month.
