What do support partners want?

1. A good product (few bugs)

2. An opportunity to make revenue, both for selling and delivering support and for selling additional services

3. Easy process to get started, including a good training program & few bureaucratic hassles

4. Good ongoing support from you, the vendor, for escalations

Come to think of it, they are looking for pretty much the same thing we are!

Incentives for Support Partners

If you are using support partners the standard setup is to split the revenue with them (typical splits range from 25 to 50%) but a better idea would be to build a reward system based on performance. Say the partner usually gets 25% of the support revenue. What you may want to build is a system through which partners that escalate a smaller portion of their cases and/or achieve high levels of customer satisfaction get an extra “bonus” based on performance. The bonus would be a back-end (after the fact) payment, unlike the revenue split.

In most instances the issue will be measurement: how can you capture the escalation percentage, or customer satisfaction accurately? Focus on accurate measurements so that the incentives can work properly.

Local exceptions?

Companies with a worldwide presence and large customers that span regions should have consistent offerings worldwide, as discussed here. However, that does not mean that you cannot maintain local variations in the way you present the offerings or even in the availability of the offerings. Here are a few examples.

Question: Most customers in the Americas are large but there’s a number of established and new clients in Europe that are quite small. [The situation could be reversed!] As a result, the Business Day Support offering is popular in Europe but rarely used in the Americas. Is it OK to drop it from customer presentations entirely?

Answer: Certainly! Why present offerings that don’t match customers’ requirements?

Q: Culturally it works better to present the offerings from small to large to European audiences but from large to small in the US. Can we have different approaches in each region?

A: Absolutely. Your goal is to sell, not to be robotically consistent worldwide, right?

Q: The onsite support offerings are popular and practical in Europe where distances are small but ridiculously expensive to deliver in Asia since we only have one office there. What should we do?

A: You have a number of options. One is to offer onsite support only in geographies where delivery is feasible (i.e. affordable.) Another is to price onsite support differently based on the location to reflect the higher cost of doing business there, or to require a minimum purchase. You can offer the same service at different price points around the world as long as there’s a good justification for it. Use different SKUs so no one gets confused.

Q:The heads of the Sales teams in our three regions (Europe, AsiaPac, and Americas) have very different ideas of what we need for support offerings. Should I give in and create completely different support portfolios, one per region?

A: Assuming that your customers themselves have a global presence, you really need to stick with a worldwide portfolio or else you will confuse the customers — never a good thing. However, you can certainly package different regional presentations for the same portfolio that would nicely mesh with each geography’s concerns and still meet the requirement for a unique, worldwide portfolio.

Engineering Support for Older Releases

One of the perennial causes of customer escalations and general discontent is the level of Engineering support for older releases (well, the level of Engineering support for current releases is also a problem, but that’s another story for another day!) The issue is sometimes a simple lack of awareness of the service-level agreement, Many customers, having installed a version recently, automatically assume that it’s supported since it’s new to them. The other, much more difficult problem is that customers often find the standard rules impractical for the way they run their business.

So what is the standard practice for Engineering support? There are lots of variations but most vendor provide technical support for the latest release and the one immediately preceding it, and Engineering support (that is, bug fixes) only for the current release. So if the latest version is 3.2, technical support would be available for 3.2 and 2.11 (assuming 2.11 is the last version for the 2.x releases) and Engineering support would be available for 3.2 only. If a bug is uncovered in version 2.11, the customer will be encouraged to upgrade to 3.2 where the bug may not exist at all or will be fixed.

In addition, most vendors provide a guaranteed timeframe for support. So if release 3.3 comes around technical support continues to be provided for 3.2 for a year or two. Similarly there should be a grace period for Engineering support on 2.11, say for a year after release 3 becomes available. Typically you can restrict the severity level for fixing bugs on older releases, fixing only the most severe defects.

As you can see, the details can become very convoluted. The wise vendor maintains a support matrix that clearly shows those releases that enjoy full support (technical and Engineering) versus technical support only, versus none at all.

The actual length of the support period should be determined by your customers’ needs. Complex systems, lengthy upgrade processes, regulated industries, and larger customers all suggest a need to lengthen the support period. In some environments you may need to commit to delivering support for 10 years on each version.

