How to Successfully Implement & the Benefits of Customer Logging of Service Requests
Save Money with a Self-Help Web Portal for the Help Desk & Customer Service Organizations
Why should customers log their service requests?
How can you prepare an economic analysis of the benefits?
Overview
There are many myths about letting customers into your problem management system. I often hear support managers say that their customers won't take the time. "Our customers would rather call us than enter their own calls." I also hear them say that their customers are not capable of entering the correct information and support would just have to call the customer anyway." It is my experience from working with many companies, that the perceptions do not fit reality. What I will try to do in this paper is to present the advantages to customer logging and tips to make it successful.
What is Customer Logging?
Only a few service event management systems available today have a customer interface into the system. Usually these take the form of a web application. Whether client or web-based, the customer interface is usually a much simpler version than the full-blown application. In all cases, the customer documents what their problem or request is and submits their request receiving a confirmation and service event tracking number. Some applications also allow the customer to enter their own severity level, pick the Nature of Request category, attach an asset, and/or attached a document.
Advantages
- 24x7 Coverage for Customers
- Most support organizations have limited coverage. A typical day may be 10 hours a day five days a week. Who covers after hours and on the weekend? Often there is a duty person that has a pager for emergencies. Without anyone manning the phones, your customers working late, or on weekends or from home cannot make non-emergency requests. When you allow your customers to log their own requests, it is like having a 24x7 support desk without the expense.
- Support Cost Savings
Support Front Line Logging Overhead
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.
Web-based Customer Logging Overhead
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.
Overhead Savings Told by the Volume
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).
| Total email/phone requests process hours per year | 3002 |
| Percent of service requests closed at the Help Desk | 52% |
| Status Requests process hours per year | 394 |
| Web submit usage in first year | 19% |
| Total time savings in Help Desk by the end of first year (hrs) | 517 |
| Total savings (Help Desk + Customers) | $135,164 |
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.
How to Successfully Implement Customer Logging
-
Know your current state. You should first benchmark your current support center workload.
- Numbers of service requests by the various submit methods (by month).
- Length of time that it takes to document a single service request by submit method.
- Develop a process for providing superior service to Web submissions.
- Develop a marketing plan to encourage your customers to try out the Web.
- Dedicate resources to processing Web submissions.
- Track progress and report at least monthly.
Since we have already discussed methodology for determining current state, we will now discuss the other requirements.
Develop a process for providing superior service to Web submissions.
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:
- "I want someone to be there when I call."
- "I want to know that they have heard me and that they understand my request."
- "I want to be treated with respect."
- "I want to have a knowledgeable person make sure that my request is resolved."
- "I want to know when I can expect resolution."
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.
Market your new service to your customers
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.
Dedicate resources to web 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.
Track web submission trends
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.
Conclusion
The benefits to both the support center and to customers are significant when customers favor web submissions over other forms of submitting service requests. In order to successfully convince customers to switch the support center must have strong processes in place. The support center must also market the benefits to their customers and be dedicated to providing superior service to those customers who submit web requests.
Financial Benefits to Customer Web Submissions
Current Situation |
Year 0 | Year 1 | Year 2 | Year 3 | Year 4 |
|---|---|---|---|---|---|
| Email/Phone Processing Analysis | |||||
| Total Calls/Day | 228 | 230 | 262 | 273 | 284 |
| Total Calls/Day (Less Status Req) | 201 | 212 | 246 | 259 | 273 |
| Total Email/Phone Submits/Day | 221 | 186 | 141 | 123 | 99 |
| Days Per Year | 247 | 247 | 247 | 247 | 247 |
| Time Per Email/Phone Submit (Min) | 3.3 | 3.3 | 3.3 | 3.3 | 3.3 |
| Email/Phone Processing Time/Day (Hrs) | 12.2 | 10.2 | 7.8 | 6.8 | 5.5 |
| Total Email/Phone Process Hours Per Yr | 3004 | 2531 | 1922 | 1669 | 1350 |
| Percent Calls Closed @ Help Desk | 52% | 52% | 53% | 54% | 55% |
| Status Requests Analysis | |||||
| Total Status Requests/Day | 27 | 18 | 16 | 14 | 11 |
| Time to Process Status Req. (Min) | 3.5 | 3.5 | 3.5 | 3.5 | 3.5 |
| Total Status Req. Time/Day (Hrs) | 1.6 | 1.1 | 0.9 | 0.8 | 0.7 |
| Total Status Req. Time/Year (Hrs) | 394.2 | 265.1 | 226.5 | 196.7 | 163.7 |
| Salary Analysis | |||||
| Salary of Help Desk Tech./Hr. | $21 | $22 | $23 | $24 | $26 |
| Benefits of Help Desk Tech./Hr | $6 | $7 | $7 | $7 | $8 |
| Salary of Help Desk Consultants/Temp/Hr. | $38 | $38 | $40 | $42 | $44 |
| Avg. Weighted Salary of Help Desk Techs./Hr. | $27. | $28. | $30. | $31. | $32 |
| Cost of Email/Phone Processing | |||||
| Salary Cost for Email/Phone Processing | $81,488 | $71,330 | $56,739 | $51,592 | $43,704 |
| Salary Cost for Status Request | $10,692 | $7,472 | $6,686 | $6,080 | $5,297 |
| Total Help Desk Salary Cost | $92,179 | $78,802 | $63,426 | $57,672 | $49,001 |
| Annual Additional OT Charges | $15,756 | $12,605 | $10,084 | $8,067 | $6,454 |
| Total Help Desk Salary w/ OT | $107,935 | $91,407 | $73,510 | $65,739 | $55,455 |
| End User Cost Analysis | |||||
| Number of Customers | 1,200 | 1,250 | 1,300 | 1,350 | 1,400 |
| Customer hours lost per call | 0.50 | 0.50 | 0.50 | 0.50 | 0.50 |
| Customer Annual Days Training | 2 | 2 | 3 | 4 | 4 |
| Annual Burdened cost per person | $100,000 | $100,000 | $100,000 | $100,000 | $100,000 |
Savings Analysis |
Call Handling Savings | Year 0 | Year 1 | Year 2 | Year 3 | Year 4 |
| Actual & WEB Usage | 0% | 19% | 46% | 55% | 65% |
| Cost to process calls without ARWeb | $81,488 | $85,420 | $101,921 | $111,210 | $121,122 |
| Reduced Customer Turn Around Time | |||||
| New Requests: | |||||
| Mins. per call-Now | 3.3 | 3.3 | 3.3 | 3.3 | 3.3 |
| Mins. per call-w/ WEB Submit | 0.4 | 0.4 | 0.4 | 0.4 | 0.4 |
| Status Requests: | |||||
| Mins. per call-Now | 2.7 | 2.7 | 2.7 | 2.7 | 2.7 |
| Mins. per call-w/ WEB Query | 0.5 | 0.5 | 0.5 | 0.5 | 0.5 |
| Total Savings - $ | $64,323 | $63,138 | $70,946 | $82,622 | |
| Reduced Time to Process Calls | |||||
| New Requests: | |||||
| Mins. per call-Now | 3.3 | 3.3 | 3.3 | 3.3 | 3.3 |
| Mins. per call w/ WEB Submits | 0.4 | 0.4 | 0.4 | 0.4 | |
| # of WEB Submits Per Day | 35 | 65 | 68 | 65 | |
| Status Requests: | |||||
| Mins. per call-Now | 3.5 | 3.5 | 3.5 | 3.5 | 3.5 |
| Mins. per call w/ WEB Inquery | 0.0 | 1.0 | 1.0 | 1.0 | 1.0 |
| # of WEB Status Calls/day | 0 | 9 | 8 | 7 | 6 |
| Total Savings - $ | $70,842 | $76,596 | $84,102 | $94,266 | |
| Total Time Savings in Help Desk (Hrs) | 517 | 858 | 877 | 830 | |
| Total Savings-Call Handling | $135,164 | $139,734 | $155,048 | $176,888 | |