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.

What are “business hours”?

Many vendors offer a choice between “business hours” support and “24×7″ support. It seems simple enough: if the customer has an issue during daytime hours, Monday through Friday, it falls under business hours support. Otherwise, it would qualify for 24×7 support. But in a global world this simple definition quickly fails to provide a standard that can be used to categorize cases. What to do?

1. Define the frame of reference for business hours. You can define business hours as the business hours for either the country where the contract is signed or the country where the technical contacts are located. Say you sell a contract to a US customer who has technical contacts in the US and in Europe. Under a contract definition business hours would be US business hours (so the customer’s European contacts would get only limited service during their business hours.) Under a contactdefinition business hours would be US business hours for the US-based contacts and European hours for the European contacts. Note how much more generous the contact-based definition is. Further note that if you use very different pricing mechanisms in different regions a customer could get very cheap support under a contact-based definition by making a purchase in one of your low-price regions.

2. Define whether business hours are determined by region or by customer. Imagine you have a customer based in Hawaii and your support center is in California. Depending on the season Hawaii is 2 or 3 hours behind Pacific Time. Do you provide business hours service until 5pm Hawaii Time or 5pm Pacific TIme (2 or 3pm Hawaii Time)? Most vendors use a region-based definition, so for instance in the US customers get business hours from (say) 5am to 5pm Pacific Time, which means that East Coast customers are within business hours until late in the day but West Coast customers get early-morning service (and those poor Hawaiian customers get cut off mid-afternoon.)  Some vendors choose to calculate business hours from the customer’s time zone instead. The customer-based definition requires slightly more work for entitlement checking but it’s not insurmountable.

3. Consider limiting the number of technical contacts. It’s a good idea to limit the number of authorized support contacts, not so much because it limits the number of inquiries (although it might) but because the authorized contacts, over time, become more knowledgeable about the product so the caliber of the questions they pose is higher. But limiting the number of contacts is especially important if you make the choice of defining business hours from the contacts’ perspective. If a customer happens to have operations (and contacts) around the world it could get full support around the clock (on weekdays) for the price of business-day support. Perhaps not what you intended?

4. Expand the definition exercise to weekends and holidays. Business-hours support typically excludes weekends and holidays. But what’s a weekend? If you think Saturday and Sunday, you haven’t worked with Israel or Indonesia, say. July 4th is not a holiday in 99% of countries in the world. As in step #1 you can either go by your calendar or the customer’s, but be clear about it.

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.