Want help applying this guide?Ask the DripTell team
A low transfer rate is not automatically good customer service. It may mean people reached the right person first. It may also mean agents kept work they could not safely complete, closed it early, or told the customer to contact another team themselves.
The useful answer is to review transfers by reason and outcome, not just count them. Separate necessary specialist help from wrong routing, missing access, repeated handoffs, and transfers that should have happened but did not. Then fix the system that created the bad movement without discouraging the good movement.
| Area | What to verify |
|---|---|
| Start with the customer need | A queue move is an internal event. The customer need is the unit that matters. |
| Record the transfer event | You cannot review transfer quality from the final owner alone. Preserve the event itself. |
| Classify the movement fairly | Use four practical classes. |
| Use more than one number | Start with a simple contact transfer rate: |
Start with the customer need
A queue move is an internal event. The customer need is the unit that matters.
Suppose a customer asks a billing agent to reverse a card charge. If only a finance specialist has authority to approve the reversal, a transfer can be correct. If the finance team sends the case back because the order number is missing, that second movement is avoidable. If the first agent tells the customer to start a new conversation with finance, the dashboard may show no transfer even though the experience was worse.
Define one review unit as the complete customer need from first contact to a verified outcome. Keep all agent, queue, bot, and channel movements inside that unit.
Microsoft's current agent metrics reference defines escalation rate for an automated agent as the share of engaged sessions handed to a person. That definition is useful inside one system, but Microsoft also notes that a conversation can contain several analytics sessions. Your operating measure therefore needs a stable customer need above the platform session.
Record the transfer event
You cannot review transfer quality from the final owner alone. Preserve the event itself.
For every move, record the original owner, destination, time, reason, information collected, promised next action, and whether the receiving owner accepted it. Retain the eventual outcome and any related repeat contact.
Use a short controlled reason list such as authority required, specialist knowledge required, language or accessibility need, wrong initial route, missing access, capacity move, customer request, automation limit, and unknown.
Do not let unknown become the default. Review a sample of those events each week and either improve the reason list or correct the workflow that is hiding the real cause.
Acceptance matters. A transfer is complete when the receiving owner accepts the work and understands what happens next, not when the first team releases it.
Classify the movement fairly
Use four practical classes.
- A necessary transfer moves the need to someone with genuinely required authority, access, language, or expertise and carries enough context for work to continue.
- An avoidable transfer corrects wrong routing or compensates for missing knowledge, permission, ownership, or information that should have been available earlier.
- A harmful transfer repeats movement, loses context, restarts the customer's explanation, breaks a promise, or sends the need somewhere that cannot accept it.
- A suppressed transfer occurs when specialist help was required but the agent, automation, or policy avoided the move. It often appears later as a reopen, complaint, correction, or repeat contact.
The last class has no transfer event to query. Find it through quality reviews, repeat contacts, complaints, and cases where the final action exceeded the owner's authority.
This classification turns a blunt target into a diagnosis. Necessary transfers should be made easier and warmer. Avoidable and harmful transfers point to changes in routing, knowledge, access, or responsibility. Suppressed transfers are a safety signal.
Use more than one number
Start with a simple contact transfer rate:
customer needs transferred at least once ÷ eligible customer needs
Then add transfer depth:
total owner changes ÷ customer needs transferred at least once
The first number shows how often movement occurs. The second exposes bouncing. Report both by customer need, channel, initial route, destination, reason, and outcome. Do not combine sales questions, technical incidents, billing disputes, and regulated decisions into one target because their legitimate need for specialists is different.
Pair those numbers with acceptance time, context completeness, resolution, repeat contact, reopen rate, and customer effort evidence. A transfer rate that falls while repeat contact rises is not an improvement.
The Kustomer escalation rate explanation gives the familiar escalated interactions divided by total interactions formula and warns that pressure to reduce the number can encourage paper resolutions or avoided help. Use the formula as a starting point, not an agent score.
Review patterns instead of blaming agents
Run a short weekly review with operations, quality, and a representative from the teams receiving the most work. Sample necessary transfers, repeated transfers, quick closes, reopens, and cases with no transfer despite a later correction.
Ask what decision required movement, whether the route was reasonable, what context survived, and whether the customer obtained the promised outcome. Record the earliest controllable cause.
Microsoft's topic escalation analysis separates expected escalations designed into a flow from unexpected ones caused by errors. The same distinction helps human operations. A policy referral can be expected. A referral caused by a broken permission is not.
Avoid publishing league tables for individual agents. Case mix and authority differ, and personal targets invite transfer suppression. Coach specific decisions when needed, but assign system fixes to the owner of routing, access, knowledge, automation, or policy.
Fix the cause and test again
Choose one high-volume avoidable pattern and change the smallest control that can remove it. That may be a better first question, clearer route, missing access, concise knowledge answer, consult path, or specialist acceptance rule.
Compare the same cohort before and after the change. A useful result reduces avoidable movement or transfer depth without increasing repeats, unsafe decisions, unresolved work, or waiting time.
In DripTell's shared inbox, conversation history, ownership, notes, and status stay together across supported customer channels. That makes the transfer event reviewable without claiming the software can decide whether every move was justified. Teams can connect the review to automation and assignment rules, then test a narrow change against real outcomes.
If you are assessing your current workflow, bring ten transferred customer needs and ten similar needs that were not transferred to a DripTell walkthrough. That comparison usually reveals more than a dashboard percentage alone.
Frequently Asked Questions
What is a good customer support transfer rate?
There is no responsible universal target. The right range depends on customer needs, team authority, specialist design, and channel mix. Establish a baseline by reason and outcome, then reduce avoidable and harmful movement without suppressing necessary help.
Should a necessary specialist handoff count as a transfer?
Yes. Keep it in the measure, but classify it as necessary and test its quality separately. Excluding good handoffs hides real customer movement and makes comparisons harder.
How can we find transfers that should have happened?
Review quick closures, repeat contacts, complaints, corrections, and cases where an agent acted outside their authority. Sample both transferred and nontransferred needs so the metric cannot reward unsafe avoidance.
DripTell Editorial
Practical guidance reviewed by the DripTell product and customer workflow team.
See how DripTell checks product claims, uses primary sources and handles corrections.
Editorial and source policy