Ticket response standards: updating open tickets
Have more standards!
Your support process has a blind spot. Your team is doing a great job responding to questions and solving immediate problems, but longer-running issues are getting neglected. Customers who’ve suggested specific product improvements aren’t getting notified when those improvements are finally implemented. Long-standing bugs are solved, but customers have to find out about it on their own. In short, while support responsiveness is great for new issues, a lot of older tickets are falling through the cracks and customers are starting to complain. How can you get a handle on this and make sure your support experience is excellent across the full ticket lifecycle?
Continuing our discussion from last week, let’s talk today about setting standards for regularly updating your team’s open tickets.
Why?
While it is vital to commit to quickly responding to new support issues, it’s just as important to the overall support experience that you establish and enforce response standards for older tickets as well. A large part of building a successful support organization is establishing and maintaining user trust in the service you provide: if customers don’t think your support will be helpful, they may not bother even reaching out. A good first impression in responding quickly to new requests is great, but if you don’t follow through with longer-running tickets, you’re squandering the goodwill you’ve started to build. If on the other hand you provide regular updates so customers don’t have to keep chasing you for more information, you’ll cement your reputation as helpful and diligent, meaning the next time your customer has a problem, they’ll ask for help instead of suffering in silence or just starting to look into your competitors.
Types of open tickets
Tickets that don’t fall under the heading of ‘one response, close ticket’ can be of several types. (I’ll use Zendesk terminology here, since that’s what I’ve been using most recently, but the concepts are valid for any ticketing system you may be using.) Let’s look at each one in turn, and consider what a reasonable expectation for ticket updates might be for issues in that state.
Open
This status applies to any issue where the customer is waiting on an update from you. These are the most important issues in your system, because these issues are typically longer-running problems where you have to investigate or pull in other resources on your side. Every day you’re not updating the customer is one more day they’re still experiencing issues and wondering when, if ever, you’ll resolve the problem for them. Typically a response cadence of at most two days is appropriate for these issues. Even if you don’t have any new information, a simple ‘we’re still looking at this, we apologize for the frustration’ can go a long way towards assuaging customer annoyance. The faster you can respond to these issues, of course, the better off you’ll be, but two days is a useful maximum to aim for. Looking ahead to Setting due dates below, you should also try to set expectations for when the next update will come, so the customer isn’t left wondering.
One exception to this, however, is critical customer issues. If a customer is experiencing an outage due to your product, two days is far too long to go between updates. Aim to update those at least once a day, if not more frequently. If your outage is going on more than a day, of course, you’ve got much bigger problems to solve. But even though your team is probably powerless to resolve systemic issues with your product, you can still provide regular customer updates through the incident.
Pending
This is any issue where you are waiting for an update from the customer. (If you also owe the customer some information, then the ticket should be Open, not Pending.) These are the easiest issues to forget about, since the customer will contact you when they have more information, right? Yeah, not exactly. Your request is not usually their top priority, and in order to keep things moving you may need to remind the customer that you’re waiting on them. Nicely, of course. Again, how long you want to wait between reminders may vary somewhat depending on how important this issue is, but a good rule of thumb is to nudge them after no more than a week of silence.
While we’re on the topic, it’s important to be aware of whether the customer is responding at all on this issue. If you’ve sent them a couple of reminders with no response at all, it’s time to escalate. Though this is not common on support teams, I find that it’s very effective to involve the appropriate customer success manager (CSM) at this point. They are in a position to determine whether they want to escalate the issue on the customer side, or just close it. Either way, close the loop with the customer by letting them know you’re closing the issue. This may be just the motivation they need to actually engage again!
On-hold
Any issue where neither you nor the customer, but some third-party, is responsible for the next steps is On-hold. This can encompass any number of situations, for example:
A reported bug is pending updates from Engineering
A feature request is waiting for acceptance (or rejection) by the Product team
A reported issue is in fact due to a problem with a third-party product, and both you and your customer are waiting for that third party to update something
Like the Pending status, it might seem like these issues can be safely backburnered until someone else gets back to you. And while theoretically this is the case, think about it from the customer’s perspective. They’re having a problem, and they’re not hearing anything from you. It doesn’t matter to them that the ball is actually in someone else’s court. What matters is the radio silence from you. So don’t let that happen. You should aim to update the customer on these tickets at least weekly, unless you’ve previously agreed with the customer to a different update cadence (see Setting due dates below). Ideally you’ll be able to get a status update from that third party first, and convey it to the customer, but at a bare minimum you should be letting them know that you’re still monitoring and waiting on whoever, and will continue to keep the customer updated.
Setting due dates
As I gestured at under On-hold above, sometimes it makes more sense to set expectations in advance that they won’t be hearing from you for a certain period of time but you’ll provide an update by date X. But the thing about this is—it’s worse if you set that expectation, and miss it, than if you didn’t set it at all. So the moment you find yourself writing something like ‘I’ll let you know in a month’ or ‘I’ll reach out again on July 31’, you should immediately give yourself a due date for that issue. Many ticketing systems will let you set this within the ticket itself, which is ideal. You can then let that ticket snooze until the due date arrives, and ensure (via automations) that you’re notified as the date approaches and are able to gather any relevant customer updates. If you’re not able to set this up within your ticket system, then use your calendar. Whatever it takes, don’t miss that date.
Implementing these standards
The best way to get your team used to regularly going through their longer-running tickets, updating where necessary, is to take a three-pronged approach:
Automations: set up notifications in your ticketing system using the thresholds you’ve established for the various ticket types. Set the expectations that your engineers should be paying attention to these notifications and updating their tickets accordingly.
Designated backlog time: have everyone on your team block off time on their calendars, at least once a week—ideally more. During this time, they should be going through their own ticket backlog, checking on status and seeing if there are any updates to share with customers. This will get them into the habit of keeping up with their own ticket backlog.
Spot checking: Insert quote about trust-but-verify here. As a support leader, you should keep tabs on all open tickets across your team. If anything seems to be getting stale, reach out directly to the ticket owner and make a plan for getting that issue updated.
Keeping tickets updated regularly is a critical part of an excellent support experience, and it’s a lot easier keeping up with a well-managed ticket backlog than it is to dig out of a mess of old and abandoned tickets. The sooner you set these standards across your team, and enforce them, the more effective your team will be—and the happier your customers will be, too!
Thanks for reading Andy's Support Notes 💻💥📝!