FCR vs Repeat Contact Rate: The Two Metrics That Must Be Read Together

The quarterly review looks good: first contact resolution in ServiceNow has hit its target for the second quarter running. Yet the same employees keep raising new incidents about the same VPN client, the same docking station and the same Outlook profile, and nobody looking at the dashboard can explain why.

FCR vs repeat contact rate is not a choice between two metrics, because each one only makes sense in light of the other. A rising FCR number tells you incidents are closing on the first contact, and it tells you nothing about whether the fix survived the week.

TL;DR

First contact resolution records a claim made when an incident closes, and repeat contact rate tests whether that claim held once the employee went back to work. Only the pair, measured on incidents that contain real resolution data, shows a ServiceNow service desk whether its first-contact fixes are genuine.

1. FCR records the technician's judgment at close, while repeat contact rate tests that judgment afterwards.
2. Reopen rate misses every employee who comes back by raising a new incident instead of reopening the old one.
3. A team measured on FCR alone learns to close incidents rather than prove the fixes.
4. Plotting FCR against repeat contact rate produces four patterns, each with a different cause.
5. Repeat contact rate in ServiceNow needs a defined window, both new and reopened incidents, and readable resolution notes.
6. Device context at session start and structured notes at session end move both metrics the right way.

What FCR and Repeat Contact Rate Measure in a ServiceNow Service Desk

The two metrics look at the same incident from two different points in time, and that timing difference explains almost everything about how they behave.

1. First Contact Resolution Measures the Claim Made at Close

First contact resolution is the share of incidents resolved on the employee's first contact with the service desk, as defined in our guide to IT help desk metrics. The number is recorded when the technician marks the incident resolved in ServiceNow. FCR therefore captures the technician's judgment at that moment, and nothing about what happens once the employee goes back to work.

2. Repeat Contact Rate Measures Whether the Fix Held

Repeat contact rate is the share of employees who contact the service desk again within a set window after their incident was resolved. Some of those repeats are about the same problem and some are about something new, a distinction that matters once you start measuring.

Repeat contact rate surfaces what FCR cannot see: workarounds that expired, fixes that never reached the cause and devices that keep failing the same way.

3. Reopen Rate Only Sees Part of the Repeat Contact Picture

Reopen rate looks like it covers repeat contacts, but it only counts incidents that are reopened. An employee who comes back by raising a brand new incident about the same problem never appears in reopen rate at all.

Timing narrows what reopen rate can see even further than that. ServiceNow's incident state model marks a Resolved incident as Closed once it has stayed in the Resolved state for a set duration, so any measure that stops at closure misses every return that happens after that point.

Why FCR Read Alone Rewards Closing Over Fixing

Of the two metrics, FCR is the only one a technician directly controls. Marking an incident resolved on the first contact is a technician action, while whether the employee comes back a week later is not.

A team measured on FCR alone therefore learns to close incidents, and our guide to reducing AHT and boosting FCR shows how speed targets push technicians to close tickets quickly rather than thoroughly. Our breakdown of critical help desk KPIs makes the same point from the data side: a closed-ticket count says nothing about whether the resolution held.

The resolution note is the last line of defence, and a note that says "fixed" gives a reviewer no way to check whether the first-contact fix was real.

How to Read FCR and Repeat Contact Rate Together

Plotting the two metrics against each other gives four distinct patterns, and each one points to a different cause and a different first action.

1. High FCR and Low Repeat Contacts: Fixes That Hold

This is the pattern every service desk wants, and the job is to understand which fixes produced it. Pull a sample of first-contact resolutions with no repeats and turn their resolution paths into knowledge articles other technicians can reuse. A healthy pattern only stays healthy when the fixes behind it are captured and shared.

2. High FCR and High Repeat Contacts: False Resolutions

Incidents are closing on the first contact, yet the same employees keep coming back, which means the fixes are not holding. A workaround logged as a resolution, or an incident closed before the fix was confirmed, would produce exactly this pattern. Start with the resolution notes on the repeated incidents, because they show whether the first fix addressed the cause or only the symptom.

3. Low FCR and Low Repeat Contacts: Slow but Durable Fixes

Fixes hold once they land, but they take escalations or several contacts to get there. Check whether technicians start sessions with device context, because a first contact spent gathering information is a first contact that cannot end in a fix. Shortening the path to a correct diagnosis raises FCR without putting durability at risk.

4. Low FCR and High Repeat Contacts: A Service Desk Missing Context

