Don't leave customer support to luck - The simple principles of good service management, part 4

 

     

This video on YouTube. | Read the full transcript.

 

Service providers need a consistent, professional approach to managing incidents and service requests, because bad customer support drives away customers.

Keeping existing customers is way easier and cheaper than winning new ones, so it's not surprising that there is a strong emphasis on support processes in all service management frameworks and standards. Indeed, incident management is probably the best-know process in these frameworks, but - as Stefan Kempter explains in this video - quite a few more processes play their part in getting customer support right.

This is video number four in our series about "the simple principles of good service management - and how to apply them in practice": There have always been a number of time-tested, simple principles in service management that we must get right in order to become successful providers of services. In our videos we explain how you can bring these principles to bear in your organization.

Please ask your questions and share your thoughts in the YaSM support community!

Resources and further information

Video series: The simple principles of good service management
Related pages

Video transcription

Video: Don't leave customer support to luck. Managing incidents and service requests based on the YaSM framework. - Series: Good service management, part 4.When you start looking into any of the popular service management frameworks, one of the first things you learn is that you shouldn't leave customer support to luck. What's needed is a consistent, professional approach to managing incidents and service requests, and the reason why this is so important is quite obvious:

Bad customer support drives away customers, and we don't want that to happen - simply because keeping existing customers is way easier and cheaper than winning new ones!

So it's not surprising that all service management frameworks and standards have a strong emphasis on support processes and today I'd like to tell you what it takes to excel in customer support.

Service support and incident management in the popular service management frameworks

The popular service management frameworks, such as ITIL® and CMMI-SVC®, contain lots of time-tested advice for providing customer support and managing incidents in a professional way. And ISO 20000 requires proper processes for managing incidents and service requests.

Indeed, the process for managing incidents is probably the best-known part of these frameworks, and it's so much talked about that it's easy to miss the fact that quite a few more processes play their part in getting customer support right.

We'll look into these processes in a second, but first we need to speak about the objectives of good customer support.

What exactly does good customer support mean?

Obviously, we need to create a good experience for our customers. We shouldn't annoy them by making it difficult to find our contact details, instead it should be easy to get in touch with us. If an incident has occurred, we should resolve it swiftly, and keep customers informed while we work on a solution.

But simply focusing on the perfect customer experience is not enough, we also need to control the costs of providing support.

For this, there are a number of possible strategies.

  • For example, if we manage to keep the number of incidents low, less work is required for resolving incidents.
  • Also, mechanisms should be in place to detect issues early, so incidents can be dealt with before a large number of users are affected.
  • And if we are able to provide attractive self-help options, we can save a lot of money because no support agents are needed for resolving certain kinds of incidents.

So what we want is a good customer experience without costs spinning out of control, and now I'd like to show you in a bit more detail the kind of advice you'll find in YaSM.

How to design state-of-the-art support processes

First of all, it's important to understand that starting to think about customer support once a service is operational is too late; such considerations need to begin well before services are implemented, during the stage of service design.

Obviously, if a service and its infrastructure are badly designed, this may well lead to high volumes of incidents. Dealing with all these incidents is expensive, so it makes a lot of sense to think during service design about ways to keep the number of incidents low.

  • Possible solutions are the elimination of single points of failure (so incidents do not occur in the first place)
  • or the design of robust recovery and repair mechanisms (so incidents can be resolved quickly).

We could say that services and their infrastructure must be designed and built for stability and high availability so that we don't have to spend too much time providing support.

Handling incidents and service interruptions in service operation

But of course even well-designed services may fail once in a while, so we definitely need proper support processes in service operation to deal with incidents.

This calls, first of all, for setting up a process for managing incidents and service requests that receives reports of incidents and service requests from the customers. This process typically includes activities for

  • Resolving incidents
  • Fulfilling service requests and
  • Keeping users informed about the state of their requests.

These activities usually mean that support agents in the help desk are involved - which is expensive. So we also make sure that attractive self-help options are in place, such as a support website. Evidently, if we help customers help themselves, this will reduce the workload of the support agents - and save money.

