One of the most common complaints from SaaS customers is that support teams are not as responsive as they’d like. These customers say that they have to wait too long for support teams to reply to their requests and that they’re too often left in the dark when problems arise. In some cases, support teams have so severely damaged their reputations among their customers that the customers simply bypass the teams entirely when they need to reach out, instead relying upon their account managers or even their sales reps to kick-start a solution.

Needless to say, these situations are simply not sustainable. A support team’s primary job is to communicate with customers about their requests, and it’s therefore up to those teams to maintain customer trust whenever they receive calls, emails or tickets. Support teams cannot always control when their company’s products cause problems, but they can control the quality of their interactions with customers during these challenging times.

Fortunately, it’s not actually all that hard to keep customers happy, even in the most stressful of circumstances. All support teams need to do is remember two simple concepts: Effort & Details.

Effort – Showing (not just telling) customers that your team is working on their requests.

Even when customers have the most benign, easy-to-accomplish requests, they still expect support teams to a.) respond quickly and b.) provide timely updates until the request is complete. The more serious the issue, the more important these two responsibilities become for support teams.

Support teams should provide an initial reply to customer tickets or emails as soon as possible, and at no time should a customer be made to wait more than one business day to hear back. In those notes, support agents should let the customer know that they’ve received the request and (if they do not have an answer or solution at that time) that they’re looking into it further. The key with these and all other responses to customers is that support teams include specific update ETAs, meaning that agents will tell customers that they’ll reach out again at or before a particular time. An update ETA of “later today” or “by the end of the week” is much more helpful to customers than telling them they’ll hear back “shortly,” “as soon as possible” or “when we have more information.”

These update ETAs let customers know that their requests have not disappeared into the support team’s queue, and that even if they need to wait a few days for more information, the support team has committed to providing it before a specific time. Of course, support teams need to actually meet those update ETAs in order for them to have any value, but setting discrete deadlines will help support teams hold themselves responsible for keeping customers informed.

An example outside of SaaS: When the power in my house goes out, it’s a pretty big inconvenience. This is particularly true when the temperature is hot or cold enough that things might start getting uncomfortable without a functioning HVAC system. Luckily for me, the local power utility has a helpful app that keeps me informed when things do go wrong.

First, I’ll get a text message from the power company letting me know that my power is out. While I’m almost always aware of this when it happens since all my lights are off, it still reassures me that at least the power company knows what’s going on. From there, I can log into the app to see the power company’s progress on a fix. The app will show me how many nearby customers’ power is also out, and will share information like when the power company has assigned a crew to fix it and what the cause of the outage is. Perhaps most helpfully, the app will always have an ETA on when the power company thinks things will be restored, which the company also shares via text message and keeps updated as the situation evolves.

As a customer, this helpful information reassures me that I won’t literally be left in the dark indefinitely, and that the company that I pay to keep my power on is actually working to fix problems when they happen. For most SaaS companies, their products are certainly a key component to their customers’ business success, and while issues with those products might not rise to the level of a power outage, support teams must still show customers that their requests are not being ignored.

There are plenty of other ways for support teams to demonstrate their collective effort to customers. They can arrange phone calls or screen-sharing sessions when a customer requires a little extra help. They can create customer-specific training material for requests that come through more often than others. They can check in with customers after a particular request has been resolved to ensure everything is to the customers’ satisfaction.

The most important things that support teams can do to build customer trust, though, are to respond quickly to their requests, be specific when providing update timelines and, crucially, making sure those timelines are met. If support teams do those things, their relationships with customers will remain solid, even in the face of product problems.

Details – Sharing the right information with customers, as soon as your team receives it.

A frequent debate that I’ve heard in my career concerns the amount of information to provide to a customer when they have a request. Some support teams always revise more technical feedback to allow for easier understanding by less technical customers. Others err on the side of providing all of the available information, even if a lot of it goes above their customers’ heads. In my experience, the way that support teams have the most success explaining a solution to customers is to do both.

Support teams must always understand the level of technical knowledge that each of their customers possesses. In some cases, a support team’s primary customer contact might be an engineer and is therefore receptive to more complex concepts related to the products they use. In other cases, that contact might be someone with a very limited background working such products, and just wants their requests completed as soon as possible. In either case, support teams must remember that their main contacts are not the only customer stakeholders paying attention to product performance, and should craft responses accordingly.

