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.

Metrics for Using Social Media in Customer Support

This post started life as a response the TSIA forums (registration required, free).

Setting up a social media support forum and trying to measure its effectiveness is an interesting challenge. Expecting it to reduce the volume of incoming cases is a long term proposition that has to be managed carefully before you have any chances of success at all.

Consider that in order for the forum to become a successful support tool, you will have to create traffic, first browsers and then contributors.  In the mean time it will be up to your staff to encourage the traffic, respond to questions and keep the forum alive.  Therefore in the first period of its life, measuring volume of traffic, repeat visitors, time spent, number of responders from outside your organization is exactly the right thing to do.  You want to make sure there is interest and value to the visitors, regardless of the reduction in case volume you experience.

Eventually, you’d want to think about measuring the impact the social media initiative has on your incoming workload – now the main effect you are hoping for is reduced number of cases. This can be manifested in either of these two ways:

  1. Fewer new cases
  2. New cases are better documented and therefore more efficiently managed and resolved

The main challenge in directly measuring the impact your social media initiative (or knowledge base, or anything else designed to reduce case load) is that you can’t measure the things that did not happen. In other words, there are multiple reasons a customer did not open a case, for example: no problem happened due to improved product quality based on support feedback, they are phasing your product out due to reduced quality and are not interested in investing time in resolving minor problems, your knowledge management initiative is highly effective and the customer found a solution there, and so on.

What you can do is deduce the effectiveness based on several other measurements, for example:

  1. How does your workload develop based on your revenues, if you are growing revenues and reducing workload you are likely doing something right
  2. Ask your customers when they open a new case whether or not they have tried to use the website / forum / whatever and failed to find a solution
  3. Measure the number of visitors to the site that open a new case within 24 / 48 hours after their visit
  4. Ask your customers how useful they think the tool is during customer survey
  5. Measure the value to your organization through the content and information you were able to retrieve from the forum into your own systems and processes

There is an excellent book you may want to look at, it’s called Collective Wisdom, written by Françoise Tourniaire and David Kay, they have section discussing metrics for Knowledge Management initiatives which applies equally well to an social initiative.  Also, there have been several valuable discussions on John Ragsdale’s blog,Esteban Kolsky’s blog, and the eVergance blog (which seems to have been deserted).

Was this post useful for you?  What’s your experiences in implementing and measuring social media initiatives in support organizations?

Support and Partner Relationships

This post came to life as a response to a linkedin question on the Association of Support Professionals group (see the entire exchange here, join the group for valuable information).  The discussion started with a question about differentiating partner cases from direct customer cases.  Below is my response, a little enhanced and slightly cleaned up and edited to stand on its own:

When evaluating the way partner cases should be treated it is important to take a look at high level partner relationships and the way they apply to the support world:

The partners’ interests in many cases are:

  1. Get the maximum amount of discount from the vendor,
  2. Invest as little as possible in non-project oriented activities
  3. Deliver a working implementation and charge for the project
  4. Do the minimum supporting the customer and throw any case over the fence so they do not disrupt current projects

Additionally, the partners’ operating environment is such that

  1. Their investment in the product is not high
  2. Switching costs to a competitive solution are not high
  3. The main asset is the customer relationship

Therefore partners tend to always be operating “on the brink”, doing the absolute minimum they can and attempting to get the most out of it.

The challenge support operations face is removing their relationships with the partner from the transactional project-oriented MO of the partner and transition it to a continuous dialog.  In order to do that, it is important to realize several things:

  1. Partners are allowed to take an extra cut of the software maintenance fees for providing support (your contract with them should give you the right to demand some things of them in return, from service levels to auditing rights)
  2. Partners main source of revenue is from professional services projects and not in providing maintenance and support services
  3. Vendors are interested in the long term retention of existing customers and in the reputation their products have in the market served by the partner, which they have outsourced to the partner for the extra cut of the maintenance fees

Looking at it this way, it becomes much easier to provide answers to your questions:

  1. You must treat partners differently, after all they are an important participant in the support chain and therefore should be measured, praised or made to face the consequences of poor performance in the same way as everybody else.  If you treat them like customers, why not treat your own Level 1 team as customers as well?  Most likely they cost you way less than the partners.
  2. Having a separate team or routing directly to level 2/3 is probably an individual operational matter and has more to do with workload, scheduling, availability of expertise, etc., but if you route partners through level 1, then why pay them in the first place?
  3. If you think partners are part of your overall ability to deliver excellent customer experience then you absolutely have to ensure they have the same access as your employees (point made by David Kay).  If you do not give them access to resources how can you expect they do a proper job?

