Every transfer has a cost the customer pays
A transfer feels free to the team and expensive to the customer. Each one risks a dropped thread, a wait in a second queue, and the sinking “so, starting over” moment. Some transfers are genuinely necessary — the question really does belong to someone else. The goal is not zero transfers; it is zero unnecessary ones.
Route it right the first time
The cheapest transfer is the one that never happens because the chat reached the right person to begin with. A short pre-chat form or a department picker sends billing questions to billing and technical questions to technical, so the first agent can actually resolve it. Good routing up front prevents the reactive shuffle later.
Broaden what the first agent can handle
Many transfers happen not because the question belongs elsewhere but because the agent wasn't equipped to answer. A well-maintained knowledge base and canned answers let a generalist resolve more without punting. Every question your front line can handle directly is a transfer, a wait, and a repeated story avoided.
When you must transfer, transfer well
Some handoffs are right — and a good transfer is nearly invisible. Pass the full context in an internal note so the receiving agent reads in instead of re-interviewing, and tell the customer who they are going to and why. “Let me bring in Sam from billing, I've filled them in” keeps a necessary transfer from feeling like a brush-off.
How MyLiveChat supports fewer, cleaner transfers
MyLiveChat routes by department and skill so chats start in the right place, supports internal notes so a needed transfer carries its context, and its knowledge tools help a single agent resolve more without handing off. The reporting then shows you which topics transfer most — the shortlist for where to train or re-route next.
Find out which transfers you are actually making
Most teams estimate their transfer problem rather than measuring it, and the estimate is
usually wrong in an interesting way: the transfers people remember are the dramatic ones, while
the volume sits in a few dull, repeatable topics. Before changing routing or training anyone,
spend a week tagging every transfer with two facts — the topic, and the reason.
Three reasons cover nearly everything, and each has a different fix:
- Wrong door. The chat landed in the wrong queue from the start. This is a routing problem, not a training one.
- Knowledge gap. The right queue, but the agent could not answer. This is a documentation or enablement problem.
- Permission gap. The agent knew the answer but could not act — no access to issue the refund, change the plan, or release the order. This is a policy problem, and it is the one teams most often misdiagnose as training.
Sorting a month of transfers into those three buckets tells you where the effort belongs. A
team that trains harder on a permission gap will not move the number at all.
A transfer script that does not feel like a brush-off
When a handoff is genuinely right, the wording carries most of the customer experience. The
pattern that works has four beats: name the person, say why, confirm the context has travelled,
and set the wait expectation.
“Billing questions like this go to Sam, who can actually apply the credit — I have
written up everything you told me so you will not need to repeat it. Give me one moment to bring
them in.”
Compare that with the version most customers get: “Let me transfer you to
billing.” Same action, entirely different experience. The first tells the customer the
transfer buys them something; the second reads as being passed along.
Two phrases to retire. “That is not my department” describes your org chart, which
is not the customer’s problem. “Please hold” with no reason attached converts a
short wait into an anxious one.
Write the internal note before you move the chat
The single highest-leverage habit is writing the internal note first, while the
context is still in your head, and only then moving the conversation. Notes written after the
handoff are shorter, vaguer, and often never written at all.
A note that saves the next agent real time contains four things:
- What the customer is trying to accomplish, in their words — not your diagnosis of it.
- What has already been tried, so the receiving agent does not repeat it.
- Any identifiers already verified, so the customer is not asked twice.
- What you promised, explicitly. Unrecorded promises are how handoffs turn into complaints.
The fourth item matters more than it looks. When the first agent says “they should be
able to waive that” and the second agent cannot, the customer experiences it as a broken
promise rather than a misunderstanding between colleagues.
What to measure, and the trap in measuring it
Track transfer rate as a percentage of chats, and always break it down by topic. The
headline number moves too slowly to guide anything; the per-topic breakdown points straight at
the next fix.
The trap: transfer rate is easy to game. Announce it as a target and it will fall, because
agents will keep chats they should have passed on. That produces longer handle times, worse
answers, and a metric that looks better while the customer experience gets worse. Guard against
it by never reviewing transfer rate on its own — pair it with resolution quality and
reopen rate, so a suspiciously low transfer rate has somewhere to show up as a cost.
A useful companion is the second transfer. One handoff can be legitimate routing;
two on the same chat almost never is, and chats transferred twice are worth reading individually
rather than counting.
A short checklist
- Tag every transfer with topic and reason for two weeks before changing anything.
- Fix wrong-door transfers with routing, knowledge gaps with documentation, permission gaps with policy.
- Write the internal note before moving the chat, and include what you promised.
- Name the person and the reason when you hand off.
- Review transfer rate alongside reopen rate, never alone.