Introducing paid support: designing support tiers
Some tiers are tastier than others
Last week we started talking about introducing paid support, starting with the actual logistical requirements: support worth paying for, appropriate staffing levels for full support coverage, and comprehensive policies and procedures around handling support issues to minimize customer dissatisfaction. This week we’re going to continue that discussion as we come ever closer to starting to charge for enterprise-level technical support.
Getting your team on board
You’ve prepared your team on a technical level to start taking on paid support contracts, but it’s just as important to discuss these upcoming changes with your support engineers and ensure they have a chance to ask questions. Change is always difficult and usually unpopular, but you can smooth the transition by helping everyone understand what’s happening, the reasons for it, and what will be required of them going forward.
One thing to be clear on before we look at the specific topics you’ll need to discuss with your team: this may not be an easy transition. People tend to get into technical support, and stay there, because they are really invested in solving customer problems. They love resolving complex issues and they love doing it well. Moving to a stratified model where some customer problems are considered ‘more important’ or ‘higher priority’ than others may feel like a betrayal of those principles. That’s a valid perspective, and one you shouldn’t ignore or try to paper over. For engineers specifically concerned about this, take special pains to convey the last two points below: they’ll still be able to help customers and will never be asked to ignore customer issues or tell them to come back later. This will hopefully help alleviate their concerns, but pay attention to people’s reactions and take as much time as is needed to talk things through, alone or in a group.
These are the important points to cover, and to make sure everyone both understands them and is bought in:
Moving to paid support is a business decision and it’s our job to implement it. It doesn’t do any good to imply it’s up for discussion, or that there’s anything the Support organization can do to prevent it. At the same time…
Support leadership was involved in planning this transition. This decision, though ultimately the responsibility of company leadership, did rely heavily on input from you and other support leaders. The Support organization won’t be called upon to do the impossible or go against your mission of helping customers.
This will help the support team in the longer run by showing its monetary value. This is an important one: in leaner times where every dollar is scrutinized, the Support team can show that it’s a revenue-positive function and is not (seemingly) a drain on company finances with no revenue to show for it.
Contractual obligations must take priority. The most immediate consequence for the support team is that we must always ensure we’re meeting our contractual commitments to customers. If a new issue comes in from a customer with a 2-hour response SLA, we must ensure that that issue receives an initial response within two hours. If that means pausing troubleshooting another issue, or setting aside a bug reproduction process, then so be it. But at the same time…
Existing triage processes are still valid. Once we have met our contractual commitments, we should continue to prioritize our work based on our existing processes. If a super-extreme-Platinum-executive-tier customer wrote in with a low-severity problem, all we owe them is a fast initial response. After that we’re free to return to the urgent issue we were already working on that was submitted earlier in the day by a free-tier customer. Moreover…
We will never refuse to help a customer. Even if our published business hours state ‘M-F 9-5 ET’ for free customers, if they write in with an urgent issue overnight, we’re not going to tell them to come back in the morning. If we’re working, we’re going to be responsive to customer issues. A lack of guaranteed support is not the same thing as a guaranteed lack of support, to torture a phrase.
Designing support tiers
When thinking about how many support tiers to have, and how to justify the price difference from tier to tier, it’s important to coordinate with Sales, Customer Success (CS), and ensure you have buy-in from the C-suite as well. In most cases, a higher support tier will also be packaged in with other non-Support features such as regular CSM (customer success manager) check-ins, complimentary or customized training, quarterly business reviews (QBRs) or other incentives. These tend to be grouped under the CS banner, so having CS input into the features of each tier is critical. And while we won’t be discussing this until next week, it’s going to be the CSM who has to explain to their customers the new support tiering model, so it’s critical they understand the distinctions and value propositions of each tier. Similarly, Sales is going to have to be selling these packages, so their input is also valuable in determining what should be at each tier based on their own understanding of the market.
Every company is going to set up their support tiers differently, but here are some specifically Support-relevant considerations. Depending on how your Support organization is set up, you may be able to offer more features than this to higher-paying customers, but these are the basics:
Support hours: This is one of the two main levers your team has in differentiating different support tiers. Some customers (or products) may only need support during business hours, some customers may require extended hours if your product is critical to operations or they are running a global business. Not coincidentally, expanding support hours is also one of the biggest budget-busters for your team, so it makes sense that offering broader support hours is gated behind a more expensive support tier.
Response SLA (service level agreement): Second only to support hours is the speed of your team in responding to inbound issues. There’s a lot of room to differentiate here—you can define separate response SLAs for different issue severities, different times of day, or even how the issue was submitted to the support team. Response SLA is also one of the most important aspects of an enterprise support agreement for larger organizations. When they need help, they need to know they’re going to get it immediately. Like support hours, this is also one of the most expensive features for a support team to build, due to the increased team size required to guarantee specific response times.
Support modalities: Most SaaS technical support is email-first, but there are many other options: chat, phone, and shared private Slack/Teams channels, to name some of the most prominent. Gating access to some of these support modalities can be a nice bonus for higher support tiers, but it is typically less important to customers than support hours/SLA.
Ticket reviews: The larger the customer, the more ongoing support issues they are likely to have. While you probably have a support portal or other way for customers to have an overview of all of their in-flight issues, a periodic check-in with the customer to go over these issues and highlight any roadblocks can be valuable to busy customers. These periodic ticket reviews are generally tied to QBRs with a CSM and a support leader both in attendance, but some higher-end enterprise support agreements include the option for a customer to call for a supplemental ticket review as needed.
Example support tiers
Keeping all of the above in mind, here’s an example 3-tier support program. The most dramatic differences from tier to tier are in support hours and response SLA, but there are also other benefits available at higher tiers to make the support experience smoother for enterprise customers. I’ve also added a number of CS-specific features to illustrate how Support and CS can work together to build a consistent offering for each tier.
Basic tier
Support hours: 8-5 EST M-F (business hours only)
Response SLA: best-effort only
Support modalities: email only
Ticket reviews: none provided
CSM: none assigned
Training: none included
Onboarding: self-guided onboarding; documentation provided
QBR: none
Intermediate tier
Support hours: 24/5 (M-F)
Response SLA: 2-hour initial response for Urgent, 24-hour for other issues. Best-effort outside stated support hours.
Support modalities: email and shared private Slack channel
Ticket reviews: quarterly, as part of QBR
CSM: dedicated CSM assigned
Training: free customer training session during onboarding
Onboarding: dedicated TAM (technical account manager) and active onboarding
QBR: yes
Enterprise tier
Support hours: 24/7
Response SLA: 2-hour initial response for Urgent, 6-hour for other issues
Support modalities: email and shared private Slack channel
Ticket reviews: as part of QBR and as requested by customer
CSM: dedicated CSM assigned
Training: free training session during onboarding and annually thereafter
Onboarding: dedicated TAM and active onboarding
QBR: yes
Sidebar: pricing
You probably noticed that I avoided talking about one of the very important components of support tiering: how much do we charge for each level? The reason I’m not really getting into it is because it’s not up to you. This is a business decision that will be driven by the executive team, and while you may be involved in those discussions, the final pricing model will be up to someone with a C in their title. That said, I’ve typically seen enterprise support contracts to be set at anywhere between 5% and 20% of TCV (total contract value) for larger customers, with a floor of maybe $5000-$10000 per month.
You now have defined support tiers and your team is prepared for taking on the new, stratified support regime. There’s just one hurdle left: notifying your customers about the upcoming change. It’s a complex enough process that we’ll save it for next time—see you then!
Thanks for reading Andy's Support Notes 💻💥📝!