John Ragsdale has an excellent post about the cost differentials between escalated and non-escalated cases across support tiers. The case for eliminating tiers in support has been made by quite a few support industry members, here is one example, by Phil Verghis.
When looking at multi-tier organizations, we should do that from three perspectives, the customers’, the support employees’ and the case that’s being resolved.
From the customers’ perspective multi-tier support does not generate any benefit. In many cases they have to explain the problem to someone with not enough knowledge or experience to handle it, only to have to explain it again to someone more qualified when the case have been escalated. As Phil notes, there is little to no recognition of the customers’ knowledge and experience or the circumstances of the problem.
From the support employees’ perspective, the tiered model presents several challenges. First, it does not allow them to exercise their skills beyond the limits defined for their tier. The model also encourages exclusive thinking, where higher tiers have a disincentive to share knowledge and coach lower tier employees for fear of losing their relative advantage.
From the case perspective, the journey becomes really fascinating:
- Case opened, customers describe symptoms to the best of their ability
- Tier One researches case, calls customer for additional information, can’t find a solution, needs to escalate
- Tier One must qualify the case for escalation, sometimes fill a long form or go through some other process
- Case is escalated, Tier One reviews the case with Tier Two
- Tier Two begins to research the case, often repeating many of the steps performed by Tier One
- If Tier Two is successful resolving the case, fine. If not escalation to Tier Three repeats the entire process
A good way to review this process is through the perspective of Lean methodologies.
So, what can managers do to shorten the case life, reduce the amount of unnecessary work involved in the case, and make their employees and customers happier?
Simple, bring the knowledge to the case, instead of the case to the knowledge.
If we think about it, many of the developments in support, at least those focused on knowledge, are aimed at two goals. First is the accumulation of all knowledge in the extended organization through KCS and user communities, and second is the ‘democratization’ of this knowledge, bringing it as close to the problem as possible. Support organizations should act in a similar manner when managing cases and bring the knowledge, and the person holding it, to the case and the person attempting to resolve it. By doing so the organization gains knowledge transfer that happens better through collaboration than through escalation. It eliminates the cumbersome, overly bureaucratic escalation checklist, and saves its customers the need to repeat the story every time the case is escalated.
There are two prerequisites for such a transformation to take place. First is the need to build a map of the knowledge in the organization, who has it, at what levels, and who are the go-to specialists, and a process to dispatch cases according to this map. Second, and more complicated, is the transition in roles that has to take place. Members of the higher tiers, who until now have been protected by a moat of forms, case handoff processes and chargebacks as well as exclusivity and status will now have to rub shoulders with Tier One employees and proactively guide them through complex cases. The situation becomes more complicated in case the support chain is split along tier lines between, say Sales and R&D, which introduces executive politics into the mix. Indeed, observing multiple support organizations, it is easy to get the impression that multi-tier organizations are born due to either the need to preserve technical knowledge or due to organizational mistrust.
What’s your experience with multi-tier organizations? Does it work for you? Did it fail to deliver? I’d love to know.
PS: As I was writing this entry, Phil added a link to story summarizing the experiences of Red Hat’s support organization going through a tier elimination exercise. It is very interesting and worth reading, including their lessons learned on implementing change.