Should you offer support beyond the contractual agreement for an additional fee? Perhaps. You can certainly charge more to support older versions but the issue is one of staffing: can you afford to maintain staff that’s knowledgeable about older releases, especially for bug fixes? Often the answer is no and it’s not possible to offer the service at a practical price point.

Besides building the support lifecycle to match customers needs you should also work closely with customers to ensure that they are indeed using supported releases and to encourage them to upgrade if they are not. It’s very difficult to force an upgrade in the middle of a crisis, especially if the customer feels it’s all your fault, and magically creating bug fixes on an older release is very painful.

Making Indirect Support Work

There are many reasons to work with partners to provide support to customers (see here for instance.) Once the decision is made to work with an indirect support model, here are some steps to ensure success.

1. Define mutual responsibilities. Who owns the customer? Who manages the billing cycle? How much troubleshooting should the partner do before escalating to the vendor? Does the end-customer have access to a shared knowledge based maintained by the vendor? How will updates and upgrades be distributed? Will the vendor have any direct contacts with customers or are all communications handled by the partner? Can the vendor offer direct support to the partner’s customers? Typically the partner owns the customers, performs all the troubleshooting on any customized applications, and only escalates those issues that can be reproduced against a vanilla product — but you can craft any agreement that make sense for you and your partners. A clear description of each party’s responsibilities goes a long way towards minimizing future conflicts.

2. Agree to financial terms. The main problem in indirect support is the vendor’s feeling that the partner escalates indiscriminately while contributing little financially. If support is fee-based, you can either ask for a percentage of the support fees or for a fixed fee. The former can grow nicely and automatically over time (but will you be able to audit it properly?) The former can be readjusted as the end-customer base and more importantly the escalation volume grows.  

3. Provide technical training. A common cause of headaches with indirect support is that the partner’s employees are simply not knowledgeable about the product. Provide documentation and training with each new release.

4. Mandate certification. A standard practice is to require a minimum number of certified technicians. If you are a small vendor do not be frightened by the idea of a certification: you can make it a relatively informal program, perhaps by administering a short test at the end of each training session. The goal is to filter all requests for your precious assistance through technically-capable individuals. Certification should also include basic reproduction equipment. You can provide incentives to certification by charging certified partners less and by promoting them more actively to customers.

5. Actively manage the relationships with partners. If a partner is escalating too many unwarranted cases, you must find out why. If the certified technicians have mysteriously disappeared, you must insist they be reassigned (they are probably out on a billable assignment) or others be retrained. This is the most important component for successful indirect support. If you have many partners a good investment is a full-time partner support manager who can reach out to each partner on a regular basis and address any issues.

Maximizing Self-Service Adoption

Is it possible to drive the adoption of self-service? Yes! Here are some best practices courtesy of my customers. The main idea is that if you build it they will come (and you can successfully tell them to come.) The punitive approach (as in: you can never call us on the phone, go to the web site instead) is never as successful, and very difficult to implement successfully in enterprise support environments in any case.

1. Deliver what your customers want. Most customers who come to your web site need answers to technical questions (so want to search the knowledge base) or want to download fixes and updates. Does the site make perfectly clear how to accomplish those goals? Revamping the landing page with a big search box and “obvious” navigation typically yields large and almost immediate increases in site usage.

2. Beef up the knowledge base. The most common difficulty I encounter here is the quest for perfection: “we can’t possibly post articles without copy-editing them,” “we can’t let support engineers post an article that has not been reviewed by someone else.” As a result, perfectly serviceable articles languish in review queues. This is so silly! Make a big push for knowledge publishing, not just knowledge creation.

3. Invest in a good search engine. What’s more frustrating than not being able to find a document you know is there? Invest in a tool that can do a unified search: knowledge base and forums (if you have them) and documentation, and anything else you wish to search.

4. Consider customer forums. They probably won’t work very well if your customer base is small but otherwise they provide a great, low-cost way to deliver support (and create new knowledge at the same time.) Sure, you will need to invest some time and effort in launching and monitoring them, but they are much less costly than 1:1 support.

