How to Successfully Implement & the Benefits of Customer Logging of Service Requests

When I work with various companies, one measurement that I always ask for is the length of time that it takes for the support front line to log the basic information into the problem management system. Most managers do not know how long this takes so I take my stop watch and observe a number of entries. I find that on average it takes about three minutes and nineteen seconds. This is only the basic information. This does not include any diagnosis or resolution.

I timed phone call logging, voice mail logging, email logging, Fax and Web. Voice mail is by far the most inefficient because the support agent usually has to replay the message several times to make sure that it is recorded correctly. Emails usually can simply be cut and pasted. There have been a few support organizations that take Fax requests. These are all manual and take the longest.

For the various submit methods I have also tried to measure how many times and the length of time customers are called back because the information they provided is not sufficient. I have not been able to accurately document this aspect, but the amount of time and effort is very significant once the game of phone tag begins.

When the customer submits their own service request, there is still some overhead required by the support center. They have to (1) verify customer name and location information, (2) read and understand the service request documentation, (3) reclassify the Nature of Request, (4) verify the severity level, and (5) assign it to the correct service group. My observation is that this overhead time takes less than thirty seconds and that includes calling the customer to verify information or to just say thanks.

For every service request entered by a customer you have the potential to save two minutes and forty-nine seconds! You say, "OK, but how about when a customer does not enter the correct information or is vague and we have to call them back". This is a significant problem when they leave a voice mail or they send an email because of the time lag between when they contact you and when you pick up the message or email. However, with a Web submission there can be great savings in time. We need to assume that your problem management system immediately and automatically notifies you of a Web submission and that you have good support processes in place. My experience has been that when you immediately call the customer to thank them they will still be at their desk. This is a very good practice to introduce this new process to your customers. They will be surprised at your response and will gladly give you any clarifying information. It is also a great time for one-on-one training on how to submit the perfect service request.

Let us just look at what volume does to this 2:49 savings. For a detailed analysis, please see the last pages of this White Paper. This is actual numbers taken from one client (first year).

This help desk saved 517 hours of processing time in the first year. That is time that the customer would have had to spend anyway just getting the information to the support organization. 517 hours translates to more than 64 person days that could be used to (1) train front line support, (2) take on more front line responsibility and (3) delay increasing front line staff due to increase volume. After four years, customers were entering 65% of their requests via the web and savings were up to 760 hours for the year. Total savings for four years was 9600 hours or approximately $607,000.

Since we have already discussed methodology for determining current state, we will now discuss the other requirements.

Ultimately, customers must feel that they are receiving better service when they submit via the web than any other way. I have interviewed hundreds of customers in many companies.

One of the questions that I ask is "what do you want from a support center?" Here are the most frequent answers in the order of importance:

If the support center cannot meet the customers' needs when they submit over the web, then they will not use it and go back to their old ways of wanting to use the phone.

There are two processes that I have witnessed that are critical success factors: (1) program the problem management system so that it notifies the support center every time a new web submission arrives, (2) who ever takes the request should personally call the customer back immediately. I have seen this become a game for the support center. In the beginning, this is not a great burden. Remember that you are saving almost three minutes per web request. This call back has great success because almost 100% of the time the customer is there. This addresses the first need the customer has as stated above ("I want someone to be there when I call."). This will relieve a great fear that they are just submitting into a black hole and that no one will respond. The phone conversation can go something like: "This is the support center calling and I wanted to thank you for using our web service. I have your request here. Do you have a moment to go through it with me to make sure that I understand it?" This addresses the second and third need (I want to be heard and treated with respect.). By simply asking for clarification the customer is learning how to better document the next time. The support person then can conclude by stating what is going to be done. On easy requests the customer could be told that they have already resolved the issue or that they were working on it and it would be done in a few minutes. The customer still gets a feeling of being taken care of (the need for a knowledgeable person to resolve it) when the support center says that they have already sent the request off to the appropriate group and that they should expect it to be resolved in a certain amount of time.

Your customers do not like to be surprised. When you make any changes in the way that you provide support, let your customers know well in advance of the change. Three months is an adequate amount of lead time. A well written email explaining the service and benefits to the customer is all that is required. Send it out three months before, then two months before and then once a week before the launch date.

When marketing your new web service, make sure you stress that all your old services are still in effect. Make sure that your customers know that they can still call you any time. In fact, you want them to call you for all emergency (Severity 1 and 2) issues.

If you don't get this point across, then your customers may feel that this is another way that you are trying to avoid talking to them. The point to stress is that you are adding a service (another way to submit a service request) and not taking away a service.

When you turn on the new web service, you need to be certain that you are ready for it. Web service requests must be given priority. After phone calls, make sure that the web requests are quickly addressed. That might mean that you don't answer your emails as fast. Make sure that the web service is covered throughout your normal support hours. Several successful implementations have taken their staff that were on phones and assigned them to handle the web requests when they came in. Since volume at the beginning was not great, this was an easy change. Later when the volume increased, they assigned staff to the web the same way that they assigned to the phones. One company found that they could only have a person on the web service for an hour at a time because of the stress in handling so many requests. Just be ready to dedicate resources in an organized manner.

It is important to know where you are spending your time. That is why I suggested that you start with a benchmark from which to measure. You will probably find that initially those customers that usually sent emails will switch to the web. Those that use to phone will eventually switch to the Web. Knowing the change will help you adjust your scheduling of resources. Below is an actual chart of the initial phases of a web implementation. Note that for the first six months there was a one-to-one correlation between the number of web submissions and emails. After six months customers began shifting from phoning the support center to submitting over the web.