Support teams can begin explanations with a summary of the problem and the steps they’ve taken to investigate or resolve it, written in plain language. Doing so will not only make it easier for less technical customer contacts to understand what the support team is doing, but will also provide a brief encapsulation of the complete “request journey” for more technical customer contacts to provide their own team-members and executives.

Support teams can then expand upon that summary by adding more detailed information concerning the steps they have taken. While it’s true that some of this detail might not mean much to less technical customer contacts, those contacts will frequently have more technical co-workers who will want to know the cause of any problems and the things the support team has done to prevent their recurrence. In some cases, those more technical co-workers can then make their own changes to their product configurations, based on recommendations from the support team.

Another example outside of SaaS: When I take my car to the mechanic, I want to know what’s broken and what they did to fix it, even though I know almost nothing about auto repair.

When I arrive, I’ll drop my keys at the service desk and explain to the service rep what I think might be happening before taking my place in the waiting area with a book or my laptop. If I’m just in for an oil change or something that doesn’t require any diagnostic work, the service rep will find me after an hour or so and let me know that everything is ready, providing a detailed list of the work completed in the garage before walking me to the billing area. If it’s something more significant, the service rep will send me a video showing the mechanic explaining what’s wrong and what likely needs to be done to fix it. In addition, the service rep will bring over a printout explaining the specific parts and labor that will be required and the accompanying cost.

In both situations, the service rep has provided me with information that I can understand and a more detailed explanation that I might be able to share with someone who knows the difference between a spark plug and a camshaft if I wanted to second opinion. The company knows that the majority of their service customers probably know as much about cars as I do, which is why they employ service reps rather than just letting the mechanics explain everything. Still, those service reps share as much information as they can gather, even knowing the lack of automotive acumen in their average service customer, because it’s important to bolster their recommendations with specific data.

Once again, there are plenty of other ways that support teams can provide even more detailed communication to their customers. In addition to the less-technical summary/more-technical explanation feedback model, support teams should always make sure to document any interactions that take place outside of the support ticket. If the support team arranges a phone call or a web session with the customer, they should summarize those conversations and any next steps/deadlines in a comment that the customer team can see. This way, the customer team and support team will be operating with the same information, and there won’t be confusion about which team was responsible for which tasks.

If a support team is working with a customer-facing knowledge base (and they should be), they can share articles with customers as a quick first step toward a solution, following up soon thereafter to ensure the information makes sense. A robust knowledge base goes a long way to decreasing the time to resolve a request by enabling support teams to quickly locate the precise information a customer is seeking, rather than having to manually write it out each time. The hope, of course, is that customers themselves will also begin to look for answers in the knowledge base, which is why maintaining the appropriate level of detail and care in the articles within is also necessary.

The primary principle to remember is this: Customer contacts are not the only members of their teams who are invested in their ticket requests, so support teams must make sure to cater their communication for that wider audience. By beginning any feedback with an accessible summary, support teams will ensure that less technical customers have enough information to be satisfied that progress is being made on their requests. By supplementing those summaries with a more thorough explanation, support teams allow their customers to share those details with their own more technical team-members, while also strengthening the rationale for the support team’s solutions.

---

Too much blah blah blah? Fine, I’ll make it simple:

Support teams should never just say “we’ll get back to you” or “we’re working on it” in response to customer requests. Those two phrases will supercharge a relationship straight to Trouble City, especially if the support team is also negligent in actually making any meaningful progress.

Instead, support teams should make sure customers know their requests are being taken seriously through the use of specific update ETAs and carefully crafted feedback. No new progress to share? That’s OK – support teams can let customers know what’s already been done and then provide (you guessed it) another specific update ETA.

At the end of the day, customers just want their problems solved. Short of that, though, they want information on what support teams are doing to help and when another update is coming. No matter how simple or complex a customer’s request might be, if support teams remember the philosophy of Effort & Details, they’ll do a lot to build trust with their customers and keep them happy.

Click here for more “insights” into the world of SaaS support.