I am regularly involved in Support Requests (SRs) where expectations are not met and which cause irritations. We want to avoid irritations at all costs, as this will be at the expense of the lead time and the implementation of the solution. A large part of these irritations can be prevented by creating the right expectations. With this article I want to provide some insight and recommendations on how to deal with SRs.
SRs can often be created in several ways. The most commonly used ways to create SRs are portal, chat and telephone. Which method do you use exactly at what time? Personally, I would recommend the following:
- Portal: The preference for registering an SR lies with the portal. To register an issue within a portal, you usually have to log in with an account that is linked to the company you work for, which makes basic data immediately available and you also have to provide minimal information before the SR can be created.
- Chat: I would only advise using the chat when you do not have access to the portal and still want to register an SR.
- Telephone: I would register an SR by telephone when there is an urgent issue that needs to be resolved as soon as possible (outage).
After you have chosen the method to register an SR, it is important to choose the right severity for creating an SR. Below you can see which severities are most common and at what time you should use these. Please note that there are response times related to the severities and that it is also expected that the person who registered an SR (and/or his/her backup) is also available. Example: When you register a “Severity 1 – Critical” ticket you can expect 24/7 support, but you must also be available 24/7.
Severity 1 – Critical
A production system is down, or a critical production issue exists that severely impacts the use of the Software or Service Offering and no workaround is available.
Severity 2 – High
Major functionality or performance degradation of the system or business operations is severely impaired.
Severity 3 – Medium
A partial, non-critical loss of functionality or use of the Software or Service Offering.
Severity 4 – Low
Mostly used for answering questions and as a pro-active SR during changes.
We have chosen both a method and severity for registering an SR, the next step is to provide the SR with information so that the person assigned the SR knows exactly what is going on and can deal with it.
Best practice:
Provide as much information as possible and include a colleague (as a backup) during the initial registration of an SR. What actions do you perform before you encounter the issue (provide click path), what is the exact error (provide screenshot) and what is the business impact.
Minimum information (if applicable):
Provide information on all the software components that have been involved (include environment and versions)
Include the device type that is used (including versions)
Provide the amount of impacted devices/users
When dit the issue occurred for the first time
Have there been any changes made
Provide as much log files as possible (involved components / device)
Provide screenshots or a video while reproducing the issue
Provide a detailed Description
Hope the above helps having a better experience while working on SRs and please keep in mind that it will always be a collaboration between you and the engineer assigned to the SR.
TIP 1: Check if you can reproduce the issue on the latest version of the software. This may provide an opportunity for a quick solution and additional information for the assigned support engineer.
TIP 2: Inform your account team on urgent SR’s by including them on CC of the email communication.
Leave a Reply