To improve first call resolution, investigate why customers need another call for the same issue. The cause may be an incomplete diagnosis, an unusable answer, missing agent authority, incorrect routing or a dependency that cannot be completed during the conversation. Each requires a different response.
This guide turns repeat-call evidence into a practical improvement plan. It covers baseline measurement for phone and other channels, hidden barriers, knowledge, training, checkpoints during the call, decision authority, technology and difficult call types.
Establish a baseline that reflects the customer’s issue
SQM defines first-call resolution as resolving the initial call reason without requiring repeat calls for that reason. Its guidance distinguishes internal measurement, such as repeat-call records and quality review, from customer-reported measurement. Use both perspectives where available, and describe the limitations of each.
Write a measurement policy before comparing teams or setting a target. Decide which calls are included, how the same issue is identified, the observation window and how transfers, consultations, callbacks and multiple issues are treated. A consultation during the same conversation may support resolution; whether a transferred call qualifies depends on your reporting rule. Distinguish first-agent resolution from first-call resolution. If a transferred call can count, report the transfer rate alongside FCR so transfers do not disappear inside the resolution figure.
If the issue requires a later callback or email to finish the work, record the further problem-solving contact. Track planned follow-up separately from avoidable repetition, while keeping both visible. Customers should not have to stay on the line for an unavailable decision simply to protect a metric.
Do not substitute a ticket metric for FCR. Zendesk’s one-touch calculation includes solved or closed tickets with a single agent reply or no replies, subject to its conversation rules. That calculation does not establish that a caller completed the original task or avoided another call.
Choose a stable reporting period and break results down by call reason. Publish the underlying counts, eligible population and unresolved or unknown outcomes. Allow the observation window to elapse before treating recent results as final. A customer who did not call again may have succeeded, abandoned the task or used another channel; silence alone leaves uncertainty.
An illustrative calculation with visible coverage
For an issue-based cohort, use one formula consistently:
FCR rate = Eligible issues resolved within the first call ÷ Eligible issues first raised in the cohort × 100
Apply the same eligibility rules to the numerator and denominator. Count an issue once rather than treating each repeat ticket as a new first issue, and report exclusions such as spam or test records with their counts.
Suppose a hypothetical review covers 100 eligible initial calls after the observation window. Evidence confirms first-call resolution for 60, further problem-solving contact for 25, and leaves 15 outcomes unknown. The confirmed proportion is 60 of 100, or 60%. Among the 85 known outcomes, it is about 70.6%. These answer different questions and should not be reported interchangeably.
This example is arithmetic, not a benchmark or a prediction. Keep unknown coverage visible, and do not classify every unmatched customer as resolved to raise the figure. If you use a survey, report the responding population and acknowledge that it may differ from all callers.
Extending the measure to first contact resolution
First call resolution focuses on phone conversations. First contact resolution can include email, chat, messaging and other support channels. If you report it, define the contact boundary for each included channel:
| Channel | Illustrative contact boundary | Resolution evidence to seek |
|---|---|---|
| Phone | The initial phone conversation | The required action works and further problem-solving contact is unnecessary |
| Live chat | The initial defined chat session | The customer completes the task or a verifiable outcome is established |
| The first substantive agent reply to the initial request | The answer resolves the issue without another problem-solving exchange | |
| Asynchronous messaging | A documented interaction boundary | Resolution within that boundary, checked for subsequent related contacts |
These are example rules, not universal tool definitions. Specify how long pauses, session restarts, same-session transfers and channel changes are treated, and do not define a multiday thread as one contact solely to count it as a success. If automated assistance counts as a contact in your policy, a later human conversation is not the customer’s first contact; if you report only human-assisted FCR, label that scope.
Keep self-service outcomes separate from assisted FCR as well. If self-service removes straightforward questions, the remaining callers may have more complex problems, so the assisted rate can fall even when the overall experience improves.
Find the failure between the first and repeat call
Select a documented set of returning cases and reconstruct each initial interaction. Include different reasons and teams where relevant. Add some confirmed first-call successes for comparison so the review can identify what worked as well as what failed. A diagnostic sample helps generate hypotheses; it does not by itself establish their prevalence across the operation.
Record the original goal, what the agent understood, evidence collected, answer or action, verification and what the customer needed next. Link the repeat contact using the issue as well as customer identity. Two calls from one account may concern unrelated tasks; one issue may appear under separate tickets or another channel.
Ask agents what made the first call difficult and ask customers what prompted the return where an appropriate feedback route exists. Separate observations from explanations. “Agent searched for ten minutes” is observed behavior. “The article was hard to find” is a hypothesis until the search and content are reviewed.
| Possible barrier | Evidence to seek | Potential improvement owner |
|---|---|---|
| Incomplete diagnosis | A missing question or unchecked assumption that changed the answer | Coach or diagnostic-content specialist |
| Knowledge gap | Missing, outdated or inapplicable instructions | Knowledge owner |
| Authority or access gap | An approved action the agent could not perform or authorize | Service owner and access administrator |
| Routing or handoff gap | Wrong capability, lost context or unavailable recipient | Routing owner and receiving team |
| Context gap | The agent did not know the relevant role, environment or previous attempt | Case-record owner |
| Communication gap | The customer could not apply the instructions that were given | Coach and knowledge owner |
| Incomplete verification | Steps delivered but the original task was never tested | Quality lead and coach |
| External or product dependency | A required approval, repair or event outside the call | Relevant department or product owner |
| Unknown cause | Insufficient evidence to reconstruct the failure | Case-record owner |
Assign a primary reason when evidence supports it and retain contributing factors. Avoid forcing every repeat call into “agent error.” A policy or product limitation may remain even when an agent follows the process correctly.
Repair the knowledge that failed during the call
For a knowledge-related repeat call, repeat the agent’s search using the customer’s wording. Was there an appropriate answer? Was it discoverable? Did it state the correct environment and prerequisites? Did its instructions produce a result that could be verified?
These failures call for different changes. A missing answer needs investigation and new content. An outdated answer needs correction. An accurate but unfindable answer may need a recognizable title or better indexing. An answer that depends on restricted authority needs a clear internal route and customer explanation.
The KCS practices guide connects knowledge reuse, improvement, capture and structure to the workflow. Use the repeat-call review as a specific correction opportunity: preserve the customer’s context, flag the failed instruction and let the authorized owner update it. Do not create another duplicate article whenever a case returns.
For visual tasks, a maintained short demonstration can supplement written steps. State the product context and expected outcome, and keep a route for customers whose interface differs. Review article usefulness through applicable outcomes and agent feedback, rather than interpreting views or links as proof of resolution.
Coach the missing judgment, not just the script
Turn an observed failure into a safe, illustrative practice scenario. Remove unnecessary personal information and preserve the decision that matters. If an agent assumed the caller had the correct account role, practice how to check that prerequisite and respond when it is missing.
A useful exercise varies the situation. The first scenario may match the standard article; the next should include a conflicting symptom, an unavailable approval or a solution that does not work. This reveals whether the agent understands the diagnostic path and the limit of their authority.
Assess specific behaviors: clarifying the task, choosing relevant questions, using appropriate knowledge, explaining approved actions, verifying the result and documenting a handoff. Give feedback on the step that failed and observe another attempt. Avoid treating a confident delivery or a short conversation as evidence of correct diagnosis.
Name the behavior to practice. “Improve FCR” is too broad; “ask the caller to verify the new invitation can be accepted before ending this case type” is reviewable. Use a consistent rubric and discuss disagreements between reviewers; our support quality assurance guide covers sampling, calibration and coaching.
Technical practice and communication practice serve different gaps. An upset caller may need a calm acknowledgement and a clear explanation, while an intermittent software issue may need better evidence collection. The call center agent training guide explains how to build these exercises into onboarding and ongoing coaching.
Give agents checkpoints for the call itself
Confirm the contact reason before answering or transferring. A brief question can separate similar issues: “Is the payment failing, or are you asking about a charge that already completed?” Review what the phone menu or previous agent collected; a caller who selected “billing” may still have an issue that partly belongs elsewhere.
Check that an answer applies to the caller’s role, version and account state before reading out steps. Give the next action and its expected result, then check what the caller sees, rather than delivering a whole troubleshooting sequence when the first result determines what comes next. If a transfer is necessary, explain why, summarize the case and say who is taking ownership.
| Call stage | Useful checkpoint |
|---|---|
| Opening | The customer’s goal and impact are understood |
| Investigation | Relevant context and prerequisites are confirmed |
| Action | The permitted action is completed or a dependency is identified |
| Verification | The expected result is checked where possible |
| Closing | Remaining work, ownership and update expectations are explicit |
Before ending the call, summarize the original issue, action and result. This illustrative check is not a script to read verbatim:
First-call resolution check Original task and contact reason: Relevant verification completed: Action taken and authority used: Expected result and observed result: Customer can complete the task now: Remaining dependency or follow-up required: If unresolved: next action, owner and update time: Related earlier contacts and case reference:
If the issue remains unresolved, a clear handoff is still good service. Record the reason so the team can address it, rather than rushing the caller or changing the disposition.
Clarify verification and decision authority
Those checkpoints work only when agents know what they may decide. List the actions an agent may take independently, the conditions that apply and the decisions that require approval, such as a replacement, billing correction or account update. Keep this authority matrix specific to each action, with an approval owner and the evidence the approver needs. Review routine calls that wait for approval, inconsistent decisions and approval requests missing information.
For an illustrative billing case, an agent may be authorized to correct a verified duplicate charge under the team’s policy. If a particular case needs an approver, the process should identify who is available and what evidence they need. A later approval and callback remains additional resolution work. Do not copy another organization’s refund or compensation limit as your own rule.
Keep identity verification separate from authority to act. Recognizing a phone number or displaying an account record does not establish permission to disclose information or change an account. Improve a verification step that creates unnecessary friction, but do not remove a required control to raise an FCR percentage.
Choose technology for a verified obstacle
Use the investigation to define the required capability before selecting a tool. If cases return because the wrong team receives them, inspect the routing input and available skills. If agents cannot find relevant records, determine which information is missing and whether identity, permissions or synchronization caused the problem.
Zendesk omnichannel routing uses availability and capacity for supported email, messaging and call work; skills-based routing depends on plan and configuration. Confirm the fallback when the required capability is unavailable. Assigning to an agent is not proof that the agent can complete the task. Review whether the phone menu accurately distinguishes contact reasons, and balance specialization with cross-training so one expert does not become the dependency for every ordinary request.
Agent assistance also has distinct functions. AWS documents answer recommendations, manual search and orchestration as separate AI-agent capabilities, with orchestration using preconfigured tools. Check the configured knowledge and actions, test representative requests and review the advice before using it. Adding assistance does not supply missing permissions or make an unresolved product defect disappear. If a tool classifies FCR automatically, validate it against a manual review sample before using it for performance decisions.
Visual support is appropriate when seeing the task helps clarify the problem. Screendesk live screen sharing allows an agent to view and guide while the customer keeps mouse and keyboard control. Explain the purpose and select a relevant sharing scope; preserve another support route when the customer cannot share.
For an asynchronous investigation, a Screendesk recording request can link a submitted recording back to the originating ticket or conversation, with optional microphone narration. Console capture needs its workspace setting and website widget; network capture is documented for the Chrome extension. Technical capture also depends on the available plan and enabled features. Request the evidence actually needed. A later recording can support resolution, but an issue that still required it was not completed during the initial call.
Investigate complex call types separately
Technical troubleshooting
Distinguish the symptom from the customer’s goal. Reproduce or inspect the relevant behavior where appropriate, record the environment and work through approved checks. Verify the original task after the proposed fix. An error disappearing at one intermediate step does not prove the entire workflow works.
Illustrative review: a caller can open an export menu but returns because the file never arrives. Check whether the first conversation tested the completed export, account permissions and any delivery dependency. The investigation may lead to an article correction, a coaching exercise or a product issue; it should not begin with a predetermined tool purchase.
Complaints and disputed outcomes
Clarify the practical remedy the caller is seeking as well as the reason for dissatisfaction. Acknowledge the concern without inventing an explanation. Identify what the agent can approve and when another decision-maker is required. Separate a clear policy explanation from the customer’s acceptance of the proposed outcome.
Illustrative review: a customer calls again about a disputed charge after being told that a review has started. The first call established a process, but the billing question remained unresolved. Inspect approval authority, the promised update and ownership. Faster closure of the complaint record would not complete that decision.
Requests involving several departments
Map the required steps and identify which can occur during the conversation. Keep one communication owner, record the outstanding decision and supply the next department with the evidence it needs. Where a specialist can consult during the same call, test that route. Where a later event is required, give a clear next action and update commitment.
Illustrative review: an account change needs both technical verification and an authorized commercial approval. Determine whether the repeat call arose from missing verification, lost handoff context or no progress update. These remedies belong to different owners. Do not describe every legitimate multi-step request as an avoidable frontline failure.
When the same dependency keeps generating calls, bring a specific case pattern to its owner: affected customers, contact reason, impact, confirmed facts, attempted actions and the recurring dependency. Agree on a concrete action and completion evidence; “collaborate more” does not identify what should change.
Turn findings into one testable improvement
Prioritize a recurring barrier with clear evidence and a responsible owner. Define the change and the expected mechanism: for example, correcting a missing prerequisite should prevent the same unsuitable instruction being given. Choose a comparable review population and retain the same measurement rules.
Repeat-call review Initial and returning case references: Customer's original task and call reason: First-call diagnosis, action and verification: What required further problem-solving contact: Known outcome / unresolved / unknown: Primary barrier and supporting evidence: Contributing factors and external dependencies: Knowledge, coaching, routing or authority change: Responsible owner and implementation date: Comparable review population and observation window: Quality checks and evidence of task completion: Next review decision: retain / revise / investigate further
This is an original diagnostic worksheet. Use it with the agent and relevant specialist to agree on a specific change. Track repeat reasons, customer task completion, quality and waiting time alongside FCR. Handle time may rise when agents perform a necessary check; a shorter call is not automatically the better result.
Review the evidence after the observation window and look for changes in case mix, staffing or reporting that could explain the result. Keep the finding provisional when coverage is small or incomplete. Avoid incentives that encourage rushed calls, discouraged follow-up or premature solved dispositions.
Frequently asked questions
Does a call transfer always mean FCR failed?
Not necessarily. A same-call transfer and a later callback are different events, and whether a transfer counts depends on your documented rule. A safe, useful transfer is preferable to an incorrect answer delivered to preserve a metric.
Does a thank-you reply or a new question count as a repeat contact?
Not necessarily. Distinguish courtesy messages from additional problem-solving contact using a consistent rule. A new, unrelated issue should not automatically invalidate the earlier resolution.
What is a good FCR rate?
Use a baseline with explicit definitions, then set goals for comparable call types and addressable causes. Contact boundaries, case complexity, exclusions and measurement methods can change the rate substantially, so do not apply an unverified industry percentage to every team.
