Category Archives: Support Management

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?

Benchmarking, why not?

I was going to write a benchmarking post, and then discovered that it was written for me already.  So, back to the drawing board – I will try to add to an already well written article.

Consulting clients, and  some of my bosses (mainly those with marketing background) when I was in the corporate world, keep asking “what’s the industry benchmark?” or “how are we doing against IBM / Oracle / HP / CA / new-competitor-de-jour?”.  My answer was always and remains “I don’t know, I don’t care, and neither should you”.  Here’s why:

  • You never know what you are benchmarking against.  Customer support, unlike finance, has no GAAP equivalent, and the results are not audited.
  • Suppose you knew the benchmark and the way it is measured, now what?  Your decisions will remain the same with or without this information
Here is what I always advise clients:
  • Ask your customers what other vendors are doing that they like, or don’t like.  Understand the differences between your organization and other industry participants.  Know your capabilities and the boundaries your company will not let you cross 
  • Study the industry’s practices and achievements, adapt, emulate and copy shamelessly what makes sense for your operation and your customers like.  Avoid everything else (“IBM / Oracle / HP / CA / new-competitor-de-jour are doing it this way” is not good enough reason to implement anything, but a very good reason to study it
  • Know your own performance and always work improve the parameters that matter to your customers, your employees and your management
  • Customer satisfaction is NOT a benchmark, it is the feedback loop confirming that your customers appreciate the efforts you are making to improve

Last, have faith and what you do and be aware of the gap between cause and effect.  So, not everything you do will immediately manifest itself in the metrics, and certainly not in customer satisfaction results.

What’s your experience with benchmarking?

Support, Transparency and Service Design

Support teams are regularly torn between customers’ pressure to disclose more information, especially when cases are not progressing as expected, and the need to protect the company’s internal processes or the identity of decision makers.  Frequently, we err on the disclosure side, thus exposing the decision makers to unexpected calls from customers and undue pressure.

Those of us who enjoy visiting restaurants with open kitchens will realize that while we enjoy watching the cook prepare our pizza, we hardly ever get to watch the dirty dishes piling up or, indeed, the dishwashing crew in action.  Similarly, there are always portions of the company’s operation that we should consider keeping away from customers’ eyes

Here’s where Service Blueprinting comes into play – it is a methodology for process design and analysis that, among other things, makes process designers aware of the need to make informed decisions about the visibility of sections of the problem resolution process to the customers.  A sample of a service blueprint is:

I am sure each of us can chart our favorite restaurant / bank / airport experience into similar chart,  Can we done it with similar clarity for our support operation?  Is the line of visibility as clear in our operation as it is for other businesses we are familiar with?

I added several blogs to the blogroll on the right with service design and blue printing information.  Wim Rampen’s blog is always insightful, while design for service and desonance have several good entries that got me thinking about

Take a look and let me know what you think.

Why Can’t They Read The Manual?

In support we frequently tend to chalk all customer questions on how to do things under the unflattering RTFM umbrella.  However, some careful thought will lead us to see that there are at last three classes of such cases:

  • The customer is trying to accomplish a really unique and complicated task
  • They are trying to accomplish something relatively basic, but can’t exactly figure out how to do that due to lacking or inadequately organized documentation
  • The caller is under-qualified and needs more education on the platform or the product than what support can provide while managing a case
If we look at the three classes we can clearly see the different direction we need to take for each.  In the first and second cases we need to help the customer accomplish what they are trying to do.  We’d also want to document the information we provided, which will help us (assuming we are using KCS) understand two things:  First, how common is the ‘unique and complicated’ task the first customer is trying to accomplish, and second, the impact of not having the way of accomplishing that simple task properly documented, and give us a way to discuss a fix to the documentation, which, as I wrote in an earlier post, is a part of the product.  

When dealing with customers with inadequate knowledge there are several considerations we need to make.  If the contact we are dealing with is lacking in basic platform knowledge, we should find a way to raise it with their management.  

In cases where the customer  is missing product-specific knowledge a system that worked for me well in the past worked as follows:

  • Support engineers mark cases where the contact could use product knowledge
  • Education department uses these cases as leads to sell training seats
  • If they were successful and the customer signs up for training, the support engineer gets  a small reward
What’s your experiences collaborating with the education department?  Other departments?  Handling customers who need more knowledge than they have?

Backlog and “Why Can’t I Close This Case?”

How to define and measure backlog, together with its sister question, when to close a case, seem to always trigger high passions in team meetings.  I thought I’d share my experiences here and ask for sharing of readers’ experiences.

I always viewed backlog as all cases that have not been closed.  And the size of the backlog represents the total impact to customer value as a result of support cases.

With that said, we need to think of backlog from several perspectives:

Operationally, backlog can be broken into several groups:

  • What we are working on or is waiting for us
  • Cases for which we are waiting for someone else internally to respond (specialist knowledge, R&D, marketing)
  • We are waiting for the customer to respond either with information or confirmation that a fix we have given worked

When measuring backlog, we must be able to distinguish between the three groups and analyze it separately for improved performance.

For example: support managers do not usually concern themselves with cases waiting for the customer to produce information.  Not until the customer complains, at least.  However, examining these cases more closely may reveal the need to develop guidelines or tools that will help customers produce diagnostic information quickly and with minimal effort.  I am sure you can think of additional examples.

So, back to the original question “I have given a fix, why can’t I close the case?”  “Because a case is not a vehicle for support workload, it is a representation of diminished customer value and the experience associated with solving the problem.  Therefore we do not close the case until customer value has been restored”

What’s in a Product?


In support we frequently need to decide whether to let a product out the door or not.  Many times the sticking point in the discussion is around the difference between the code and the product, where the code is ready and everything else is lagging, from documentation to support training.  Should we let the product out?

To answer this question let’s remember that customers buy our product under the assumption that it will help them generate additional business value in their own operation.

In order to make an informed decision we have to answer several questions:

  1. Can customer do anything with code only?
  2. Can they do that with the new code and old documentation?
  3. Are we ready to support the new code with our existing knowledge?
  4. What is the risk we are taking releasing an incomplete product to the market?

In all cases, though, we have to remember that “product” and “code” are not exchangeable terms.  While the code is a critical part of the product, it by no means provides the entire customer experience the customer has signed-up for.