The Agent With Three Transfers
At a 60-seat inbound BPO in Guwahati, agent R handles a telecom client's postpaid billing queue. Last month: average handle time (AHT) 610 seconds against a 480-second target; first-call resolution (FCR) 61% against 85%; QA score 72% against 80%; repeat calls within 72 hours 14%; schedule adherence 80%. A customer verbatim says: 'I was transferred three times and nobody knew my plan.' The team leader has no authority to change the IVR or the client's billing system. The client's service-credit clause triggers if FCR stays below 80% for two consecutive months. R is otherwise punctual and well liked, and the team leader's instinct is to put R on a strict 10-minute call limit and script reading. The team has 14 agents; two others show similar transfer patterns.
1. Using the metrics, decide whether R's main problem is speed, knowledge or process. What evidence would you pull before coaching, and what would you avoid doing first?
Read the worked answer
The pattern is not primarily a speed problem. AHT is 130 seconds over target, but FCR is 24 points low, repeat calls are 14%, and the customer describes three transfers. That points to triage and knowledge gaps: R may be spending time searching, transferring blind, or re-opening the same issue. A strict 10-minute limit would likely reduce talk time but increase repeat calls, making the service-credit risk worse. Before coaching, I would pull a Pareto of call reasons, R's transfer and hold logs, after-call-work time, the top repeat callers, and a sample of ten recorded calls; I would compare R with the team median to separate an individual issue from a queue-level process issue. I would avoid public comparison, immediate disciplinary action, or script reading. The similar transfer patterns in two other agents already suggest a process contributor, so coaching only R would miss the root cause.
2. Draft a two-week coaching and process plan with measurable checkpoints. Include changes to the transfer protocol and how you would involve the client.
Read the worked answer
Days 1–3: side-by-side observation and call calibration on five calls, focused on the top three billing queries. Build a one-page decision tree and a warm-transfer rule: before transferring, the agent records the customer's plan, issue and checks already done, and briefs the receiving queue; no blind transfers. Days 4–7: 15-minute daily huddles on one query type, plus QA feedback within 24 hours. Week 2: knowledge-base updates for the top five repeat reasons and a second calibration. Checkpoints should be staged, not all at once: by day 10, AHT ≤ 540 seconds, FCR ≥ 70%, repeat calls ≤ 10%, QA ≥ 76%. Review at day 14. The client should be involved through an anonymised root-cause summary, a request for better visibility of billing-plan fields, and a joint calibration session. Do not promise the 85% FCR in two weeks; present it as a trend target with weekly reporting.
3. The client demands that R be removed from the account. How would you respond, and what data-privacy constraints apply when sharing call samples?
Read the worked answer
I would not agree immediately or refuse flatly. I would acknowledge the client's concern, present the verified data and the improvement plan, and explain that removal without investigation may hide a queue-level cause. If the client still insists, move R temporarily to a non-client queue while the review continues, and document the decision. I would share only the minimum evidence: redacted transcripts or call IDs, not full recordings with customer PII. If recordings are shared, follow the client contract and applicable privacy law, obtain authorisation, and use a secure channel. I would not share R's personal HR records. The response should separate the individual from the process: the three-transfer pattern appears in two other agents, so a client-facing corrective action plan should address the transfer protocol and knowledge base, not just one employee.