Companies measure their support teams’ work in a lot of different ways. Some are almost solely focused on the amount of time their teams take to close customers’ tickets, with the notion that quick resolutions equal high-quality service. Other companies, meanwhile, look for longer-term trends in the number of customer requests that are submitted in the first place, mostly to measure the effectiveness with which their teams are providing feedback – the better the information available for the customers, the fewer repeat questions show up in the support queue down the road.
In one of my roles, the head of the support organization emphasized the importance of the customer satisfaction score (CSAT) above all other metrics. At that company, the CSAT score was calculated by providing customers with brief surveys after their tickets were resolved. The surveys asked the customers to share whether or not they were satisfied with the level of service they received and then to add any comments to include more details about their experience.
While the CSAT score certainly offered a direct line to the customers and painted a clear picture of how the support team was performing relative to their expectations, we still needed to figure out a way to not only emphasize specific support practices to our teams, but to measure how those practices did or did not contribute to the overall CSAT trends. To do this, we first revamped the company’s support communication policy, making sure to provide clear expectations, timelines and other details to serve the support team in their day-to-day interactions with customers. Then, we created a scorecard containing a dozen or so pass/fail questions that would be used to assess the quality of our agents’ work in individual tickets.
During this initiative, it was important for us to break down our organization’s support process into the individual elements that contributed to customer happiness. Here, I’ll discuss each of those elements, and how to measure their adoption among support teams.
Keeping Promises
The best support teams are not necessarily the ones that can instantly resolve all of their customers’ tickets themselves. Instead, those teams build trust by providing world-class communication regardless of the severity of the request. Through consistency and a demonstrated effort to keep their promises, great support teams are able to create an environment where customers know before even submitting a ticket that the request will be handled professionally.
Obviously, the quickest way that a support team can show customers that their requests are important is by responding to their initial ticket-submissions within the required support service-level agreement at an absolute minimum. While it’s great if a support team can either resolve the request or share helpful information right off the bat, customers will appreciate a prompt acknowledgement of their tickets even if the support team only tells them they’re aware of it and will send an update after looking into the request in more detail.
These update commitments cannot, however, be so nebulous that the customer doesn’t actually know when they’ll receive any feedback. When support teams need more time to look into tickets, telling the customer they’ll receive an update “shortly” or “when the team has more information” won’t do and often leads to situations where customers grow frustrated after being left in the dark for several days. Instead, support teams should commit to a specific date and time when they will update tickets. These update ETAs not only keep the tickets moving along, but also assure the customer that they’ll at least see something new in the ticket by a specific time. (You can read more about my philosophy surrounding specific update ETAs here.)
Finally, support teams should make sure to offer as much helpful feedback as possible as they work to resolve customers’ requests. If teams must investigate an issue further, or escalate it to a more technical group within the company, they should let customers know. When teams discover new information about a request, even if it has not yet led to a resolution, they should share that with customers (making sure to paraphrase/translate when needed). If they’ve run into a roadblock in their troubleshooting efforts, support teams should make note of the available details and send them to the customer. The point here is that customers would always rather hear something than nothing, so even if the information support teams send them doesn’t lead to the ticket being completed, it still signals to the customers that their request is still actively in progress.
The last thing any customer wants is to feel like their questions and issues are being ignored. Unfortunately, many teams give their customers this exact headache, not necessarily because the customers’ tickets are not being examined, but because the support teams are not effectively communicating their progress or following up in a timely fashion. By making sure to a.) respond quickly when a new ticket arrives in the queue, b.) provide and honor specific update ETAs and c.) share meaningful feedback with the customer as the request moves toward resolution, support teams will build the sort of trust among their customers that will serve as the foundation for productive working relationships.
Write It All Down
Aside from including prompt, helpful feedback to customers as part of their work to solve tickets, support teams should also diligently document their work for future reference. This documentation can take a few forms, and I’ll go over the ones I’ve used most often during my career.
At the very least, support teams should make sure to summarize, in writing, all interactions with customers that take place outside of the ticket (phone calls, screen-sharing sessions, etc.). Doing so will guard against any misunderstandings regarding responsibility for next steps, update deadlines and other information used to resolve the request. Phone calls and screen-sharing sessions are great ways to discuss tickets with customers who might need a little extra help, but those important notes being omitted from the ticket leaves room for confusion and could lead to frustration moving forward. Better to create a customer-facing note in the ticket to get all of the necessary information in a place everyone can see it.
If a support team uses a knowledge base when interacting with customers, agents should include any relevant links in their feedback, in addition to clear, well organized instructions to help the customers resolve their requests. These links will allow customers to access the relevant information if they need to repeat the same tasks in the future, and will reduce their need to solicit help from the support team in a new ticket. Of course, there will always be some customers who just prefer to have the support team complete each request themselves, and in these situations the links to knowledge articles will likely never be clicked, but for those customers who actually want to improve their own abilities, those articles will be extremely valuable.
Not all ticket documentation needs to be accessible to customers, however. For many support teams, especially those made up of more than a few people and/or which handle a high volume of tickets, periodic internal notes will not only help the team-members working on a particular active ticket, but will serve as reference points for similar requests that appear later. For starters, when support teams track the details of their own work in ticket notes, it becomes easier for other members of the organization to understand what’s already been done, which is especially helpful if a ticket needs to be escalated outside of support. Another benefit of these internal notes is that they turn tickets into training tools for other support co-workers. If a customer opens a ticket that is similar to a previous request, having those extra details in the older tickets will make it easier for all members of a support team to understand what to do.
One more helpful practice when closing tickets, especially for support teams that do not have a well maintained knowledge base, is to create a final internal note that summarizes the customer’s request and the things the team did to resolve it. As with the “notes as you go” above, a final summary can help tremendously when facing the same requests from different customers by offering a quick snapshot of the ticket, which often removes the need to re-read the entire comment thread to understand what took place. In addition, a brief summary can help support leaders or members of other customer-facing departments who might be asked questions about specific tickets by providing the most relevant information all in one place. These summaries do not need to be extremely detailed, but should encapsulate the “story of the ticket” in a few sentences.
TL;DR – If it’s not written down in the ticket, it might as well not have happened. Tickets should not only be the place customers get their questions answered and requests resolved, but also must serve as an information repository that support teams can use for reference points when customers bring similar challenges in the future. This process of documenting interactions with customers and making notes of the troubleshooting steps taken on the way to a solution is important even if a team has a robust knowledge base, but it’s absolutely crucial if they do not.
Do You Understand the Words That Are Coming Out of My Mouth?
Support teams can be made up exclusively of product experts who can quickly troubleshoot and resolve any issue a customer might bring to them. They can possess an encyclopedic knowledge of every aspect of not only the products themselves but the different specific ways their customers use the products. They can be highly trained technical wizards with years of experience working with customers and optimizing their configurations.
None of this means anything if the teams can’t effectively communicate.
One of the most common challenges I encountered when reviewing tickets was that the support agents in my company’s organization clearly did not read over their customer-facing feedback before sending it along. This was not a trend isolated solely among those members of our team for whom English was not their primary language, and instead seemed to emerge from a desire to get the information into the customers’ hands as quickly as possible. Obviously, even the most knowledgeable and well intentioned support agents will be little help to customers if they cannot organize their feedback in a way that’s easy to understand, so it’s very important for them to review all of their notes with this in mind before sharing them with anyone else. Tools like ChatGPT can also be a huge help when it comes to cleaning up this sort of feedback, and should absolutely be in regular use among those members of the team who could use extra help.
There are, however, some ways support teams can make themselves look unprofessional that has nothing to do with the clarity of their feedback. Unfortunately, it was all too common when I was reviewing tickets that support agents would simply ignore the rules of writing many of us were taught in elementary school. I’m talking about the big ones – spelling, capitalization, punctuation and the like. For the last 25 years, there’s been almost no excuse for anyone working on a computer to spell most words incorrectly, and many word-processing tools have evolved even further to identify other obvious errors that should not go overlooked. In any case, most software support organizations are staffed by grown adults who at some point demonstrated that they grasped the basic tenets of written communication, and correct spelling, capitalization and punctuation should be the lower limit of what’s expected of them.
Some customers just don’t learn well by trying to digest written instructions, though. In these situations, support agents must be flexible with how they present important information in order to guide their customers in the right direction. One easy way to do this is to set up screen-sharing sessions with customers who are having trouble understanding the initial round of feedback. These live sessions allow agents and customers to discuss requests in greater detail right away, rather than going back and forth in several ticket comments over a number of days, and often lead to a much quicker resolution time as a result. Connecting in this way also presents an opportunity for support agents to continue to build trust among their customers by showing that they’re willing to go out of their way to answer everyone’s questions. (As mentioned above, though, it’s still important to document the important details from these conversations, just so the customer team and the support team are on the same page.)
Support teams must necessarily know a whole lot about the products they work with, but they must also be able to communicate that knowledge to customers in a way that makes sense. By reviewing feedback for clarity and professionalism, and being open to teaching customers in the ways that best suit each one, they’ll usually get the right feedback to the right people at the right time.
Van Halen Rules
A little history lesson for anyone reading this who was born after the year 2000:
Long ago, there was an incredible rock and roll band from a magical place called Southern California. In its true heyday, this band was made up of two virtuosic brothers who played guitar and drums, respectively, one more-than-capable bassist and a wildman lead-singer who made noises with his mouth that I did not realize were possible by a human man. You’ve probably heard some of their songs if you’ve ever been to a live sporting event or spent any time around construction workers.
I am referring, of course, to Van Halen.
Anyway, like a lot of famous bands, Van Halen presented a document known as a rider to all of the venues where they performed – basically, a list of demands that must be met in order that the show actually goes on. One of the more bizarre items in the rider was that the venue set up a bowl of M&M’s for the band’s dressing room, but that all of the brown M&M’s would first have to be removed.
On its face, this seems like a famous band flexing its proverbial muscle in order to force some production assistant in Omaha to sift through a bowl of M&M’s. Instead, the band explained, there was a great reason this item was included. If a venue could not be trusted to do something as mundane and simple as removing a specific color of candy from a bowl, what guarantee could they offer that the more serious, safety-focused items in Van Halen’s rider would be met?
It is with this in mind that I usually include a few “Van Halen Rules” among those I expect support teams to follow. These are usually things within the tickets that aren’t customer-facing, and probably aren’t crucial to the team’s overall success, but they nevertheless measure the team’s willingness (or lack thereof) to tick all of the necessary boxes as they complete a customer’s request. Making sure to properly categorize a request type, for example, or to quickly review/change a ticket’s subject line so it fits with the actual request are two Van Halen Rules support teams can follow.
Some might argue that these extra requirements are pointless, and that they just pile on more tasks for already-overloaded teams. In my experience, though, adding even one criterion that requires very little effort can provide an easy look into which members of a support organization might need their work examined more closely.
It’s easy for a company to say they care about the quality of their support services. It’s even easy for a company to come up with a handful of general rules for their support team to follow. What’s less easy, but ultimately more useful for building a culture of eager helpfulness among support agents, is to specify which practices are the most important to follow and then have a tool to measure how well the agents are performing.
In general, it should be easy for support leaders to identify whether their teams are responding to customers within the required amount of time and whether they’ve provided the appropriate level of documentation within their customers’ tickets. They should also constantly work with their teams to improve the effectiveness of their communication with customers, where such assistance is needed, and could even throw in a Van Halen Rule or two just to make sure everyone is crossing their Ts.
By taking the time to review enough support tickets to identify any performance trends – both strengths and areas of improvement – those same support leaders can keep the engine of continuous improvement running, and ensure that their teams really are offering valuable help to customers.
Click here for more “insights” into the world of SaaS support.
Eric Reinert 