by Tony 

SaaS Customer Support: Best Practices for Support Teams

0 Comments

SaaS Customer Support: Best Practices for Support Teams

When it comes to resolving issues on behalf of a customer, there's no faster way than via chat, where it averages approximately 38 times faster than email. Despite this major difference in speed to resolve a case, most support teams are still staffing their email inboxes in a way reminiscent of 2015.

Success in scaling your software as a service (SaaS) company is nearly impossible if you're still relying on a $15 average cost-per-case for manual resolution (at time of service), while at the same time watching your knowledge base slowly degrade into non-existent content.

Why You Need to Fix Your Customer Support Margins

In order to prevent churn of your customers, and to protect your profit margins, the following technical guide will guide you to defining your service-level-agreement (SLA) targets, your true deflection math, and your automation architecture.

The Cost of SaaS Customer Support

Today's customer support leaders are now operating in an environment where the realities are vastly different than what they were when companies used to use marketing packages for selling software. Marketing claims typically provide an AI-induced containment or "resolution rate" of 50% or greater; however, the actual average median across all independent studies comes in at 22%.

Whereas, the year one median containment rates of B2B SaaS deployments are usually less than 15%. The large discrepancy between marketing hype and reality creates massive budget issues.

Customer support has to be analyzed from a unit-economic standpoint. The unit cost of a self-serve interaction can range anywhere from $0.10 to $0.25. The cost of a live agent interaction can range anywhere from $8 to $15. In a SaaS company's case when having to process an average of 10,000 cases per month (which could easily represent the potential of $100,000 in revenue), if just 15% or more of the cases were able to be shifted from manual email to self-serve AI, it would create a savings of over $15,000 every single month, based on the 15% increase in volume being processed via AI instead of live agents.

The Cost of SaaS Customer Support

It is not enough to assume that your customers will automatically choose to use self-serve options for SaaS customer support. This shift doesn't occur by accident; it requires the right amount of supporting evidence to show your customers how easy it is and what is in it for them. You need to do the math with respect to how many cases can be shifted from assisted service to self-serve via AI and continually update your self-service content, including developing a channel strategy that forces your users toward the quickest resolution possible.

The True Scope of Technical Operations

Pre-Sale and Post-Sale Continuity

SaaS customer support should not be viewed as simply "a department that resets passwords and addresses billing issues." It is considered a constant, ongoing revenue protection for the entire business.

Support Teams Own the User Experience

Throughout the duration of the trial, until the customer's contract has been either renewed or cancelled, support teams own the overall customer experience.

Subsequently, when a user submits a support ticket during their free trial, this is essentially a sales lead under the guise of being purely technical in nature. How quickly (First Response Time, or FRT) the support team responds to that ticket will set the conversion rate. After the sale, the support team will handle issues including bug reports, new feature requests, and down system/outage reports for the company.

All of which requires great depths of knowledge regarding the product itself and great communication skills to translate complex technical issues to easy-to-understand customer updates. Thus, until the point the user becomes a customer, it is impossible to separate sales team activity from support team activity or the results of engineering team activity. Therefore, both teams reside in between the two.

Connecting Resolution with Revenue Retention

Churn is a math problem. The average B2B SaaS monthly churn rate is around 3.5%, whereas the top performers are able to retain their customers under 2% of their total annual revenue. Churn that support has a positive or negative influence upon should not exceed 5% of total lost annual revenue.

Connecting Resolution with Revenue Retention

The longer a customer is forced to wait for an answer, the more likely they are to cancel your product. Proactive SaaS customer support can cut early-stage churn in half. This means contacting a user following a failed integration attempt or a sudden sign infrequency to get them back on track. You shouldn't wait until the customer contacts the support team to resolve an issue. Tracking customer usage patterns to find the issue, and sending proactive notifications of the issue with instructions on how to fix it before the customer submits a support ticket, can significantly reduce early-stage churn.

Core Metrics and Benchmarks

First Response Time Metrics

