Introducing paid support: preparing the team
Cash rules everything around me
Providing technical support to customers is not in itself a revenue-positive function in a company. Your team is costing a significant amount of money, and not (on paper) earning anything in exchange. Eventually, someone in a financial role is going to take notice of this, and at that point there are two options: first, the company can recognize that fact and embrace it. Good support is part of the package we’re selling, and should be considered an integral component of the total product our company is known for.
But more often companies will take the second option: take steps to make Support a revenue generating function. Though there are various ways of making this happen, it all comes down to charging the customer for the support your team is providing. Today we’re going to talk about that second option, starting with the fundamentals: once your organization decides to introduce paid support, how can you make sure your team is ready for it?
Making Support pay
From one perspective there’s nothing easier than making Support revenue positive. All you have to do is tell customers that technical support will no longer be free. On their next renewal, there will be a new line item for ‘Enterprise support’, and from then on they will be paying for it and you can start to add numbers to the positive tally for your team. But obviously, most of the time things won’t go so smoothly. Customers are probably already accustomed to receiving very good technical support from your team without paying anything extra. When they’re faced with the prospect of paying more money for getting the same thing, they’re not going to be super happy about it.
There are a couple of different ways that you can address this issue. First, you can simply roll this new charge for technical support into a generic price increase at renewal time. If you don’t specify why they’re paying more money some customers might ask for a justification, while others may be inclined just to let it ride. The other major option is to introduce different tiers of support. For example, there might be free support that is only within certain hours and have a very slow service level agreement (SLA) or none at all. If a customer wants more, then you can offer them a paid tier. If the customer pays some money they’ll get faster response times guaranteed, and other benefits like off-hours support, additional support modalities, and so on. If you really want to be fancy, you can introduce multiple support tiers, with varying SLAs, different hours, et cetera. But exactly how to position these various support levels is a discussion for next week.
Before you start
This may seem like an obvious point, but it’s one that’s missed by many organizations who are looking to introduce paid support: your support has to be worth paying for. More than once I’ve seen firsthand the following reasoning:
Our support is not great, and we’re at risk of losing customers
This is because our support team is under-resourced, but
We don’t have the money to expand the team
We can get money by charging for support
We announce our intention to start charging for support
Because our support is not great, customers push back and do not renew
OH NO
It’s a vicious circle: support isn’t great but it needs money to get great, but the only way the budget can be increased is if it pays its own way, but customers aren’t comfortable paying for mediocre support. I’ll be blunt: if your team is trapped in this cycle, there’s no easy way out of it. The best way to transition to a paid support model is to have support that’s worth paying for. If the budget isn’t there to build that level of quality support, it’s going to be very difficult to bootstrap your way to high-quality support without upsetting a lot of customers on the way. I’ve seen three ways of escaping this trap, with varying levels of effectiveness:
Initial investment to permit future returns: To build a support team worth paying for, it’s going to cost some money upfront. If you can convince company leadership of this, you’ll be in the best possible position to be ready to start charging for support once your team has been brought up to snuff.
Introduce paid support very early: When you only have a small installed customer base, it’s a whole lot easier to provide satisfactory support with a tiny team. If you establish early on that all support for your company’s product is paid support, you’ll be able to build up your team with cash flow from the very beginning. For some companies a model like this can work very well, but when you’re selling a product with a lot of established competition, the additional cost of required paid support can make it harder for your company’s product to be price-competitive with the rest of the field.
White-knuckle it: This isn’t my preferred option, but frankly, it’s the one that most support teams in this situation end up dealing with by default. Your company announces that support is going to start costing money, and some customers grumble about it because they’ve already had some disappointments with your support experience. But most go along with it, money starts coming in, and you’re able to start building your team out some more. New customers are satisfied, and existing customers notice an improvement in the support quality they’re receiving. The hardest part is to make it through the six months or so between when you start charging and when you’re able to hire and onboard new team members with the proceeds—this is where you’ll need to lean on customer goodwill and effective customer management from your Customer Success organization, if any.
I’ll be honest: making the transition to paid support, even for an excellent support team, is not guaranteed. If enough new customers don’t come onboard, or if the revenue brought in from existing customers is not enough to offset the costs of your team, you’re in for some difficult conversations with leadership and may be forced to make some difficult decisions about the future of the support organization. Introducing paid support can be a gamble, even (or especially) when it’s not one you’d have chosen to take yourself.
I don’t want to end this section on a gloomy note, so I’ll add one more observation. If you are able to effectively implement paid support, it is a huge ongoing benefit to your team. By transforming your support function from a cost center to a revenue generator, you’ve cemented the utility of your team to a revenue-oriented leadership team, and the quality support your team is providing will have a bright future. Congratulations!
Critical components of paid support
When planning to introduce paid support, you must ensure that several critical components are already in place in the Support team: comprehensive coverage, an internal SLA, and documented triage policies. Make sure that these are all established and functioning correctly before you start transitioning to a paid support model in order to minimize the chances of customer dissatisfaction.
Comprehensive coverage: By this I mean that your team must be of sufficient size and geographical distribution that you have at least one engineer available for all of the support hours you’re planning to offer. I’ve discussed this extensively before so I won’t belabor the point here except to point out that this is absolutely critical for paid support. If customers aren’t paying, they’re going to be a lot more forgiving of slow responses from time to time due to understaffing. If they’re paying, they’re going to have significantly higher expectations for the speed and quality of issue handling.
Internal SLA: When customers are not paying for support, it makes sense that you’re only promising a best-effort response. But even if you’re not guaranteeing a specific response SLA to customers, you should establish an internal-only SLA and make sure your team is capable of meeting it. For example, one team I led established an internal SLA of 15-minute first response, 24/7. Even though we only promised our customers a best-effort response, we managed to send an initial response, from a human, within 15 minutes over 90% of the time. When the time came for us to start offering enterprise-level support plans, we could easily commit to a 3-hour initial response SLA because our team was already used to 15 minutes. Try to build an internal SLA that is much more aggressive than anything you’ll ever offer to customers.
Triage policies: When a support team needs to start dealing with different classes of customers, paying for different levels of support, there need to be clear written policies regarding how to triage incoming support issues. “If two issues come in, one from a Gold customer and one from a Platinum, but the Gold issue is critical but the Platinum is merely moderate…” The permutations can be quite extensive, and an overloaded support engineer is going to need clear guidelines for which issues take precedence. Draw up these policies and guidelines before you start charging for support, and make sure everyone on your team is clear on how to apply them. Inconsistent issue triage is, again, a significant source of customer dissatisfaction.
Introducing paid support is a huge topic, and a successful implementation depends on more than just your own team. Next week we’ll talk about the necessary planning and coordination with other teams: sales, customer success, and company leadership. See you then!
Thanks for reading Andy's Support Notes 💻💥📝!