Support plans are usually packaged as subscriptions–but they don’t need to be “all-you-can-eat”. Here are 10 ways you can place limits on what you deliver, each with recommendations and caveats.
This one is pretty much universal: support plans are for your own products or services only, not for other products that users may routinely use in conjunction with them. You can offer premium plans that include support for a larger set of products.
It is also very common to limit support to certain versions of the products or services, sunsetting older ones after some period of time. Common, but hated by users who find it expensive and disruptive to upgrade to newer releases. We think of this limitation as a the convenience of the engineering team, so it does not have to keep fixing older releases, but it is also helpful to the support team since keeping trained resources for older, rarely serviced products is difficult.
Many vendors charge extra to support older versions, and it’s fairly well accepted by customers.
For products used in complex ecosystems, vendors often certify certain combinations of products and versions that they guarantee to work. Other environments are to be used at users’ risks. This is not a bad idea but it does create issues with customers that operate outside the certified environments, since investigating the cause of problems can be very complex and costly, only to result in a verdict that the environment is to blame. Be sure you can have a strong voice in the selection of the certified environments.
Out-of-the-Box vs. Customizations
Product customizations can be very complex, and, as above, just researching the cause of a problem can take many hours (and a skilled engineer or two). Restricting support to the out-of-box product can be a hard sell if you support products that lend themselves to customizations. As an alternative, you can require some level of certification for the customizations before support can commence.
Restricting the number of cases is common at the low end, but it is also awkward: will you really turn users away? And how will you handle cases when the problem turns out to be caused by a bug? Investigate with great caution and carefully think about how to police the limit.
If you thought limiting the number of cases was challenging, effort time should be even more scary. Customers routinely challenge the hours logged for a particular case, arguing that the support engineer “should have known” to do X or Y. Avoid at all costs.
Number of Technical Contacts
Limiting the number of individuals who can contact support is commonly done, as is requiring a particular level of expertise for the contacts, with the idea that all “easy” issues will be automatically filtered out. Whether your customers will accept the limitations depend on how they are structured internally. If they already channel issues through dedicated specialists, it’s worth looking at.
Hours of Support
A standard limitation, with higher-level plans promising 24×7 support. Usually well-accepted by users, but it all depends on the type of product or service you provide. Many applications simply demand 24×7 support.
Limiting contacts to chat or email/portal is commonly done, and can pay off if issues can actually be resolved without voice or screen sharing. Note that you can place limits to how issues can be reported but still allow multiple modes of communications once the issue is logged.
Location of the Support Engineer
Users may prefer or require for the support engineer to be physically present in country, or be a citizen. This is typically a fee-based option. On the other hand, working with offshored staff can be a limitation placed on lower-cost plans.
Before you make your decisions, carefully consider the consequences for your customers, for your team, and for prospects.
- For prospects: support plans with lots of limitations are less attractive, and indeed may give the impression that you will not be a good partner overall. Strive for simplicity and less small print, and make sure you understand your competition.
- For customers: restrictions mean potentially lower satisfaction so make sure you can demonstrate fairness, and remove restrictions from the higher-level plans.
- For your team: check that any restrictions you are planning are really helping you with lower staffing, higher efficiency, or lower cost. And if you don’t intend to enforce them, remove them entirely.
Do you place limits on your support plans and how? Please share in a comment.