First Call Resolution (FCR): Definition, Formula and How to Improve Your FCR Rate

The short version: First call resolution (FCR) is the share of support requests that are fully resolved at the first contact, with no follow-up call, reopened ticket or hand-off needed. In IT support, FCR rate = requests resolved at first contact divided by all requests in the period. Agree the counting rules before you quote a number, because they change the result more than the team does.

Ask an IT service desk manager which metric best shows whether the desk is working, and many will say first call resolution. It is easy to explain, it matches what a user wants (fix it now, once), and it moves when training, tools and knowledge improve. It is also easy to measure badly. This guide explains what FCR means, how to calculate the FCR rate, what drives it, and how to improve it without gaming the number.

We read the outside definition on 28 October 2026: the Wikipedia article on first call resolution (checked 2026-10-28). Where we describe how Brocent publishes its commitments, the details come from our SLA page.

What is first call resolution?

The Wikipedia article (checked 2026-10-28) describes first call resolution, or first contact resolution (FCR), as a metric that measures a call centre's performance at resolving customer interactions on the first call or contact, which removes the need for follow-up contacts. It adds that, ideally, FCR means no repeat calls or contacts are needed from the customer's point of view.

The same article separates two names for the same idea:

• First call resolution: measured for a call centre, that is, for voice calls.
• First contact resolution: measured for any channel, such as chat, email, portal or phone.

For an IT service desk the second reading is the more useful one. Users reach the desk by phone, chat, email, a ticket portal and sometimes a walk-up counter, so we use "FCR" for resolution at the first contact in any channel, and say "call" only when the channel is voice.

Three neighbouring terms are easy to confuse with it:

• First-level resolution: the ticket is solved by the first support level (L1) without passing to L2 or L3. A ticket can be solved at L1 after three conversations, so this is not the same as FCR. Our article on L1, L2 and L3 support levels explains the levels.
• Mean time to resolve: the average elapsed time from logging to resolution, covered in the guide to MTTR, MTBF and MTTA. It measures speed; FCR measures whether it took one contact.
• Reopen rate: the share of resolved tickets that come back. It is the mirror image of FCR, and the two should be read together.

How do you calculate the FCR rate?

The formula is simple:

FCR rate = (requests resolved at the first contact ÷ total requests handled in the period) × 100

An illustrative example, with invented numbers to show the arithmetic: in a month the service desk handles 200 requests. For 130 of them the user did not need to contact the desk again about the same issue and the ticket was not reopened. The FCR rate is 130 ÷ 200 = 65%.

The hard part is deciding what counts as "resolved at the first contact". Settle these points once, write them down, and keep them stable.

1. What is a request? Count incidents and service requests, or only incidents? A password reset and a failed server are both tickets, but they behave very differently. Many desks report FCR separately for the two.
2. How long is the repeat window? If the same user contacts the desk about the same issue within, say, two business days, is that a repeat? The Wikipedia article notes that "no repeat calls in a given timeframe" is one of the most common methods; the window is yours to choose, but it must be fixed in advance.
3. Who decides the issue is the same? Linking follow-ups to the original ticket is a manual judgement unless the system matches them. Decide who does this and how.
4. Does a hand-off count as a miss? If L1 passes a ticket to L2 and the user never has to call again, was it resolved at first contact? Most definitions say no, since the first contact did not resolve it. State your position.
5. Which tickets are excluded? Planned work, proactive monitoring alerts and tickets logged on someone's behalf usually should not count. List the exclusions.

How is FCR measured: system data or the customer's view?

The Wikipedia article describes two families of method (checked 2026-10-28). Internal methods measure operational performance: agent logging, speech analytics, quality monitoring, reopened issues and counting repeat call volume. External methods ask the customer, for example through a post-call survey. It also says FCR is ideally judged from the customer's point of view, since only the customer knows whether the issue is truly resolved.

For an IT desk, a practical approach combines both:

• System signal: no reopen and no new ticket from the same user on the same topic inside the repeat window. This is cheap and covers every ticket.
• Customer signal: a one-question check after closure, such as "Was your issue fully resolved on this contact?" Sample it, because asking every user every time breeds survey fatigue.
• Reconciliation: compare the two each quarter. If the system says 70% and users say 55%, the desk is closing tickets that are not really fixed.

