How to write a good support ticket

In projects where SMILE is engaged in ongoing Support and Maintenance, we understand and take seriously the fact that we are responsible for the resolution of issues. However, responsibility for the speediness and efficacy of these resolutions is shared between us and our customers. We will always do our best to investigate a support ticket to the maximum limit of our understanding of it. But you can help us improve and increase that understanding.

While we do have experience in diagnosing and fixing a problem in its entirety from the simple description ‘Website Broken’, the fact is this takes hours longer than it could. We understand that it’s easy to panic when something isn’t functioning the way it should. But taking the extra 5 minutes to provide us with an accurate but succinct subject line together with even a 2-sentence description written in plain English can increase our understanding phenomenally, not to mention the inclusion of supporting evidence such as screenshots and frontend/backend URLs.

Broadly, the help that you can give us exists in the following two steps. The first is best summed up as telling us about the problem being experienced, the second is in showing us the problem:

1. Clear description (Tell) This means describing one single issue in as detailed a manner as necessary. Very few support tickets require an essay. But they do require you to guide us towards the problem in as economic a way as possible. Remember, when we start reading a ticket, we have no prior knowledge of the problem. Help us to help you by describing:
   • What is happening? Who is it happening to?
   • Is this a front end or back end problem?
   • Is this a problem specific to the flagship site? Or other platforms on your network?
2. Evidence gathering and presentation (Show) Sometimes it is much more powerful and helpful to be shown a problem alongside being told about a problem. This why we often ask for:
   • Screenshots – It’s so useful for us to be able to see what you see.
   • Links – as well as directing us to an example page where we can see the full manifestation of a problem, there is quantitative information contained in URL structure and the code of a problem page which our dev team can scrutinise for a sometimes-instant diagnosis.
   • A step-by-step walkthrough guide in how the problem was encountered and how we might be able to recreate the problem for our own experience.

Every new piece of correspondence takes you an extra few minutes to write and us, an extra few minutes (or hours) to investigate. Being clear from the outset can reduce correspondence and speed up resolution.

How we handle a support ticket

Our troubleshooting flow:

1. A new ticket lands on our Support Desk
2. We read the ticket description, examine the provided evidence and attempt to crystallise our understanding of the problem, in particular: what is happening and who it is happening to.
3. Next, we attempt to further our understanding of the problem by attempting to replicate it. Can we force ourselves to encounter the problem? We can only truly begin to solve it once we can see it with our own eyes. For this, we need to understand step-by-step, what set of actions happened in order for the problem to manifest.
4. Scheduling and delegation. Time is made to schedule in work on the issue. The issue is assigned to a developer.
5. The developer diagnoses the issue at code level
6. The developer works on fixing the issue in a local environment.
7. The fix is tested and deployed.
8. Once resolved, the issue is closed and the customer notified.

Note how much of the above workflow is admin-based. Only points 5, 6 and 7 involve code modifications. Developer time is precious and we always want to be lining up as much evidence as possible before handing the problem over to the team. Steps 5, 6 and 7 can take some time. But if the issue hasn’t been clarified and recreated, this time can double or triple.

What slows us down on support

• Probing for more detail due to:
  • Unclear description
  • Lack of evidence gathering
• Separating multiple issues described on a single ticket into several separate threads.
  • When several things seem wrong or broken at once, it’s easy to make the mistake of assuming they are all related or part of the same issue – or simply to use one support ticket as an opportunity to flag multiple problems. Please avoid this where possible. It takes us time to split the ticket up into several separate threads for investigation. At worst, you risk the chance that our team accidentally overlooks one of your points. Give your support queries the best chance they have to be resolved by restricting them to one issue per ticket.
• Organising/removing duplicate threads
  • Poor inter-team communication can result in the same issue being raised by multiple team members within the same office.
• Unhelpful subject description
  • The subject line of your email will become the title of the ticket in our support desk. Help us easily recognise your issue among all the other issues we receive. ‘Intranet Login – Error message appearing for Course Managers’ stands out much better than ‘Login Broken’.
  • While forwarding an email from a colleague is quick and easy, remember that the ‘FW:’ subject line comes to us too. Take time to rewrite this if necessary.
• Awaiting clarification/feedback from clients
  • Prompt responses mean we can move forward with the next stage of investigation sooner.
• Prioritising sheer load due to a combination of the above.

Support is one of the most important things we do and we’re always looking to improve our service. We hope this article has highlighted some of the challenges we face on Support and the ways in which you can help us to help you better and faster. If you have any questions or comments, please get in touch.