Monthly Archives: June 2011

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:

How to not deliver bad news to your customers: #poorservice #SCRM


Haim Toeg

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

@ interesting, how would you have delivered the news?


Loic Le Meur

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?

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.