Simply put, most companies have a completely inaccurate way of measuring First Response Time. Most companies report their average FRTs including automated responses (from auto-responders), which creates false success metrics for the company. The precise point in time when an autonomous or human person provides a customer a specific, targeted answer to their question is called the "True First Response Time" (True FRT).

  • The median True FRT for emails is approximately one hour. However, the best SaaS based on 12 million tickets process their email support requests within an average of three minutes and ten seconds. Companies with email True FRTs around the two hour range will lose their enterprise customers to competitors with a five-minute response time.

  • For resolution time metrics: Resolution time is the key metric that defines the operational efficiency of a service. The median time to resolve a ticket is six hours and fifteen minutes industry-wide. On the other hand, top 20% of resolution times are 31 minutes and 59 seconds, the lowest 20%, or the bottom tier, is greater than 36 hours, indicating a breakdown in the escalation processes. L1 agents do not have the necessary capabilities to escalate to engineering quickly when a ticket requires engineering assistance. The ticket will ultimately end up in what is referred to as a dead queue. As a result, clear paths must be built from front line to engineering.

  • The divergence between email and chat channels: A slow, legacy channel with all the inefficiencies of email. Gorgias data indicates Live Chat is 38 times faster than email for True FRT and 8 times faster overall resolution. Product led growth (PLG) companies are growing past 50,000 monthly active users and must force ticket volume into either in-app or live chat messaging. Email creates a context switch. When a user exits your application and sends an email, by the time you respond, they’re gone. Having in-app chat allows the user to remain within your application while also recording their browser information, current URL, and session history without any additional effort.

Customer Satisfaction and First Contact Resolution

The average customer satisfaction score for the SaaS industry is 78% to 85%. If your score is lower than 75%, your product may be defective or your support team is unprepared to assist you. Companies that achieve a customer satisfaction score above 85% are considered the best.

Customer Satisfaction and First Contact Resolution

First contact resolution rates (FCR) drive customer satisfaction. The goal for top-performing companies is to have their team resolve their users’ issues on the first response approximately 70% to 75% of the time. To accomplish this, first-line support agents must be permitted to access billing platforms, customer relationship management (CRM) data, and administrative tools. If a first-line agent must obtain an approval from another department for a refund, the FCR for that transaction will be counted as zero.

Deflection Math and Automation

You should not use generic deflection percentages to estimate how many tickets you are deflecting. You must calculate your "true deflection" by measuring the total number of tickets you’re receiving using strict denominators. You cannot measure the number of tickets deflected by measuring total knowledge base page views divided by total tickets. This will give you a false result.

True deflection is measured based on "eligible attempts." An eligible attempt occurs when someone begins to write a support question into a support widget, observes a suggested article, clicks on it, and then closes the article without opening a ticket for support.

A company with a mature SaaS customer support program typically deflects around 25% to 40% of all incoming inquiries. That said, strict protocols will need to be enforced on both sides in order to achieve this level of success. A billing complaint is not something that can be redirected via email; however, it is possible to redirect a request for a new password.

Ticket types need to be broken down prior to computing the associated success ratios.

Effects of Knowledge Base Decay

A knowledge base cannot just be created and then left to rot on a shelf. It is an ongoing, continuously updated tech guide. There is definitive evidence linking the number of tickets to how fresh your knowledge base content is.

When support teams refresh their articles in their knowledge base, within a 30-day period around 45% of the tickets will deflect. If the same content was not updated within a six-month period or longer the percentage drops dramatically down to 18%. This is because software is always changing. New button layouts, new features added, and the colors of the user interface may change at any time. If your help article contains a screenshot from a previous version of the app, the end-user's interest will probably drop immediately and they will submit a ticket.

Effects of Knowledge Base Decay

Support teams need to review their top 50 viewed articles, at the very least, each month in order to ensure the articles are current.

Containment Policies for AI

AI tools such as the Intercom Fin and Zendesk AI will transform L0 and L1 support in the near future. Containment does not necessarily mean deflection; containment is when an AI completes the entire user process without user interaction. Mature deployments by companies such as Intercom are reporting 35-45% containment rates across 500 million conversations. Heavy guardrails are needed to prevent AI from hallucinating legal compliance answers. An organization must strictly outline which topics an AI can discuss and which it cannot.

Chat Routing to Technical Account Managers

If the AI determines that a chat is initiated by a high-value enterprise customer, the AI should immediately bypass all containment systems and connect the chat to a live Technical Account Manager.

Building a Support Team Structure

Support teams are tiered and provide escalation paths, while flat support structures do not work at scale. It is not possible for a single agent to assist an enterprise customer whose account provides $100,000 in annual recurring revenue and a user who has created a free trial account and is requesting assistance to reset their password. Therefore, a tiered support model is necessary.

