When getting an error on your software system it can be extremely frustrating for your users as well as operationally disruptive to your business and as a result you just want the issue fixing as fast as possible.
Many of the delays with resolving issues stem from poor initial communication and in getting detailed information regarding the fault. If we take a “typical” support issue, it may play out something like this:
Disaster strikes and your software system displays an error.
What do you do?
Step 1: Copy or screen shot the error and send this via e-mail to your software vendor’s support team.
Step 2: Make a cup of Coffee and wait for a reply notifying the issue has been resolved.
The Software Support Team
Step 1: E-mail arrives with a screen shot of an error with no other/or very little information detailing what has caused the issue, when it occurred etc.
Step 2: Raise a support Job in the support system, E-mail the client asking for further information. The error cannot be critical as they have e-mailed.
Step 3: Make a cup of Coffee and wait for response to e-mail and move onto the next Job while we wait.
We have now introduced delays which could have easily been avoided into the life cycle of the support job, so how can these be eliminated?
The first delay is with the Client and the fact that quite often a Job is raised with too little information. Often a screen shot of an error, or even the error details is not enough to correctly diagnose an issue with more information being required to help put the error into context.
The second issue is one of prioritisation and again this initial determination of how critical an error is should be made client side. A minor system issue can result in major operational disruption and as a result this is a major issue for the client but from a software vendor’s perspective could be identified as a minor. When raising any support issue you should always try to qualify how urgent this is.
The final piece of the puzzle is the information provided. Delays can again be avoided by supplying as much information as possible about the error. This aspect of the process can often cause the biggest delay with e-mails and phone calls between client and vendor trying to compile all the relevant information. While it is impossible to give a comprehensive list of information to provide, as this can change on an issue by issue basis, this info can generally be categorised into the following areas:
Which operators are affected by the issue? Which Operator caused the issue? Are they still having the issue?
When did the issue occur? Was it an isolated incident or is it ongoing? Provide times if at all possible.
How did the error occur and can it be replicated? Provide as much detailed information as possible on how the error occurred. Assume the support person does not know your system “intimately” and provide as much info as possible in regards to what menu’s you use to get to program that resulted in the error.
Step by step examples are especially useful on how to replicate and cause the error especially when there is more than one way to undertake a particular process.
Why did the error occur? Often the why falls within the remit of the software vendor but occasionally the client may be able to shed some light on the “why”. For example any external factors to the system that your software vendor may be unaware of, power cut, loss of internet connection etc. all may explain why an error has occurred.
Now hopefully any lag caused my insufficient information at the point a support job is raised, or in prioritising the support job, can be eliminated or certainly reduced. Now you can make that coffee and wait for your software vendor to get back to you.