Streamlining ticket handling part 2: screensharing
F it, we'll do it live
Last week I mentioned three things you can think about while putting together a plan of attack for addressing your most common support issues:
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?
This week we’re talking about the second bullet point: live troubleshooting and screenshares.
In many cases, the fastest way to get to a resolution to a support issue is to speak directly to the customer. In organizations that provide phone-based support, direct communication is the default: a customer calls in, discusses their issues live with a support engineer, and with a little bit of luck ends the call satisfied. However, phone support is less common in a startup environment, and chat-based or email-based support is becoming the norm.
Even where phone support is still in use, it can be difficult to walk a customer through a complicated troubleshooting or information-gathering procedure without having a shared view of the system in question. Fortunately, though phone support has become less prevalent, almost every one of your customers is now equipped to join web conferences, with or without video, and provide direct access to their system via a screenshare. Five minutes in live conversation—and seeing a problem firsthand—can often forestall a dozen back-and-forth emails.
Today we’ll talk about some of the ways you can best leverage web conferencing and screenshares on your team, but we’ll start with a few examples of where screen sharing won’t work.
When screensharing won’t work
Sometimes screensharing simply isn’t an option. A few reasons why this might be:
Bandwidth and connectivity: While this has become less of a concern with ubiquitous broadband availability, the fact remains that web conferencing in general, and video chat and screen sharing in particular, are fairly bandwidth-intensive. If your customer is in an area where a fast connection is unavailable, or if they’re far enough away from you physically that there is a lot of latency (i.e. long waits between your saying something and their hearing it), or if their environment doesn’t permit connection to web conferencing services, then you may be out of luck. Still, voice-only connections may be an option.
Customer availability: Even if your customer’s internet connection can handle a screenshare, they may not have the time to join one. If your customer is particularly busy, it may be difficult to find a time for them to dedicate to a live conversation. In those situations, you may have to do your best with asynchronous communications, or wait until your customer has time to speak with you live. Flexibility with your own schedule may be important here, as you may only get an opportunity to talk to them outside your normal working hours.
Support engineer availability: if your engineers are already working on other issues, they may not be able to set aside half an hour or more to do a live screenshare with the customer. In that case they may have to lean on email communications until they have some availability, or suggest a time later in the day or week to meet live.
Privacy or confidentiality concerns: Depending on the nature of the product you’re supporting, you may have customers who have concerns about sharing their specific system configurations with you. Maybe they’re working with a three-letter agency, maybe they’re a financial institution with strict data privacy requirements, or maybe the data processing issue you need to help them investigate contains protected health data. Whatever the reason, screensharing may simply not be possible due to legal requirements. In this situation, it’s often still worth requesting a live conversation. Even without a direct view of the problem at hand you can troubleshoot a lot faster without waiting for the back-and-forth of email conversation.
Business policy: Maybe the specific system or data you need to investigate with your customer isn’t sensitive, but they still can’t join your screenshare due to internal business policies. At this point it’s no longer a question of technical concerns, but of business concerns, and those words should make you think of Customer Success (CS). If, in your estimation, there is no way to proceed with your current troubleshooting process without working live with the customer, loop in CS. They can help make the case to the customer that live troubleshooting is required, and perhaps an exception can be granted.
The common thread among all of these situations: even if the customer isn’t able to share their screen, sometimes just getting them on a live conversation can be a great benefit.
Benefits for different ticket types
Not every inbound customer issue is a great fit for a live conversation. If a customer has reported a bug and provided all the information you need to reproduce it, there’s no point in hopping on a call just to tell them ‘great job, we’re working on it’. But if your next step in addressing a given issue is to ask for more information, stop and think for a moment whether it would be more efficient to have a live conversation with the customer instead of writing a detailed email.
Troubleshooting: The most obvious fit for a live screenshare session is when the customer is having trouble, but hasn’t (or can’t) provided enough information for you to diagnose it in their initial message. Rather than going back and forth with a sequence of ‘collect this… now collect this … now send me this additional information too’ messages, it’s often much more efficient to set up a live troubleshooting session where you and the customer can investigate together. You get the information you need faster, and the customer is able to learn something in the process.
Bug reporting: Being able to see a bug or unexpected behavior live, rather than relying on the customer to describe it completely and accurately via text, is often the most efficient way to gather all of the information you need to submit an internal bug report. As an added bonus, the screenshare will let you take your own screenshots or even videos to append to the ticket.
Feature requests: There may seem to be no obvious benefit to seeing the customer’s screen while they’re describing a feature request. But even if a visual isn’t necessary, the ability to have a live conversation and clarify exactly what they’re looking for can save a lot of time when conveying their request to your Product team.
Screensharing policy in practice
In a previous role, the support team I led had a simple rule for proposing a live troubleshooting session: always offer a screenshare unless you can address the question in one email. In practice, this meant that as long as the engineer handling a support issue had the capacity to speak to a customer, they would offer screenshares for all but the simplest questions. After a few months of this, several members of the team took it even further: instead of suggesting a share, they would preemptively open a Zoom meeting and share the link with their initial ticket response. More often than not, the customer would join that session immediately.
After we instituted the screenshare-first policy, the improvements were clear and immediate. Most customers were happy to address their issues through a quick conversation rather than prolonged email conversations. They’d get answers to their questions in minutes rather than hours, and bug reports could go from ‘I’m having a problem’ to ‘We’ve reproduced it and a fix is on the way’ much faster. On the support side, doing more customer interaction live cut down on the time to address each ticket and the mental load of holding dozens of tickets open and waiting for customer responses. Finally, recording these interactions (with customer permission) gave us a rich library of training material for the rest of the team and onboarding new engineers.
While it can be an adjustment to team processes to foreground live troubleshooting to this extent, the benefits to many support organizations is significant. If your team has the capacity to make live troubleshooting a standard part of your process, it can be a compelling enhancement to your support offering.
Thanks for reading Andy's Support Notes 💻💥📝!