Support Essentials: Using a Checklist

Every support exchange is fundamentally about one thing: solving a problem for a customer. While each customer is different, and each issue has its own nuances and context, aspects of the problem-solving process can be standardized to great effect.

The best way to standardize support processes is to make and implement checklists. Simple checklists that itemize processes make it easier for teams and individuals alike to provide thorough support more consistently—while making customers happier with the faster, more effective support they consequently receive.

Checklists? Really?

If you’re not sold on the power of simple checklists, check out Atul Gawande’s 2011 bestseller The Checklist Manifesto: How to Get Things Right. Gawande shares stories of how simple checklists have had remarkably positive impacts on a wide range of fields, from emergency surgery and homeland security to investment banking and skyscraper construction.

If people in these fields can extract value from simple checklists, surely those of us who provide customer support can, too.

An Example: Stellar Support in Ten Steps

The unique needs of your support team will dictate what things end up in your checklists. There may be one “master” support checklist, or even separate lists for separate products if the products are different enough from each other.

The example checklist in this post is for providing WordPress plugin support (this is the blog for The Events Calendar, after all), and it goes a little something like this:

• Step 1. Can you reproduce the problem?
  • If a person comes to the support forums and reports an issue, first try to see if you find the same problem on your own site.
• Step 2. Are there any other reports of the same problem?
  • Regardless of your findings in Step 1, then check to see if anyone else on the support team has verified the issue and has reported it to the support or development teams already.
• Step 3. If “yes” for Step 1 or 2, is there a bug report so that our developers can fix the problem?
  • Even if the issue has been reported, has it only been reported informally? Or has a proper bug report been made? Bug reports are essential for coordinating and enacting the fixing of any bug.
• Step 4. If there is no bug report, make the bug report.
  • Support technicians are often the folks who unearth bugs, and at The Events Calendar, we usually write up the formal bug reports, too. They are then passed along to the development team.
• Step 5. If there is a bug and an official bug report already, then inform the customer of the bug.
  • At this point, we’ve confirmed that the customer’s issue is a bug in our code. A bug report has been made, so we now need to inform the customer about the situation and when the arrival of a fix can be expected.
• Step 6. If “no” for Step 1 or 2, then request the customer’s system information.
  • If you cannot recreate the bug yourself, and nobody else is reporting the same issues, then it’s time to take a look “under the hood” of the customer’s site.
  • We do this by building a System Information panel right into our plugins, which lists many relevant technical details about their WordPress installation, plugins, themes, and PHP settings. When appropriate, we request the sharing of this System Information to help us investigate more closely.
• Step 7. If the customer is not up-to-date with their software, ask them to update.
  • If the System Information requested in Step 6 reveals that the customer is using out-of-date software, no further actions can be taken until we get the customer up-to-date with the latest code.
• Step 8. If the customer is now up-to-date and issues still persist, ask them to test for plugin or theme conflicts.
  • Let’s recap: at this point, the customer has reported an issue, but we cannot recreate it. We also cannot find anyone else reporting the same issue. We have verified that they are using all of the correct and up-to-date versions of software. So if issues persist at this point, then they could be—and generally are—arising from a code conflict on the site.
  • We wrote up a simple guide for testing for code conflicts in WordPress here, to which customers are referred at this point in the problem-solving process.
• Step 9. If the customer is up-to-date and there does not appear to be a code conflict, try once more to reproduce the problem yourself.
  • Depending on the issue, it may be worthwhile to make one last attempt at reproducing the problem.
  • In this last phase, we tend to try to grab any extra details that we might’ve missed earlier: we might request screenshots of the issue from the customer’s perspective, for example, or we might ask them to turn on WP_DEBUG or other debugging tools.
  • If no extra information is available, or is but doesn’t help, then it’s time to escalate the support issue and move on to step 10.
• Step 10. If you continue to fail to reproduce the problem, but the problem persists, escalate the issue to a senior team member and/or developer.
  • Our support team has a lot of technical knowledge, but we cannot match the development team in terms of familiarity with the code base of our products. If the issue is persisting after all of the above steps, then it’s worth getting the attention of developers to see if they have insights on the problem. They rarely come up empty-handed.

---

Here’s a simplified version of the above checklist, without all of the annotations and comments:

1. Can you reproduce the problem?
2. Are there any other reports of the same problem?
3. If “yes” for Step 1 or 2, is there a bug report so that our developers can fix the problem?
4. If there is no bug report, make the bug report.
5. If there is a bug and an official bug report already, then inform the customer of the bug.
6. If “no” for Step 1 or 2, then request the customer’s system information.
7. If the customer is not up-to-date with their software, ask them to update.
8. If the customer is now up-to-date and issues still persist, ask them to test for plugin or theme conflicts.
9. If the customer is up-to-date and there does not appear to be a code conflict, try once more to reproduce the problem yourself.
10. If you continue to fail to reproduce the problem, but the problems persist, escalate the issue to a senior team member and/or developer.

Keep Yourself In Check

It’s hard to not benefit from simple checklists. They are useful no matter how trivial or obvious they seem:

• If any of the steps seem very obvious, then this means that those steps are easy to overlook—remembering to do those obvious steps each time can save a ton of time and hassle.
• If any of the steps are not obvious, then, well, the checklist reminds you of them!

Even if your team doesn’t use checklists as a whole, or as a matter of company policy, use checklists in your own day-to-day work. They can make your life easier while improving the quality, consistency, and consistency of quality of your work.

---

This is the second post in a series from The Events Calendar team, Support Essentials. The next post is coming soon—subscribe via RSS or follow us on Twitter or Facebook to make sure you don’t miss it!

If you’re new to the series, check out the first post—it’s about communicating effectively while providing support.