Incidents neither resolve quickly nor stay resolved, which makes this the least healthy pattern of the four. Look at diagnostic context at the start of sessions and resolution knowledge at the end of them together, because both sides are failing at once. Fixing only one side moves the desk into a different quadrant rather than out of trouble.

How to Measure Repeat Contact Rate in ServiceNow

Repeat contact rate only becomes a usable metric once the service desk defines what counts as a repeat and can see what the original fix was.

1. Set a Repeat Window Longer Than the Resolved Period

Choose a repeat window that runs past the point where your ServiceNow instance closes resolved incidents, so returns after closure are counted. A window that ends at closure leaves out every employee who comes back after that point.

2. Count New Incidents and Reopened Incidents Together

A repeat is any incident from the same caller inside the window, whether it arrives as a reopen or as a new record. Counting only reopens drops every employee who came back through a new incident, which is the part of the picture reopen rate cannot see.

3. Separate Same-Issue Repeats From Any-Issue Repeats

Matching on the Caller field alone counts every return contact, including unrelated requests from the same employee. Matching on Caller plus Configuration item, or Caller plus Category and Subcategory, isolates the repeats about the same problem.

Same-issue repeats test fix quality, while any-issue repeats point to broader friction in that employee's working setup.

4. Check the Original Resolution Notes on Every Repeat

A same-issue repeat is only useful when the original incident records what was actually done. Incidents closed with a one-word note leave the reviewer guessing, the knowledge loss covered in every resolved incident your agents close with "done". Without a readable first fix, a repeat contact tells you something failed but never tells you what.

How Structured Session Data Moves Both Metrics in the Right Direction

The only combination that proves fixes are real is FCR rising while repeat contacts fall. A remote support session that brings device context in at the start and writes a structured resolution back at the end works on both sides of that pair.

1. Device Context at Session Start Raises Genuine First Contact Resolution

ScreenMeet's Discover agent inventories the employee's device, including errors, processes, configurations and environment state, at the start of a session launched from the ServiceNow incident. Technicians begin with evidence about the device rather than spending the first contact asking questions.

ServiceNow's own internal help desk recorded a 32% increase in L1 first-call resolutions with ScreenMeet, a result covered in our guide to improving ServiceNow first call resolution.

2. Structured Resolution Notes Make Every Repeat Traceable

ScreenMeet AI Summarization records the steps taken, tools used, device state and resolution path, then writes that record into the ServiceNow incident when the session ends. A same-issue repeat can now be checked against exactly what was done the first time.

The note also answers the documentation question behind the agent productivity metrics that actually matter: whether the fix was captured at all.

3. Fixes Grounded in Past Resolutions Hold Longer

AI Assist surfaces fixes grounded in your organization's own resolved issues and knowledge base, while the technician makes the judgment call and applies the solution. Ontario Teachers' Pension Plan shows both metrics moving together: first contact resolution rose by 10% while case reopen rates fell by 25%.

4. A Growing Knowledge Base Deflects Repeats Before They Reach a Technician

Documented sessions give the service desk material it can reuse, and ScreenMeet turns detailed session data into knowledge base content in one click. Published fixes give employees a self-service path for a repeat issue before they open another incident.

The same session data also feeds Now Assist and the ServiceNow knowledge base directly, so documented fixes reach the tools the next technician and employee will use.

Put FCR and Repeat Contact Rate on the Same Dashboard

FCR is a claim made at close, and repeat contact rate is the test of that claim. A service desk that reports one without the other is reporting half a result and calling it the whole picture. ScreenMeet brings device context into ServiceNow sessions at the start and writes structured resolution data back to the incident at the end, so both numbers rest on real evidence.

See how ScreenMeet brings device context and structured resolution data into your ServiceNow incidents.

Frequently Asked Questions About FCR and Repeat Contact Rate

1. What is the difference between FCR and repeat contact rate?

First contact resolution measures the share of incidents resolved on the first contact, recorded when the technician closes the incident. Repeat contact rate measures how many employees come back within a set window afterwards. FCR records the claim, and repeat contact rate tests whether the claim held.

2. Is ticket reopen rate the same as repeat contact rate?

They are not the same, because reopen rate only counts incidents that are reopened. Repeat contact rate also counts new incidents raised by the same employee within the window, which reopen rate never sees.

3. How long should the repeat contact window be?

Set the window longer than the period your ServiceNow instance keeps incidents in the Resolved state before closing them. A window that ends at closure leaves out every employee who returns after the incident has closed.

4. How do you calculate first contact resolution?

Divide the incidents resolved on the first contact by the total incidents handled in the same period, then multiply by 100. Our guide on why remote IT support teams should prioritize first contact resolution covers the measurement methods in more detail.