A ticket handling checklist
✅ Writing a post about checklists
Now, as we approach the end of all things 2023, we’ve come full circle here at Andy’s Support Notes. As you may recall, I began the year with a long series on writing a great support email:
Writing a great support email: content • Buttondown
Be content with your content
Writing a great support email: structure • Buttondown
Mens sana in corpore sano
Writing a great support email: tone • Buttondown
Don't look at me with that tone of voice
Writing a great support email: style • Buttondown
Stilus virum arguit
Writing a great support email: notes and handoffs • Buttondown
He listens well who takes notes
I was recently having a conversation with another support leader who’s grappling with some operational challenges around issue handling, both within his team and in their communication with other teams across the company. The details aren’t important here—though they do give me good ideas for a future post—but one of the possible mitigations we discussed was implementing and using a standard ticket handling checklist. This way, even when addressing more stressful customer issues, the support engineer can be confident they’re following the established process and not missing anything critical.
What a checklist is, and isn’t
Before we get to the checklist proper, I wanted to talk a little about what it actually is and, just as importantly, what it’s not.
It is:
A quick reference to existing processes and procedures
Short
Clear
Systematic
Updated as needed
It is not:
Long
Exhaustively detailed
A replacement for formal processes and procedures
A checklist is something you and your engineers can keep in front of you and just work your way down the list, taking actions and checking them off as you go. It’s a way to ensure you’re sticking to your established policies, which are kept elsewhere (but accessible!) and linked to from the checklist in case the engineer needs more details or a refresher for any specific step. If any item on the checklist is more than one line, it’s probably too long. Revise it down.
This checklist needs to reflect the current procedures and best practices for ticket handling. You should be reviewing and revising this and other process documents with your team regularly. Ensure all of the steps are clear, accurate, and useful, and modify or replace any that are not.
The checklist
This example checklist is representative of ones I’ve built and used in various support teams—use it as a starting point for your own team’s checklist. You’ll note that a lot of the steps here are reminiscent of what I wrote about in my ticket handling posts earlier this year. Think of this as a distillation of a lot of that advice.
Read the request thoroughly.
Ask yourself these questions:
Who is asking the question? What is their role?
Do I understand what the customer is asking?
Is the underlying issue clear?
What is the urgency of the problem?
Is it one person having issues? Several? Customer-wide?
What is the level of disruption? Mild, moderate, severe, complete?
Does it trigger your internal escalation threshold?
If there’s still ambiguity, consider follow-up questions.
More details about the problem?
More details about urgency for the customer?
Are there any steps they can take in the meantime?
Check ticket history, you may find useful related information.
For the user
For other users at this customer
What is your current hypothesis about the problem?
Do you need to ask for any clarification?
What information could confirm or refute your hypothesis?
Now you can draft your message. Be sure to include:
Current hypothesis, if any
Questions for the customer
Next steps, if any
If both the question and your answer are clear, offer the solution.
If either of these is not yet 100% clear, continue to gather information!
Before sending, reread your message for completeness and clarity.
Run it by a second set of eyes if it’s long or complex
An abbreviated form of this checklist will continue to be useful throughout the ticket handling cycle. For each message you receive, consider:
Is the customer’s response clear?
Are my own next steps clear?
If so, continue the troubleshooting. If not, stop, and clarify
Similarly, while you’re on a live troubleshooting call with a customer, there’s no time to follow a long checklist, but a shorter version can be kept in mind at all times:
Do we have a goal for this call? If not, wrap it up and regroup offline
Have we achieved the goal? Is there anything else to do? If not, wrap it up
Is something, or someone, missing from your side or the customer’s? If so, offer to reschedule
Parting thoughts
Checklists are great for distilling down a longer process or procedure into a simple list of tasks. But don’t mistake it for an actual procedure. Get the details down first, with reasoning for each step, before putting together a condensed version in checklist form. But once you have those checklists, it will help your engineers be more efficient and much less likely to miss an important step in the troubleshooting process.
Thanks for reading Andy's Support Notes 💻💥📝!