5. Promote the web site throughout the 1:1 support experience – without being annoying about it. For instance, customers waiting for an engineer should hear a reminder about the web site, but only if they have to wait, not first thing when they called. And support engineers should reinforce self-service, but only after they have helped the customer, as in “I found an answer for you. It’s document 1234. Here’s the link.” or “I am documenting the answer to your issue in a new document.” Note that this will only work if the support engineers believe that the web site is good and don’t feel they will be laid off if too many customers visit it.

6. Put someone in charge of self-service. If all your managers focus on 1:1 support self-service will languish. You may not need an army of self-service staff but you do need an owner.

Supporting sunsetted products

Is it possible to provide support for a product that is no longer supported by Engineering? And is it possible to charge for that support?

Yes and yes — with caveats.

Normally, for an active product, a support contract provides assistance with questions and troubleshooting, fixes for at least major issues, and periodic maintenance releases. The commitment also extends to continuing to support the product for either a set period of time or until a number of new releases become available. Customers are sometimes happy to upgrade to new releases if new releases are consistently more stable than older ones or if they contain interesting new functionality, but for many customers the cost and uncertainty of upgrading makes them wish to remain on older releases. In other cases it’s the vendor that decides to “sunset” a product. In either case, the Support organization has a choice to provide support, or not, for a product that’s no longer active from a development perspective.

1. Plan ahead. The worst circumstances to make a decision on how far to go to help a customer is when the customer is in trouble — and the Engineering team is nowhere to be found. Have a game plan and communicate clearly with customers ahead of emergencies to avoid painful escalations.

2. Explore the limitations of restricted support. It’s true that most customer requests are not associated with bugs, and it’s also true that customers running older releases are less likely to be making production changes, hence to create new problems, but the possibility of discovering a new bug on an older product is not nil. What will you do then? Also you may rely on the Engineering team to deliver troubleshooting assistance, not just fixes. Would you be able to conduct troubleshooting without help? Finally, customers are likely to run into problems with the surrounding environment: will the old release work if they have to upgrade the operating system? the database?

 

 

3. Be honest with the limitations within Support. Providing support for a slightly-old release is fairly easy since the staff remembers it well, but after several years it can become more challenging as turnover makes experienced staff rare and reproduction environment disappear. If you want to continue to provide support on older releases you should expect to beef up the knowledge base and the reproduction environment. It’s not just “free money.”

4. Make case-by case decisions. If an older release is relatively problem-free, has an adequate base of customers wanting to remain with it (meaning enough of a revenue base), and there are no compelling reasons to upgrade to the next release, you have a good candidate for extended support. Otherwise, you should probably say no. Ideally there can be a transition period during which minimal Engineering assistance is available for troubleshooting and the most critical fixes, after which time you can plunge into support-only mode.

5. Archive the older release code. You never know!

6. Communicate clearly. Customers that are running older products need to understand exactly what they are paying for. In particular, if absolutely no fixes are available, they need to understand the need for careful testing of any changes. It may be wise to schedule a conference with the customer to ensure that the special terms of the support-only contract are well understood.

7. Enforce the SLA. If a customer chooses to remain on release 5 after it’s officially sunsetted (support only, no fixes), be prepared for some constructive discussions the nesxt time she finds a bug. It’s important to carefully refer back to the agreement and encourage either a migration to the current release or a workaround rather than caving in to a fix.

8. You can charge more (for less, as it were…) Customers who want to remain on older releases may be prepared to pay a premium to avoid upgrade costs, and they should understand that, although the vendor is no longer required to create fixes, there are real costs associated with supporting older releases in terms of people, reproduction environments, and the costs of supporting a small numebr of customers. You can increase the cost by a fraction each year that passes to reflect that fact. (And I would never offer such support for less than normal maintenance rates.)

Bottom line: it’s absolutely possible to provide “support only” maintenance contract, without fixes, and you can charge a premium for support beyond the normal period, but beware of having to provide suppor tn older products when your staff is no longer familiar with them.

More knowledge base for premium customers

When building premium levels of support the focus is typically on assisted support features: longer support hours, faster response times, assigned support engineers, etc. But does it make sense to also include additional self-service features such as access to premium knowledge base articles? Let’s see the pros and cons.