L1 agents provide low-level support for large volumes. They handle access issues, provide answers to simple feature questions, and perform billing updates. L2 agents provide technical diagnostics. They create logs to assist in reproducing bugs and determine if data flows work correctly. Technical Account Managers (TAMs) provide dedicated support for high-value customers. They do not wait in a general queue and do not pass through standard channels.

Skills-Based Routing

A unified omnichannel inbox is ineffective if all ticket routing is incorrect. Skills-based routing reads the intent of an incoming message and routes it to the specific person who has the necessary qualifications to respond.

For example, if a ticket contains the word "API" or "webhook," the routing engine should assign it to a developer support engineer (bypassing L1) immediately. Similarly, if the ticket is submitted by a customer based in Germany, the routing engine should assign it to a German-speaking agent who is working on European time. Every time a ticket changes hands from one agent to another, the amount of time it takes to resolve the ticket doubles, which is called "bouncing." By implementing routing rules, a ticket that is being transferred from one agent to another can be resolved in the shortest time possible.

Service Level Agreements (SLAs)

Enterprise clients purchase software with Service Level Agreements (SLAs) regarding uptime and support. Therefore, it is crucial to establish strict SLAs. Critical outages must have a response time of 15 minutes or less, 24 hours a day, 7 days a week.

A typical mid-market customer’s bug report would be given an SLA of 4 hours to resolve, during business hours. Automated alerts must be created in the help desk application. If an enterprise ticket doesn't get a response after 10 minutes, the help desk application must send an alert to the support manager via Slack and the ticket will turn red in color.

How to Build a Scalable Support System

Phase One: Audits and Infrastructure

You can't improve what you can't track. For the first 30 days after you start scaling your support team, your entire focus should be on doing audits and creating the structural routing.

Start with doing a complete Knowledge-Centered Service (KCS) audit; from that audit, identify the top 20 reasons users contact you. If your documentation does not have perfect, up-to-date instructions for all 20 of those top reasons, write the documentation now. After completing the documentation, you can now move to step two: consolidate your channels.

This step involves connecting all your email channels, chat channels, and social media channels into a single platform, using something like Zendesk, Freshdesk, or Front. No support agent should ever have to log into a platform like Twitter to respond to customer complaints.

Phase Two: Guardrails and Deflection Tactics

Phase Two: Guardrails and Deflection Tactics

Days 31-60, now that you've got your documentation and your routing established, it's time to start turning on the automated defenses that you put in place. This is where you will create your automated chatbots and define your AI containment targets.

You need to establish escalation thresholds. Escalation rules:

  • Rule 1: If an AI chatbot cannot answer a question after 2 prompts, it must pass that question to a human immediately.

  • Rule 2: Any logged-in user should never need to repeat their email address or account ID.

Phase Three: Optimization and Proactive Support

The final 61-90 days is the phase where, instead of being reactive to customer service needs, the support team is working proactively. The team is able now to do more than just send a response to emails.

For example, you could implement systems that will monitor for failure before a user contacts customer service about a problem with the software. If your software relies upon a third-party integration and the integration has failed, create an alert that will tell users when they lose the connection to the integration. Then create an automated email to send to users when they lose the integration connection to inform them of the disconnection and provide a link for them to reconnect the integration. When you do this, it drives your churn due to customer service support to zero, because you have proven to your customers that you are there for them.

Tool Selection and Total Cost of Ownership

Seat Pricing Versus Ticket Volume Models

Most software vendors use very complicated pricing structures to hide the real costs of their platforms. You need to do your own calculations so that you can be sure of your total cost of ownership based on your operational model.

Tool Selection and Total Cost of Ownership

Traditionally, software platforms charge a licence fee for each agent seat. This means that if you have 50 agents, you will pay for 50 licences irrespective of the number of tickets that are resolved. Newer software solutions, especially those that use a lot of AI, are typically based on the number of tickets resolved or the number of automated interactions completed. If you expect a spike in your ticket volume during Q4, a ticket-based pricing structure can ruin your annual budget. Always calculate the worst-case scenario for your volume of tickets before you sign an annual contract.

Unseen Expenses Associated with AI Enhancements

Many people believe that the normal price of a help desk program includes AI capabilities, but that is not the case with vendors such as Zendesk Advanced AI, Freshworks Freddy AI, and Intercom Fin. They all require substantial add-ons.

