Streamlining ticket handling part 1: information gathering
Working smarter, not harder
Last week we discussed categorizing the support issues your team is handling—once you have this information available, you can start thinking deeply about those different types of issues and how to go about investigating them. Every customer request is going to be unique in some way, of course. But if you’ve chosen your categories well, you’ll have a pretty clear idea of the kind of information that will be helpful when beginning the investigation.
For the various headings you have identified as common support ticket categories, spend some time to figure out a plan of attack.
- What information is critical for triaging and investigating this type of issue?
- Will live troubleshooting move things forward more quickly?
- Is there documentation or other already-available information we can share with the customer? If not, should there be? If so, should we send it, or explain another way?
Today we’ll be focusing on that first bullet point. The easiest way to get a head start on handling a customer issue is to know immediately what kind of information you’ll need to investigate. This can be broadly split into two types: information that you need to request from the customer, and information you can gather internally. The former you’ll need to explicitly mention to the customer, but while they’re collecting it, you don’t need to be sitting idle. You can collect the internal information at the same time, and getting a start on the investigation while you wait for the customer response.
For each of the categories of common support ticket you have identified, spend some time ahead of time and put together a list of information to gather. That way, the next time a customer experiences, say, a networking issue, you’ll have a list already prepared that you or one of your engineers can consult to help expedite the information-gathering phase of the support investigation.
Information from the customer
While this will vary across issue types, there’s almost always something you can ask the customer to work on collecting, even if you strongly suspect that the issue is on your side. (In situations like that, it’s always better to give the customer something to do while you frantically collect your own data to pinpoint the issue, so it’s a good idea to have something ready to ask for.) At minimum, information about the customer environment (platform, system resources, version of product) will assist with reproducing the issue on your side, so that’s almost always useful to request. Some other things to keep in mind when putting together what customer information would be useful for a given support issue category:
- Provide instructions: even if it seems completely obvious to you that you get, for example, the version of Mac OS from ‘About this Mac’, don’t assume the customer knows that too. And for anything even slightly more esoteric, provide step-by-step instructions. Maybe even a screenshot or video, if you’re feeling ambitious. If you find yourself providing the same instructions over and over again, make a macro (see ‘Automation’ below) or put together a troubleshooting document that you can point your customers to.
- Provide reasons: it’s easier to convince customers to go and collect things for you if you can tell them why you need them. Just saying ‘what’s the free disk space on the machine?’ may get ignored, but if you contextualize it with ‘we’ve seen errors like this in the past if the root volume has filled up’, you not only give them a reason to find out, but may help them realize for themselves how to solve their problem.
- Don’t ask for anything irrelevant: while it’s good to give the customer something to work on, keep in mind that you’re imposing on their time and patience. Have a crisp list of things to request, and stick to that list unless you have good reason to request something else in order to avoid stretching their willingness to assist.
- Pay attention to product supportability: I go into this more below, but if the information the product itself provides is insufficient, particularly via logs on the customer side, that is an issue that must be raised regularly with the product team. It is hurting your troubleshooting process and wasting everyone’s time.
And while the customer is (you hope) collecting this information for you, don’t rest and wait for a response. There’s plenty you should be investigating already on your side.
Information you can gather internally
The most obvious candidate for internally accessible information, particularly for a SaaS product, is product and backend logs. If your product has a SaaS component, or even if it just reaches out to servers your business controls, there will likely be some sort of record of that. If you’re lucky, the logs will be both useful and comprehensive, not to mention archived for at least a few months. Your team should familiarize itself with what is available, how to access those logs, and how to interpret them. What’s more, you should pay close attention to how useful those logs are. Years of log retention is great, but not if the information logged isn’t actually helpful in your troubleshooting process.
If the logs your product are generating are difficult to parse or don’t contain the information you need, the best time to figure that out is before you need them for an investigation. Prioritizing supportability in the product you’re expected to support is a whole topic of its own, but one worth discussing at another date. For now, though: investments in supportability can be difficult for overloaded product managers to come up with on their own, so it is important that you and your team keep on top of this and bring suggestions as early and often as you can. Better and more legible logging is a great example—not something engineers or product management might prioritize on their own, but it can be crucial to a successful support investigation.
Taking a step back from logs and other data you and your team can collect directly from the product, there are other pieces of information you can also obtain without reaching out to the customer. A few examples:
- Current customer use cases: here, customer success is your best friend. Coordinate with the customer success manager (CSM) assigned to this account to learn more about what they’re trying to accomplish with the product. At the same time, you’re looping them in on issues they’re currently experiencing, which can be hugely valuable to the CSM.
- Customer deployment architecture: do you know how your product is deployed with this customer? How many instances and where? What does their network look like? If you have an up-to-date deployment architecture for this customer, you won’t need to ask them all of this, except to confirm it is still correct.
- Other related issues recently reported by this or other customers: I’ve definitely mentioned this before, but check through your ticketing system (and consult the CSM) to determine whether this is a new issue or if it’s been reported already. Check older tickets for some directions you might investigate next, too.
- Current customer satisfaction: the CSM can help here, too, by giving useful insights as to whether the customer is already frustrated or if they’re likely to give you more grace in resolving this latest issue.
- Sales/renewal cycle information: is this a prospect or a customer? Are they in the middle of evaluating the product, or is a renewal coming up? Determine the assigned account executive (AE) and coordinate with them as well to make sure you’re taking any additional urgency around sales/renewals into account.
By the time you’ve finished gathering all of this information, with some luck the customer has already collected the other data you’ve requested, and you’ll be ready to move forward with the cooperative troubleshooting process.
Automating the ask
Once you’ve got a solid list of information to request from the customer, and to gather on your side, it’s tempting to think ‘I just need to make some macros now, one for each category of ticket, and can save myself the trouble of typing it out every time a new ticket comes in.’ While macros (prewritten email templates) definitely have their place, it’s important not to get too complacent. Even though you’ve bucketed all of your issues into more or less well defined categories, there are enough differences from case to case that you can’t just rely on a canned ‘please send us all of this information’ message without some additional customization.
Here’s how I’d suggest approaching it: for each of those categories, write up an incomplete macro. Skip the first and last sentences, for instance, and only fully write out the actual requests for information. This will force the engineer who’s using the macro to actually engage with the message before clicking send. They’ll be able to think about whether there’s anything different enough about this case that they should be customizing their request for information. And if you want to be extra-sure nobody is abusing the macro, add an additional garbage phase like “DELETE THIS” to the bottom of the message. Then you can have your own rules to trigger if any messages go out with that placeholder intact. (I disclaim all responsibility for angry or confused customers if you do this, though!)
As your company grows, and your customer base (ideally) grows with it, you’ll need to start looking for ways to streamline your ticket handling operations. Saving your engineers the trouble of starting from scratch with every ticket they handle is a significant efficiency boost, and determining ahead of time which information is likely to be handy is a great place to start.
Thanks for reading Andy's Support Notes 💻💥📝!