Monthly Archives: August 2011

Tiers Or No Tiers?

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:

  1. Case opened, customers describe symptoms to the best of their ability
  2. Tier One researches case, calls customer for additional information, can’t find a solution, needs to escalate
  3. Tier One must qualify the case for escalation, sometimes fill a long form or go through some other process
  4. Case is escalated, Tier One reviews the case with Tier Two
  5. Tier Two begins to research the case, often repeating many of the steps performed by Tier One
  6. 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.

Books Section Added

The site now has a new section with book reviews and recommendations, as well as pointers to valuable online resources. It is pretty thin right now but will grow as I have time to add reviews of books from the past and encounter new ones.

Admin: We Have Moved


The blog has moved from being hosted on to independent hosting and can now be reached at All content and subscriptions should remain the same, but if you notice anything odd please let me know, either through the ‘talk to me‘ page or by leaving a comment here.



How Old Is Your Case Load?

One metric that every support manager seems to use is the the average life of closed cases. We all look at this metric regularly and are happy to see it go down, believing that we have done a good job. But, did we?

From my experience, there are two metrics that go hand in hand, first is the time it took us to close cases, and the second is the age of our currently open case inventory. Let’s call the first ‘Case Life’ and the second ‘Case Age’.

Why, you ask, should we look at both?

These two metrics complement each other. Imagine that we walk into a new organization with poor follow-up processes and therefore many cases in the backlog. What will those two numbers show?

Most likely, we’ll see that case life is relatively short, since the organization is able to process and close simple cases. Case age, on the other hand, will be long and increasing, showing the organization’s lack of discipline and inability to follow-up.

Now, imagine the organization embarks on a massive improvement effort, begins to follow-up and closes long-running cases. What will happen then?

Exactly, case life will increase, representing the backlog being closed, whereas case age will decrease, representing the organization’s increased ability to follow-up and control its backlog.

In other words, case age is a representation of the health of your support operation that every support manager should consider. First, it is a leading indicator, representing the current challenges facing the team. Second, it is actionable, allowing you to address problems as they occur.

Terminology comment: There are two terms I did not use in this post, first is resolution time and the other is average. There is a long debate in most support departments about when to close a case. I wrote about it in the past, and do not want to get into it again here. I will write in the future about representative numbers and the reason why using average or mean is not always the best way to represent support workload.

What Can We Learn From a British Sandwich Chain?

This past Sunday, The New York Times published an interesting and well written story about Pret A Manger, a chain of British sandwich shop with a few stores in the UK and apparently exceptional customer service. As I was reading the story, the parallels to managing enterprise customer support teams were interesting and obvious, especially their focus on people.

Most interesting, at least to me, was the intensive focus on teamwork and attitude. From team interviews to training, measurement and compensation, the entire system is focused towards the overall performance of the store, as opposed to the individual performance of single employees.

Here are some additional points I found interesting:

  1. Regular inspection of the operation, but also that of the competition – easier in retail than it is in enterprise software, but still doable (think about using your IT department, asking customers and your friends and acquaintances)

  2. Understanding customers’ demands and keeping in mind they may change between markets, learning the market and adapting quickly are mandatory

  3. Set up your operation and adapt staffing levels to the changes in volume. This may sound trivial, but if it is, why do we wait in line or put on hold in so many places?

So, where have did you find interesting lessons and inspiration?