Implementing First Contact Resolution (FCR) Tracking across Voice and Digital Channels
What This Guide Covers
First Contact Resolution (FCR) is often considered the “Holy Grail” of contact center metrics. It measures the percentage of customer inquiries that are resolved during the very first interaction, requiring no follow-up. You are implementing a multi-method FCR tracking system in Genesys Cloud that combines agent-reported dispositions, customer survey data, and automated “re-contact” detection. This guide provides the technical framework for normalizing FCR definitions across different media types (Voice, Email, Chat) and building a unified FCR dashboard that accurately reflects your center’s effectiveness.
Prerequisites, Roles & Licensing
- Genesys Cloud: CX 1, 2, or 3.
- Permissions:
Analytics > Conversation Detail > ViewQuality > Survey > View
- Methodology: Choose between Subjective FCR (Agent/Customer says it’s resolved) and Objective FCR (No return contact within X hours/days).
The Implementation Deep-Dive
1. The Multi-Signal FCR Model
Relying on a single signal for FCR is usually inaccurate. Implement a “Triangulated” model:
- Agent Signal: Wrap-up code (e.g., “Resolved - First Call”).
- Customer Signal: Post-interaction survey question (e.g., “Was your issue resolved today?”).
- Behavioral Signal: Absence of any interaction from that
ExternalContactIdwithin 48-72 hours.
2. Standardizing Wrap-up Codes
Create a consistent set of wrap-up codes across all queues to simplify aggregation.
Example Hierarchy:
FCR - ResolvedFCR - Transferred (In-Scope)Non-FCR - Follow-up RequiredNon-FCR - System Issue
3. Automated Re-Contact Detection (The “Objective” Signal)
Use the Analytics API to identify interactions that were not resolved based on subsequent behavior.
import requests
from datetime import datetime, timedelta
def check_fcr_objective(conversation_id, contact_id, window_hours=48):
"""
Checks if a contact returned within the specified window.
If they did, the original conversation is NOT an FCR.
"""
# Logic to query interactions for the same contact_id starting AFTER conversation_id ends
# If count > 0, return False (Not FCR)
pass
4. Normalizing Across Digital Channels
Digital channels like Email and Messaging have longer “resolution cycles.”
- Voice: Resolution happens during the synchronous session.
- Email: Resolution happens if the “thread” is closed with a single outbound reply.
- Messaging: Resolution happens if the session is closed without a “re-open” from the customer within the timeout period.
Architect Flow Logic for Survey Injection:
[Interaction End]
|
v
[Decision: Is it a candidate for FCR Survey?]
|
|-- YES --> [Send Web Messaging Survey / Email Survey]
|-- NO --> [Disconnect]
5. The Unified FCR Calculation
The final FCR percentage is calculated by aggregating the signals.
$$FCR% = \frac{\text{Resolved Interactions}}{\text{Total Eligible Interactions}} \times 100$$
Exclusions:
- Wrong numbers / misdials.
- Hang-ups (abandoned before agent).
- Out-of-scope requests (e.g., calling the wrong department).
Validation, Edge Cases & Troubleshooting
Edge Case 1: The “Resolution” Delay
A customer says “Yes, it’s resolved” in a survey, but then calls back 10 minutes later because they found another issue.
Solution: The Behavioral Signal should always override the Customer Signal. If a return contact occurs, the record should be updated from “FCR” to “Repeat Contact.”
Edge Case 2: Multi-Agent Transfers
If a call is transferred from Tier 1 to Tier 2 and resolved there, is it FCR?
Solution: This depends on your business definition. Usually, if the customer doesn’t have to hang up and call back, it is still considered “First Contact Resolution” (though not necessarily “First Agent Resolution”).
Edge Case 3: Email Auto-Replies
Automated “Thank you for your email” responses can skew FCR data if not filtered.
Solution: Filter interactions by participantPurpose = agent and ensure there is at least one meaningful reply before counting as a candidate for FCR.