Measuring the success of internal handoffs

This topic, measuring the success of internal handoffs, was suggested by a loyal reader who wishes to remain anonymous (thank you J!).

For the purpose of the blog I widened the question a bit. The initial question was posed in the context of forced, time-based escalations (e.g. if a case is more than X days and still unresolved, it is automatically “escalated” to a more technical team). I will discuss internal handoffs of all kinds in this post.

Handoffs are a pain

Customers don’t like to be bounced around, and handoffs requires additional work from both the sending engineer and the receiving engineer, so you take a productivity hit. Always strive to avoid handoffs through intelligent routing or other process changes.

Customer satisfaction is always key

Customer satisfaction is lower, on average, for cases that required a handoff as compared to cases that did not, since handoff cases take longer and, as mentioned above, customers don’t like to switch contacts. Still, customer satisfaction ratings are useful to track improvements over time as well as compare support engineers, both on the sending and receiving sides.

Time matters

Cases with handoffs have much in common with regular cases so measuring response time (by the receiving engineer, measured from the time of transfer) and resolution time is a good idea. Always measure against a target, which needs not be shared with customers but must exist internally.

But the real question is: did we add value?

CSAT and SLA metrics cannot answer the burning questions about handoffs:

  • Was the handoff required?
  • Was it done well?
  • Was it timely (not too early, not too late)?

The person who can easily answer these questions is the receiving engineer. Provide guidelines and audit a portion of cases to ensure that answers are grounded. For example, the handoff is probably not required if the answer was in the knowledge base all along, or the customer would have been better off simply waiting for the sending engineer’s next shift. A good handoff requires that the sending engineer gather basic troubleshooting escalation and summarize the findings before handing off. A timely handoff occurs before the customer is mad-as-hell because nothing constructive happened for three days.

If you think that asking colleagues to rate colleagues is too awkward, you can simply conduct case audits to judge which handoffs were legitimate, but it’s time consuming, and you won’t be able to get to all of them.

Engineer who produce many poor handoffs need training or a motivational session, or both. And if you are experiencing many unnecessary handoffs, chances are that support engineers are somehow rewarded to continue this unhealthy behavior: are you penalizing owners of cases that go beyond a certain timeframe? Are you imposing customer satisfaction targets that encourage the engineers to dump their tougher cases? On the other hand, do you reward support engineers when they close more cases?

For the timeliness question, you can try using simple time measurements and AI metrics. For instance, if many cases are solved very fast after the handoff, chances are that they should have been handed off, and solved, earlier. (It could also be that you are unnecessarily restricting access to a tool or procedure.)

How do you measure the success of handoffs? Please share your approach in a comment.

Leave a Reply

Your email address will not be published. Required fields are marked *