Eleven kinds of tickets
One is not pictured because it would make an ugly macaron
Once you’ve been on a given support team for a little while, you’ll start to see patterns in the kinds of questions and problems you and your team are fielding. While the proportions will change from team to team and product to product, there’ll be a mix of several fairly clear categories. Some tickets may fall into more than one category, and some may shift over time from one to another, but this should be a pretty complete taxonomy. The interesting thing to note is that only some of these ticket categories are actually going to be your team’s responsibility! By figuring out early on in the interaction that a ticket actually needs to go to another team, you can save yourself and your team time and aggravation. Learn to spot all of these kinds of issues, and have a clear path for transitioning tickets to other teams before you need it, rather than making something up as you go.
Good questions. There are often things your product is perfectly capable of doing, but a customer can’t figure out how. No matter how good your documentation and in-app help, there will always be things that aren’t clear. Your job is twofold: get things working for the customer, and work with your documentation team to make things more clear for future users by improving the docs or making it more obvious within the product.
Bad questions. In one team I was on we defined these as ‘this information is available in the documentation, which you haven’t read.’ Calling these questions bad is facetious—the truth is they’re gold, just not for the support team. These questions are a golden opportunity for the customer’s CSM, or prospect’s AE/SE, to swoop in with a quick answer. They get to build a relationship and establish their technical cred, and you get a ticket off your plate. Hand them off immediately, and it’s a win-win.
Off-topic questions. Especially common if your product integrates with anything else at all, you’ll regularly be fielding questions that aren’t about your product at all. ‘How do I use Terraform?’ was a common one in my last role. Depending on the nature of the question, and the specifics of the customer, you can either handle these directly or pass the customer along to their CSM or AE to kindly explain that we can’t support someone else’s product.
Requests for assistance. Like questions, these can be on-topic (actually about your product) or off-topic (everything else). Sometimes these requests are simple (‘help walk me through this complicated process that is well-documented’) and sometimes they’re open-ended (‘can we do weekly working sessions to build a full orchestration setup for your product in our environment?’) and it can be difficult to draw the line between providing assistance and politely declining. While the exact location of this line is going to vary wildly from company to company, and product to product, it’s worth discussing with related teams (particularly sales and customer success) what constitutes appropriate levels of involvement before it becomes necessary to make the decision. This can help avoid mixed messaging and give you backup in conveying the bad news when customer requests cross the line.
Feature requests. These are straightforward: the customer wants the product to do something that it doesn’t already do. Sometimes these are obviously bad (‘I want to be able to make toast with your SaaS security product!’) and are easy to dismiss with a polite brush-off or a promise to open a feature request that will never go anywhere. Where it gets interesting is the vast spectrum from ‘not obviously bad, but not a fit’ to ‘sounds great.’ The good news is this isn’t your problem to solve, unless you’re also in charge of Product (if this is the case, I’m sorry). You can still end the customer interaction by promising to open a feature request, but after that it’s in Product’s hands. The main thing to keep in mind here is that you shouldn’t make any promises to the customer about whether, or when, a feature request might be implemented.
Troubleshooting. Finally, your team’s bread and butter! Something’s wrong, and it’s not immediately apparent what it is. These will more likely than not become a question or request for assistance (trying to do something that’s not well documented), a bug report (trying to do something that’s currently broken), or a feature request (trying to do something that can’t currently be done), but for now you just need to gather information and find out what’s happening.
Bug reports. These have two main sources: one is the result of a troubleshooting issue, where you realize what’s going on that something is broken. The other kind is seemingly easier: a proactive customer recognizes that something is a bug and reports it as such. I say seemingly because although this can save you a lot of legwork, keep in mind that customers aren’t always right. They may think something is a bug when in fact it’s simply not implemented, or works differently than they expected, or they failed to read the documentation. Always accept customer bug reports with gratitude along with a grain of salt. Regardless, the first (and often most time-consuming) thing to do with both kinds of bug reports is attempt to reproduce them yourself, in preparation for passing them along to the engineering team for resolution.
Outage. This is simultaneously the most stressful and, ironically, one of the simplest issues to address from a support perspective. Stressful because, hey, a customer’s down! Simple because in a well-run company this issue quickly becomes a lot bigger than the support team. Engineering, customer success, support, and who knows how many other teams will be involved in the response, so you’ll have a lot of assistance. Now, in smaller or less organized companies, this may not be the case, but how to go it alone in an outage investigation is far beyond the current discussion. If you don’t have a full incident response plan ready and tested, now is the time to start agitating for that. Work closely with Engineering and CS to figure out what escalation paths need to exist and what role your team will have in the ensuing response.
Off-label use. Customers are always using products, particularly software, in ways not intended by their developers. These ones are interesting, but can also become a tremendous time-sink if you let them, not to mention potentially putting your company in jeopardy. Similarly to ‘requests for assistance’ above, spend some time now talking with other teams about what level of assistance from your team is appropriate for these requests. Depending on the use case, it may be intriguing or useful enough that your own Product team gets involved to actually improve the product and officially support it. On the other hand, it may be dangerous enough to loop in the customer’s CSM to formally warn the customer off their plan of action. For example, anything that bypasses or breaks built-in security measures is not something you want to encourage! When it inevitably breaks or causes a security breach, you want written proof that you warned the customer against doing whatever it was they did.
Angry rants. Don’t engage, just hand it to the CSM or AE and wash your hands of it. There’s nothing you can do and it’ll just waste your time and energy.
Non-technical topics. This is basically the ‘everything else’ category, and the appropriate owner for these issues is almost always someone that is not your team. Billing questions? Customer success. Renewals? Involve the AE. In brief, as soon as you recognize that it’s not something that the support team deals directly with, offload it as quickly as possible so you can free up your energy for actual technical issues.
Phew! That was a lot more than I expected when I began writing this. While most of these categories could sustain a lot more discussion, these brief considerations should be enough to get you thinking and planning more deeply about how you and your team will respond to the different kinds of issues coming into your inbox.
Thanks for reading Andy's Support Notes 💻💥📝!