What is a good FCR rate for IT support?

There is no universal figure, and we will not quote one. Published benchmarks often mix call centres of different kinds, and an IT desk that handles mostly password resets will score higher than one that supports complex line-of-business systems. A better way to judge a number:

• Compare against your own history under the same counting rules.
• Compare by category. Password resets, access requests and software installs should resolve at first contact most of the time. Network faults and application errors often cannot.
• Compare with the reopen rate and user satisfaction on the same tickets. High FCR with a high reopen rate means tickets are being closed too early.

FCR is a measure for the desk and its improvement work. It is usually not a contract promise. The Wikipedia article on SLAs does list first-call resolution as one of the indicators that SLAs commonly use, but most IT support SLAs commit to response and resolution times instead, as explained in our guide to what an SLA is in IT support. FCR tends to show up in the monthly report as a quality indicator beside those targets.

What affects first call resolution?

Seven things move FCR more than any other. Most are about equipping the first person who picks up the request.

1. Knowledge the first agent can use

If the fix to a common problem is in someone's head, only that person can resolve it at first contact. A maintained knowledge base, with short procedures written for the first-level agent, lets anyone resolve the common issues. Articles that are out of date lower FCR as surely as having none.

2. Authority and access

An agent who can diagnose a problem but cannot reset the password, unlock the account or change the permission has to hand the ticket on. Review which routine actions the first level is allowed to take, and give access to those that are safe to delegate, with logging.

3. Remote tools

Being able to see the user's screen or take control of the device (with permission) turns many "describe what you see" conversations into a fix in minutes. For distributed teams, this is often the largest single factor.

4. Training and skills coverage

First-level agents should know the top twenty issues by heart. Pair-working with L2 engineers, short refreshers after each major change, and a clear map of who knows what keep the first contact productive.

5. Quality of the first conversation

Good questions in the right order save a second call. A short script for the common categories, covering what changed, when it started, who else is affected and what the user has already tried, avoids the follow-up that asks the same things.

6. Categorisation and routing

When a ticket is mis-categorised, it lands with someone who cannot fix it. Clear categories and routing rules, ideally with a link to priority definitions as in the severity versus priority article, get the right person on the first contact.

7. The mix of requests

A desk that supports a standard device fleet with managed applications will resolve more at first contact than one that supports a patchwork of old systems. This is not a reason to ignore FCR; it is a reason to compare like with like and to treat the number as a map of where the complexity is.

Which requests usually resolve at first contact, and which do not?

Looking at the mix of requests explains most of the variation in FCR, so sort your tickets by type before you set any improvement goal.

• Likely at first contact: password resets and account unlocks, access requests that follow a standard approval, software installs from an approved catalogue, printer and mapped-drive problems with known fixes, and how-to questions.
• Sometimes at first contact: email and Microsoft 365 issues, device slowness, VPN problems and application errors. These depend on the quality of the knowledge base and the remote tools.
• Rarely at first contact: hardware failures that need a part, faults inside a carrier's network, defects in a vendor's software, and anything that needs a change window.

For the first group, a low FCR means a process or permissions problem you can fix. For the last group, a low FCR is expected, and the better question is how quickly the ticket reaches the right person with the right information, which the L1, L2 and L3 guide and the escalation matrix template address.

How can you improve first call resolution?

Work through these steps in order. Each one is cheap compared with hiring.

1. Measure a baseline. Fix the counting rules from the earlier section, then measure for a month before changing anything.
2. Find the top ten repeat categories. Sort tickets that needed more than one contact by category. The biggest few will usually account for most of the gap.
3. Write or fix a knowledge article for each. Keep them short: symptoms, quick checks, the fix, and when to escalate. Assign an owner and a review date.
4. Open up the safe actions. For each category, list the actions L1 cannot take today and why. Remove blockers that exist out of habit, and replace the rest with a scripted hand-off.
5. Equip the first level with remote tools and device information. Make asset and user details visible on the ticket so the agent does not have to ask for them.
6. Add a short first-contact checklist. Questions to ask, evidence to collect, and what to try before escalating. Include a rule that an escalated ticket carries everything the next engineer needs.
7. Close the loop with the user. Confirm the fix before closing, and agree the repeat window with the user so a return is recorded against the original ticket.
8. Review monthly. Look at FCR by category, the reopen rate, and the escalations that could have been solved at first contact. Feed what you learn into the knowledge base.

