Author Archives: Toeg, Haim

The Pain Report

One of the people I worked with in the past used to produce what he called “Pain Report”. This report attempted to predict the customers (or sales people) that would explode next and give support managers a way to proactively address problems.

The report was basically a weighted sum of the amount of time all cases were open. Here’s how it works:

  • Assign a weight for every severity level you have. The more severe the case, the higher the severity. For example, with a four level severity scale a possible a possible scale can be:
  • Now multiply the number of days each of the customer’s cases have been open, and what you have is the weighted number of days for every case
  • Sum the numbers you received, and you receive the customer’s pain index

The weight numbers in the table above are a way to assign relative urgency to the different severities, play with them and determine the weighting that works for you. Here is a sample of two customers’ pain report that demonstrates the influence of higher severity cases on the pain index:

Both customers have an identical number of cases open, and the total number of days is similar. The only difference between the reports are two higher severity cases that customer “A” has.

Now, this report does not attempt to predict the next angry phone call our CEO will receive. There are more variables at play here, from a pending deal to total lack of good will on the customer’s side. But, it does give us an additional perspective on the caseload and the way it is broken down by customer, and helps us diffuse potential trouble spots before they materialize. It will probably be far more useful in very high complexity environments, where customers have multiple cases open at any given time and support management needs to find a way to make sense of their workload.

Have you implemented such a report? Do you think it will useful in your environment?

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.