It’s called the ‘Service Desk’ not the ‘Frustrate your Customer Desk’
helpdesk

It’s called the ‘Service Desk’ not the ‘Frustrate your Customer Desk’

Posted by on Monday, February 3rd, 2014  

 

From my experience providing technical support to end users, I’d like to share some tips I picked up along the way on how to provide customers with the best “Help Desk” experience possible. I believe the goal of every Service Desk should be to communicate effectively and resolve the customer’s issue as quickly and efficiently as possible. By the time customers initiate contact by opening a support ticket, they are already frustrated with the problem they are having. We’ve all been there, and the last thing we want is more frustration.

Looking back, these are probably some common sense tips, but when you’re first starting out, you may not initially think about them. All of these tips are centered on what I found to be the biggest frustration around opening Support Tickets: excessive and needless back and forth communication in order to gather all the necessary information to begin work. The best advice I have to offer: The more information you can get up front, the better.

Not only will this eliminate the needless back and forth communication, it will also lead to a quicker, smoother resolution of the ticket and a much happier customer.  The last thing you or the customer wants is to be playing a game of Support Tennis, Ping Pong, whatever you would like to call it, you get the idea!

Whenever a request for assistance came through, what I learned to initially ask for from the customer was the following (some may or may not be applicable depending on the issue at hand):

1) The version of SharePoint they are using in order to reproduce their environment as accurately as possible, if needed, to troubleshoot their issue.

2) What environment? IE: Production, Test, QA to determine the criticality of the issue.

3) How many users are affected by the issue? (All users or just one in particular)

4) A detailed description of the problem and steps to reproduce.

5) Asking if the problem happens consistently or if it is intermittent.

6) A sample document if it happens to be a particular document causing a problem.

7) What Browser(s) and version does the issue occur in (to narrow down if it is browser related)

8) The most important piece of information to ask for is a screenshot of the issue and asking the customer to refer to the screenshot when describing the issue.  Actually seeing the problem versus reading about it can make a huge difference and eliminate any misunderstanding of the issue.

Other very helpful information to obtain is any logs based on the type of error and whether it is client-side or server-side (if we do not have access to their environment to obtain these ourselves).

 

Examples of log files:

1) SharePoint ULS logs (These logs will contain information on server-side issues, third party products and SharePoint in general. They are also the first place to check if your error gives you a correlation ID. Be sure to check the logs on all WFE’s in the farm.)

2) Fiddler Logs (For debugging client-side errors. Fiddler must be run on the client machine and the issue needs to be reproduced with the tool running to capture any errors).

3) Console Information from IE Developer Tools (helpful if any JavaScript errors are present).

4) Application and System logs from the servers.

Part of the mystery to unraveling SharePoint errors is often solved by cross referencing the application and system logs with the ULS logs. Looking at the time stamps between the logs can give valuable information and clue us in to what is going on.

I also learned to keep track of any recurring questions or resolutions to problems that would be helpful to other users. These issues are always good to put into a Knowledge Base article or a blog. Your customers may or may not read these before coming to you for assistance, but they are always good to have as a reference. Sometimes an answer to a customer is as simple as being able to point them to an already written Knowledge Base article. It really helps a lot and they appreciate the quick response. I welcome any other tips anyone may have.

Subscribe to RSS Feed

Sign Up for Newsletter

Leave a Reply