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.

Advertisements

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?

How to Not Own a Problem

Any of you know evernote? It is a great little tool that allows users to clip, tag and access web clippings, pdfs and other files. I depend on this tool and its safari plug-in greatly and I imagine many other people do as well.

One of Evernote’s nicest features is its web clipping plug-in for browsers, including safari. A few days ago Apple upgraded Safari and the plug-in stopped working, and apparently needed major upgrade. How should a company address such a situation?

Today, several days after the safari upgrade during which the plug-in was not operational, Evernote sent its subscribers this e-mail:

What can we learn from this e-mail?

  • Apple has upgraded Safari (which we already know) and it is very different to what we had until now
  • Evernote are working hard (which we don’t really care about, we pay subscription to fund that)
  • Apparently they have no clue when a new release will be available
  • … and they do not plan to notify us when it is released

To add insult to injury, Evernote decided for its customers that their tool not working is a “small hassle”. This statement presents two questions: First, how do they know how big the hassle is? and second, if their tool being severely handicapped is a small hassle, why should anyone pay for it?

Now, beside the fact that the link they recommend does not work, what should a company do to deliver news like these:

  • Tell the users something they do not know but care about, for example, when will the new release be available
  • Do not make assumptions about the problem’s impact on your users (hint: do not use “small hassle”)
  • Commit to following0-up, communicate progress and the availability of the new release in the same way you communicated the problem

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.

How To Deliver Bad News

Recently I started using Seesmic, and also ‘liked’ them in facebook.  A few days ago they published this message, which got me thinking, and tweeting:

Surprisingly enough, Seesmic, or more accurately, Luic Le Meur, one of the founders, responded:

So, what are the keys to delivering bad news?

Put yourself in the customer’s shoes.  Does the company really think anybody will pay their carrier the penalties associated with changing devices or switching carriers just to use their iPhone or Android product?  All this message does is annoy its audience – exactly those that the company wants to keep.

Offer valid alternatives that do not require much effort or expense.  In this case the company could have just as easily recommend the native twitter and facebook applications for the BlackBerry.  It would have made a positive message that could have gained added goodwill.

Postscript: In the time since, Seesmic updated the original blog post, well done!

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?