Yes! There’s no reason why self-service features should not be included in a premium offering. For instance high-end, consulting-like white papers or access to the same knowledge base support engineers can access (before articles are sanitized and reviewed) would be appealing to premium customers. The other, obvious benefit is that the cost of delivering those extra features is very small, unlike that of typical assisted support add-ons.

No! There’s a technical issue with providing levels of access to the knowledge base, in that many tools only provide a public/private access dichotomy so providing customers with different access levels will require customizing the tool, which may be cost-prohibitive. But the larger issue is that providing self-service materials helps to cut down on requests for assisted support, so the temptation will always be to make the self-service information available to all customers. Many of my clients who initially embraced the idea of a graduated knowledge base (and made the necessary tool investment) later decided to publish all materials for all customers’ consumption.

So in most cases I would choose something else than graduated knowledge base access for premium support. We’ll see other self-service ideas in future posts.

Should resellers provide support?

Yes, resellers can provide support – and some do it well while others do not. So how do you choose?

Go with resellers if they can provide a unique benefit that you cannot provide. That could be Korean-language support, deep knowledge of the shipbuilding field, or the ability to support a customized version of your product.

Provide support yourself if your resellers are mostly sales outfits, with little to no technical expertise. If you let them provide support they will suck you dry of resources while pocketing the support revenue. And customers won’t be happy. Not a good combination.

If you choose reseller support

1. Select resellers with the proper infrastructure for support. For instance they should have a few trained technical staff members and a tracking system.

2. Offer training to the support staff and test their competence through certification tests, formal or informal.

3. Include minimum performance standards into the contracts so that you have enforcement tools. Require a minimum number of certified support staff, set maximum escalation rates and perhaps minimum customer satisfaction ratings. 

4. Define the revenue split between the reseller and you (for the amount of second-line support and maintenance you provide.) You can either split each support contract or set a yearly fee for your services.

5. Define the policy for handling customers who prefer to get support directly from you. Setting up a competitive situation between you and your resellers is always tricky. If the reseller is providing support you probably want to stay away from its customers. 

If you choose to provide support yourself

1. Create a good support sales kit for the resellers. You can repackage materials you already use for your own sales force but remember that resellers sell many products so don’t have the time or capacity to remember lots of details. This could be a great impetus to streamline your tools, and perhaps the support offerings themselves, including pricing, for everyone. Your own sales force will thank you.

2. Pay a commission on support sales. It’s not easy to sell support so expecting the reseller to do it out of the goodness of its heart is folly.

Finally, be open to a mixed model (some resellers providing support, some not), as long as you follow the recommendations above for each category of reseller.

Support for custom applications?

If the software you support can be customized extensively, the resulting applications may be completely different from the vanilla version, and your customers may want you to support them. What are the options?

Say no. Many vendors choose this apparently safe route. They only support the vanilla application and expect the customer to provide the troubleshooting and programming expertise to debug problems on the customized application. I say this is “apparently” safe because the reality can be that the support staff expands vast amounts of effort and time coaching and helping customers come up with the test cases from which they can work.

Team with a third party. A popular route, especially when the customization is created by a third party is to ask that third party to take over the support of the completed application. This should work well because the third party is familiar with the details of the application (at least if it built it) and has the technical skills required to perform debugging and enhancements. On the negative side, the relationship with the customer is mediated by a third party (which could be completely fine if you have an indirect model) and naturally the third party could heap all sins upon you if there’s a problem, even if the issue lies in the customizations. You also leave money on the table doing this.

Provide support using a custom quote. Some vendors are bravely trying to provide support to custom applications themselves. This is clearly risky unless they have a pretty good idea of how the application was customized in the first place, so typically such arrangements are limited to customizations done by the vendor’s Professional Services team, or vetted and approved by it. Vendors in this situation also need to ensure that they have a good handle on source code control. The pricing for supporting the customized application is established once the application has been inspected and is additional to the support of the base application.

Provide support using a standard quote. Here’s a new idea: rather than requiring a custom quote for supporting customized applications why not automate the pricing to some percentage of the customization work (this would require that the vendor’s own Professional Services group perform the customization.) The advantage of this approach is to streamline the buying process (and renewals). The main concern is to maintain an appropriate level of funding, especially for small-scale customizations that don’t cost very much upfront but may require significant levels of additional support. Are you experimenting with this idea? Tell us about your experience.