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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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
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
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,
After some more activities, it must be decided
until at the end of the process
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.
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!