Additionally, I like David’s suggestion of “invalid escalations” – it gives you the ability to both gauge the partners’ effectiveness as well as the ability of your knowledge base to serve them correctly (the suggestion was to measure cases that could have been resolved with existing information without escalation to the vendor).

So, how do you create a successful support partnership with your resellers?  We’ll discuss that in a future post.

Interesting?  Anything to add?  Write a comment or drop me an e-mail.

How Support Generates Customer Value

One of my consulting clients wanted to develop a mission statement for their customer support operation.  The discussion revolved around a defensive “we solve problems” for a while until a breakthrough was made, proposing to focus the statement on the protection and enhancement of customer value.

When we chart the cumulative value customers expect to gain from a product we expect that during the early stages customers gain relatively little value due to implementation and training.  Conversely, towards the end of the product’s useful life with the customer, marginal value generated nears zero as users move to other products.

If we put ourselves in the customers’ shoes we can assume that while they understand the complexity of enterprise software the expectation is that the newly acquired solution will function smoothly and with little interruptions.  The customers’ expectation of value is driven by the expectation for, smooth, trouble free operation.

As customers begin using the product and encounter problems, we can see those problems’ cumulative impact on the overall value customers are able to gain from the product.  Critical problems detract significantly while others very little.  However, over time the total impact of problems can be significant drag to the customers’ value gain:

To help customers mitigate the value lost to problems on one hand, and maximize the value gained from the product, vendors have been introducing value-added services, or whatever fancy name they are called:

Has this post been useful for you?  Send me an e-mail or leave a comment.

Getting started, or why managing customer support is like going on a road trip

Customer Support is a heavily regimented, process-oriented operation that easily lends itself to measurement.  Consequently, many of the questions surrounding changes to the organization revolve around metrics, with the two most frequent being “what should I measure?” and “what goals should I set?”  However, the answers to are very much context dependent.

With this post we will define the basic environmental parameters that help with the understanding of the context in which the customer support organization operates

My favorite analogy for managing customer support organizations is driving a car.  Before embarking on any trip in our car, however long or short it may be, we have four variables we need to know:

  1. Destination – Where do we want to be and when do we need to be there?
  2. The capabilities of the car – Can it do what we expect of it?  How long will it go on a single tank of gas?
  3. The rules of the road and obligations we made – How fast can we go?  Did we promise to stop somewhere to visit a friend?
  4. Environmental patterns and user behavior – When is rush hour?  Will we be driving on the busiest driving weekend of the year?  Will we get stuck behind heavy, slow commercial traffic?

Let’s see how these variables apply to the support world:

Destination – What do we want the organization to accomplish, and by when? Reduce costs?  Increase support revenue?  Increase product penetration?  Increase customer retention and maintenance renewals?  Do not forget that the objectives of the customer support organization cannot be disconnected from the overall corporate strategy and level of maturity.  Several writers address the different objectives of customer support organizations based on the maturity of the company they are part of.  For an excellent discussion see Thomas Lah’s book, Bridging the Services Chasm

Organizational Capabilities – What can we realistically expect from our organization?  A start-up company’s support organization will be radically different to that of a mature corporation in culture, motivational drivers, management capabilities, available resources and ability to accept change.  In fact, one of the recurring themes in several consulting engagements was the need to transform an organization from a hero-based culture of a start-up company to a more process oriented operation that can leverage the resources available to a larger corporation

Rules and Obligations – what are the existing obligations we have, what can we change and what not?  Take time to understand the existing contracts your company has with its customers and resellers, as well as any regulations that may impact you in the various locations you operate at, ranging from data retention and privacy policies to employee compensation.  A failure to follow those can get you and your company in deep trouble very quickly

Environmental Patterns and User Behavior – Are there any specific sensitivities or patterns we need to be aware of?  For example, specific seasonal behavior (we are all familiar with end-of-year lock down on one hand, and end-of-quarter sales rush on the other), industry specific patterns, or anything else that impacts the organizations ability to provide service or customers’ attitude towards it

Was this post helpful for you?  Do you have different experiences?  Start by adding a comment below.