Consider only the return on investment for the AI add-on you are considering. For example, if an AI add-on is $2,000 a month but only deflects 300 tickets that would need $3,000 in human labor to process, you would have a narrow margin between your expenses and your actual benefit. You are basically paying for a piece of software that will not provide you with any competitive advantage over your competitors. Therefore, you should always request a trial period during which the vendor must demonstrate the percentage of deflected tickets based on your actual historical data.

Integrations and Data Silos

The most effective help desk software will not be beneficial to you if it can’t communicate with your CRM and payment processor. Integration debt is one of the biggest obstacles to First Contact Resolution.

It is important for an agent working with a customer to view a Stripe transaction in the ticket timeline so that they can determine if the customer is eligible for a refund.

When working on an issue with a customer, it is helpful for the agent to see the customer’s Salesforce contract value so that they can determine how quickly to respond to the customer’s issue. Systems like HubSpot Service Hub and Salesforce Service Cloud benefit from their native, integrated data. When businesses utilize multiple systems that do not integrate naturally with one another, they may have to invest hundreds of thousands of dollars to develop custom APIs to link their systems so that they can work together.

Proof of Concept and Real-World Success

Protecting Margins with Self-Service

Examining the data from Reverb's online marketplace built on Zendesk, the path they took toward this level of success was built around self-service multipliers instead of the additional head count they would have had to hire as they scaled.

Reverb re-engineered its knowledge base and subsequently implemented an aggressive routing system that automatically routed low-tier inquiries to a self-service flow. The results were astounding in that self-service usage increased ten-fold. While removing agents from thousands of interactions, customer satisfaction remained steady at 97.6%. It showed that customers would prefer machines servicing their needs more so than a human being servicing their needs if the technology could deliver faster solutions.

Scaling with First Reply Time Guarantees

CARET, another major player in the SaaS industry, experienced an extreme influx of technical inquiries that put its SaaS customer support SLA guarantees at risk. During that time period, they completely re-engineered their routing system.

By leading with technical complexity as the main criterion for ticket segmentation and using a heavy L1 deflection strategy, CARET was able to keep their First Reply Time at a median of 1.54 hours on all global inquiries.

While scaling, they were able to maintain a 91% customer satisfaction rate. CARET achieved those outstanding results not by hiring faster typers, but by keeping as many tickets out of the queue as possible and routing the few that did end up in the queue immediately to the correct engineer.

Risks When Scaling Your Support Team

AI Hallucinations and Incorrect Logic

Never trust a Large Language Model to converse with your customers! Generative AI models will assume functionality that isn't in your product, and they will promise refunds that you cannot afford to issue.

AI Hallucinations and Incorrect Logic

Always use a strict Retrieval-Augmented Generation (RAG) method with only the verified help center content. Turn off any ability for the models to scrape from outside the help center. The answers the models provide must come directly from the knowledge base.

If there is no answer, the model must state that it does not have an answer and immediately send the ticket to a human agent to handle the inquiry. The cost of one hallucinated promise to a disgruntled enterprise customer can far exceed the savings of using an AI model in the same year.

The Destruction of Outdated Documentation

A support centre's ability to use self-service documentation to deflect inquiries to the service desk is based strictly on the accuracy of that documentation. When a product team launches a new version of their product and fails to update the support team, the self-service documentation may as well be a liability for the customer and for the support team.

A customer searching the self-service documentation for an answer and finding the old FAQ page will not see the updated UI and will consequently have questions. They will flood your live chat with questions about where to find the buttons mentioned in the FAQ. The AI will send customers to the outdated FAQ and provide the incorrect steps to resolve the issue. The support representative must now take the time to review and correct all of the problems the AI has caused.

The absolute requirement is that product managers will be held accountable for the accuracy of self-service documentation. As a rule, any new functionality must not go live until the self-service documentation has been updated and verified by the support team before going live.

Calculating the Final Margin

You should not consider your support centre as a place to dispose of bad product development; rather, treat your support centre as a facility to generate revenue.

If your team cannot accurately calculate their true 30-day deflection rate by the end of this week and you do not have procedures in place to capture any drop-offs before they hit your revenue, you are losing enterprise accounts!

About the author 

Tony

Tony is a systems architect and cloud infrastructure specialist with a deep focus on product-led growth dynamics. Through his work at SSC, he dissects complex enterprise software integrations, multi-tenant database scaling, and API automation frameworks. His technical guides serve as a benchmark for CTOs and VPs of Engineering aiming to streamline their software product lifecycle.

Ready to Deploy Our Architecture?