When an escalation is needed, do it cleanly. Our escalation matrix template describes who is contacted and when, so that a ticket that cannot be solved at first contact still moves without a second round of questions.

What are the traps in chasing FCR?

A target that is easy to hit by the wrong means will be hit by the wrong means. Watch for these.

• Closing early. If FCR is rewarded alone, agents mark tickets resolved before the user confirms. Pair FCR with the reopen rate and a customer check.
• Cherry-picking. Agents who avoid complex calls raise their own FCR and push the hard work on colleagues. Report FCR by category, not only as one number.
• Fighting handle time. Pressure to shorten calls and pressure to resolve at first contact pull in opposite directions. A call that takes ten minutes longer but avoids a second call is cheaper overall.
• Counting hand-offs as success. A ticket passed on after a quick look is not first-contact resolution. Define it, and audit a sample.
• Ignoring the user. A fix that works in the ticket system but not for the user leaves the user to call again, so the system shows a resolved ticket and the user feels a failure.
• Treating FCR as a proxy for quality. A desk can have a high FCR and still handle the wrong things, for example by fixing the same issue every week without removing its cause. That belongs to problem management, which is covered in our article on the major incident management process.

How does FCR relate to the SLA and to outsourcing?

FCR and SLA targets measure different things. Response and resolution targets promise speed by priority; FCR describes how often the first contact is enough. Both matter, and they interact: a desk that resolves more at first contact needs fewer escalations, which protects the resolution targets on the tickets that do need escalation. What each priority level promises is explained in our guide to P1 to P4 priority levels in an IT support SLA.

When IT support is outsourced, ask the provider how it measures FCR, which counting rules it uses, and whether the figure appears in the monthly report. The answer tells you whether the provider treats the desk as a service or as a ticket queue. It is also worth asking which routine requests the provider handles end to end. Our SLA page lists password resets and user management among the routine (P5) requests, and the 24/7 help desk service describes the desk that handles them. How the service fits into a wider contract is on the managed IT support plans. Our managed IT support plans and per-user pricing shows the published response commitment next to plan prices. We do not publish an FCR figure on those pages, and nothing in this article should be read as one.

Frequently asked questions

What does first call resolution mean in IT support?

It means the user's issue is fully resolved at the first contact, with no follow-up call, no reopened ticket and no need to contact the desk again about the same problem. In IT support the "call" usually stands for any channel, which is why many teams say first contact resolution.

What is the formula for the FCR rate?

FCR rate = requests resolved at first contact ÷ total requests handled in the period × 100. The result depends on the counting rules: what counts as a request, how long the repeat window is, and whether hand-offs count. Agree and document those first.

What is the difference between first call resolution and first contact resolution?

The Wikipedia article on FCR (checked 2026-10-28) says first call resolution measures FCR for a call centre, while first contact resolution measures it across any contact channel, such as chat, email or the web. Most IT desks use several channels, so first contact resolution is the more accurate name.

What is a good first call resolution rate?

There is no single good figure. It depends on the mix of requests, the tools and the counting rules. Compare against your own history, by category, and alongside the reopen rate and user satisfaction, instead of comparing to a number from another organisation.

Is FCR the same as resolving a ticket at L1?

No. First-level resolution means the ticket was solved without moving to L2 or L3, but it may have taken several contacts. FCR means one contact was enough. A ticket can be one without the other.

How can a small IT team improve FCR?

Start with a baseline, find the five or ten categories that cause repeat contacts, and write a short knowledge article for each. Then give the first person who answers the access and remote tools to act. Small teams often gain more from this than from any new software.

Can FCR be gamed?

Yes. Closing tickets early, avoiding hard calls and counting hand-offs as successes all raise the number without helping users. Read FCR together with the reopen rate and a customer check, and audit a sample of closed tickets each month.

If you want a view on how your service desk measures up against a published SLA, contact us.

Want these targets in a contract, not a slide? Brocent's managed IT support plans publish the SLA and the per-user monthly price side by side for Hong Kong, Singapore, mainland China and the United States. See the plans and pricing or talk to a consultant.