What's more, it's crucial that we gather knowledge while dealing with incidents and build up and manage a support knowledge base, because if, for example, instructions for handling common types of incidents are readily available, these incidents can be resolved very quickly.

Now, the process for managing incidents is not exactly unimportant, but we should not simply sit around and wait until incidents happen. Instead we should monitor the infrastructure on which our services are based, and try to detect deviations from normal operation as early as possible. Any detected deviations should trigger appropriate - and if possible automated - responses. The aim here is to fix any issues before customers get affected.

If any defects are detected that require human intervention, this triggers the creating of an incident record that is sent to the incident management process.

Problem management is about identifying underlying issues

So we try to detect possible issues early - and once incidents have occurred, we send them to another process that tries to find underlying problems.

Within problem management, we analyze the incidents in our database in order to detect patterns. An example for such a pattern could be frequent paper jams with a certain type of printer, which lead to a high number of similar incidents. Once we've identified the problem, we may be able to resolve it, for example by replacing the printers with a different type; and this should result in a drop of the number of incidents.

The whole point of this exercise is to prevent incidents from recurring, and provide templates for the fast resolution of incidents that cannot be avoided. What we get from the problem management process are thus workarounds and permanent solutions that help us with reducing the time we spend resolving incidents.

The support processes in the YaSM process model

So this was a high-level overview of the advice we find in YaSM and other service management frameworks.

This may look a bit complicated, but if you want to introduce such processes in your organization, YaSM provides detailed recommendations in the form of process charts, and before we finish today's session I'd like to show you a few examples.

The YaSM process charts are available, for instance, in the form of Visio® diagrams. We start from the top-level diagram with an overview of all YaSM processes, and since the processes I want to show you are in service operation, we click on the link that takes us to the service operation diagram.

If we enlarge this a bit we can see some of the processes I mentioned earlier, such as the ones

  • for monitoring the services,
  • for resolving incidents and service requests,
  • and for resolving problems.

Let's now go further down to check out the details of the incident resolution process.

The first step is to record all relevant details of the incidents and service requests. These details are stored in incident records or service request records, which are passed along to the sub-processes for

  • fulfilling the service requests and
  • resolving the incidents.

For each such sub-process, there's a further level of detail describing the activities to be performed.

If we zoom in we can see that, first,

  • the agents in 1st level support should do an analysis and
  • check the knowledge base for possible known issues and solutions.

After some more activities, it must be decided

  • if 1st level support is able to resolve the incident or
  • if it must be handed over to 2nd level support,
  • ... and so on ...

until at the end of the process

  • we have either resolved the incident, or
  • passed it on to 2nd level support.

If we move to the top area of this diagram, we can also find out what's happening next. Incidents that could be resolved in this process, for example, are now ready to be closed, and if we click on the link this takes us to another process chart that describes the recommended steps for the formal closure of the incidents, such as verifying the quality of the resolution documentation and checking again if the incident or service request is correctly classified.

With this kind of guidance, introducing such processes in your organization shouldn't be too much of a challenge.

A real-world example: The YaSM Support Portal

As for ourselves, we also provide support for our products and try to set a good example, and it goes without saying that we follow our own best-practice processes. For our customers, this means they can find all relevant information in the YaSM support portal:

As in many portals of this kind, users can explore the community forum or start a new post. They can search the knowledge base with self-help instructions - or simply enter some search terms here into this box to search the whole portal for relevant information.

It's also possible to open a support ticket if users don't find in the portal what they are looking for. While tickets are being processed, users can check their status in the support portal. And finally, if somebody wants to get in touch with us directly, our contact information is right here at the top of every page.

And that's it for today. I hope I was able to get across that it is perfectly possible to offer excellent support while keeping the costs in check, and that YaSM provides process templates that make it easy for you to introduce professional support processes in your organization.

Thanks for watching! And as always, if you have any questions we are happy to answer them in the YaSM community!

 

Home      YaSM videos      Don't leave customer support to luck