The FT Word – October 2007

The FT Word

The FT Word is a free monthly newsletter with support management tips. To subscribe, send us email with your email address. The subscription list is absolutely confidential; we never sell, rent, or give information about our subscribers. Here's a sample.

Welcome

Welcome to the October 2007 edition of the FT Word. Please forward it to colleagues you feel would enjoy it.

Two topics about support offerings for this month:

Delivering support for customized applications
Defining an account management offerings (following up on last month’s topic)

Delivering Support for Customized Applications

Thanks to Josh Baxter for suggesting this topic.

If you support a product that’s either a platform or is highly customizable, you will have to consider the challenge of providing support for custom applications. The potential for trouble is high since each application is different and you can’t simply apply the same rules for every customer. Here are some recommendations for supporting custom applications that will make the exercise successful and profitable.

1. Provide ample documentation and recommendations on customizations

With a highly customizable product it’s common for how-to questions to form a sizeable chunk of the case load. While you will never prevent all how-to questions it’s a good investment to create solid documentation for how to use the product and especially a variety of examples as close to real-life as possible.

If you can get the examples into the standard product documentation, great. Otherwise use your knowledge base. Your Professional Services team may be a wonderful source of examples taken from past engagements and requiring only a light cleanup. Structure each example with a task (goal) and the sample code.

2. Make (fee-based) training and consulting available

You can only get so far with documentation and the knowledge base. Many customers will need (and pay for) training and consulting services. Ensure that the training is sufficiently in-depth to get the customers to create quality custom applications. Nothing’s more dangerous than a little knowledge!

3. Implement a certification program for developers

In the same vein, you can protect both your customers and your support team by offering a certification program for developers that ensures a minimum level of competence. While larger companies can afford formal programs (and can even expect to make a profit on selling certifications), it’s fine to start with a modest, informal program, including such tactics as using (successfully) completed implementations as substitutes for formal testing.

4. Clearly delineate product support versus application support

This is the critical point: you cannot, both practically and financially, support custom applications as if they were your own product. For one thing, you typically don’t have access to the code. The code could be riddled with bugs (not that your product is bug-free, but still…). And the writers of the code may not be around any longer, as is not uncommon with third-party developers. Therefore you must be very careful about taking on a task that can be challenging to impossible.

You must define very clearly what you will do for customers who purchase product support, typically:

Help them install the product
Clarify any questions about the documentation or how-to examples provided in the knowledge base as they proceed through the customization project
Troubleshoot issues that can be reproduced on your system in-house

Note that product support does not include hand-holding throughout the customization effort such as

writing code (a big no-no beyond sharing the samples mentioned in point #1)
debugging code (customers should always expect to provide a small test case if they suspect a bug), or
testing code

Train the support team to refer requests for customization assistance to the appropriate organization, be it the internal Professional Services team or a third party.

Also note that, as part of product support, you won’t provide assistance on the use of the custom application (since you simply are not familiar with it), nor will you investigate bugs in the application, only those that show up on your reproduction environment. Naturally this leaves a number of gray areas since a certain level of effort will be required to perform reproductions and even before that to help the customer whittle down the issue to a manageable size, but it should avoid the bulk of the burden of supporting the custom application.

Finally note that the division of labor for support can work regardless of who created the customization: whether it was done in-house (with the developers still available for internal support), by your own Professional Services organization, or by a third-party – in the last two situations as long as the customer staff is properly trained on the customizations so that it can respond to the demands of the support staff, for instance to provide a small test case.

5. Consider offering full support for the custom application

Some customers will need more help than can be provided through product support, and some will actually be willing to pay for it. This is a high-end route, to be sure, but should be explored and can be profitable to the support organization.

Decide whether to provide level 1 (end-user) support. Many product support organizations are geared to providing level 2 support so embracing level 1 support may not be feasible – nor is it profitable with the typical level 2 staffing.
Make the custom code easily accessible to support engineers. It could reside at the customer’s site but should be available for troubleshooting whenever required. It would be crazy to take on application support without access to the code.
Strongly consider requiring an application “audit” before support starts. Inspect the application to make sure it’s working properly before you adopt it. You may want to waive this requirement if your very own Professional services group created the application. In any case, schedule a formal briefing with the developers so the support engineers can walk through the code and become familiar with it. It’s fine to push back and require better documentation or code changes if you feel that the quality is not sufficient. You can also use the audit to determine the cost of support.
Have the application developer(s) on standby for the first weeks. Most developers have a formal or informal warranty period while the customer works out normal kinks in the early days. Make sure that the support staff can have direct access to the developers as the kinks are being worked out.
Consider requiring higher levels of support for the application, specifically dedicated support. Many support organizations consider application support to be so complex that it must be done by a dedicated individual who is familiar with it. It certainly makes a lot of sense. It’s also an expensive option so smaller customers may balk at it. The ultimate decision depends on the expected complexity of the support. Take your time and assess the pros and cons with a few test customers if you need to validate your decision.
Consider recruiting a third-party support team for application support if it simply does not fit within your business. Third parties can use more flexible hiring practices and are exempt from your headcount limits, so that can be a good solution for everyone. And you would provide the product support to the third party. (Whether or not you are aware of it, some of your customers may be using a similar system already by having their third-party developers supporting their application.)
Carefully define maintenance requirements. What happens if you identify a bug in the custom application? Are you expected to fix it as part of the support contract or will the customer take care of it (most probably by hiring a third party to do it)? What if the customer wishes to add a new feature? Who does the work and does the updated application need to pass the audit again? Is there a limit on the number or frequency of changes?
Carefully consider upgrade requirements. What happens when the underlying product release is sunsetted? Who is responsible for updating the custom application and within what time frame? You can make a variety of choices here depending on customer size and the stability of your product but be sure to spell them out in advance for customers. However tempting it may be to allow customers to remain on older releases, there comes a time when the additional work and expense can no longer be justified.

Bottom line: custom application support is feasible and can be profitable if properly structured, but don’t just jump into it.

Defining Account Management Offerings

Last month we discussed whether adding an account management offering to support offerings was worthwhile (see http://www.ftworks.com/index_files/newsletter9-07.htm.) Assuming you’d like to take the plunge, here are some ideas for structuring the service and marketing it to customers.

1. Decide where account management fits within the other support offerings. Most companies consider account management to be a high-end option and therefore require that customers contract for the highest level of support available before becoming eligible for account management. Under that logic, you would require that customers be on 24x7 support or receive dedicated support (support through a designated individual or group), whichever is your highest level of support, before they can opt for the account management option. You don’t have to mandate that account management sit on top of the highest support offering but at the same time it is rarely compatible with low-end offerings.

2. Assuming that your existing support offerings are fee-based, account management should be fee-based as well but you can consider making a few exceptions. One is to offer account management on a temporary basis to customers that with special needs such as customers that are going through a difficult escalation or customers that are in a large purchase cycle. An interesting idea is to allow each regional sales executive to designate an account in his or her region that can receive the service free of charge at any one time. With temporary arrangements be sure to indicate to the customer that the service will terminate at some point unless the customer decides to purchase it. Also some support organizations provide account management at no extra fee to their largest (support) account. For instance customers paying over $1 million per year in support fees would get account management “thrown in.”

3. When it comes to selecting features of the account management offering, the first decision is for the main attraction: the account management itself.

Structure it: will the account manager hold reviews daily (probably too much!), weekly, monthly, or quarterly? Are the meetings at the customer site or by phone? A mixture is fine for instance quarterly meetings at the customer site and all others by phone.
Scope it: what will the account manager do? Provide reports on support activities (useful but probably not compelling by itself)? Help escalate support issues (great, but most customers will think this should be part of the basic support offer)? Brief the customer on updates and new products (excellent when tailored to the customer’s needs)? Make recommendations on product usage that improve efficiency (terrific)? Be sure to match the deliverables to the skills of the account managers. Non-technical account managers will have a tough time with the technical updates, but they could invite guest speakers when needed.
Distinguish it from regular support: when should the customer contact the account manager versus support? Unless the account manager also happens to be the technical support contact for the customer there should be a clear separation of duties between the two. For instance: questions about how-to’s or support issues go to support; questions about the technical roadmap go to the account manager. Make it easy for customers!

4. Many companies choose to bundle many add-ons with their account management offering – at least when it also constitutes the highest support offering. There’s no bound here except for your imagination: free or discounted training; free or discounted consulting; product discounts; special webinars; attendance to the user group; membership in a Customer Council or other special group, etc. Before you go feature-happy, be sure to consider the cost of the giveaway as well as the tracking burden. Clarify each add-on: do you mean to offer 2 days of training for one person in a regularly-scheduled class or 2 days at the customer site? Are the attendees subject to bumping or could you find entire classes filled with “free” attendees? Ideally you will find add-ons that provide great perceived value to the customer while costing little on your side.

5. Which brings us to a key point: validate with a sample of customers. If customers feel that weekly conference calls are too much and training discounts useless for long-term customers, why include them in the offering at all?

6. Account management is not cheap to deliver. Many companies price it with a healthy minimum so as to allow each account manager to concentrate on a handful of account (typically less than a dozen – but that all depends on what you include in the program.) Run the numbers before setting your price.

Customers who have access to account managers typically report high levels of satisfaction with the company and the product (and they also renew their account management contracts for the most part, showing that they value the service.) If you have large customers it makes sense to add account management to your array of support offerings.

If you’d like more ideas about creating support offerings check out The 10 Commandments of Support Pricing at http://www.ftworks.com/index_files/10cmdts.htm.

FT Works in the News

SSPA News published an article I wrote with a client of mine at Cisco on the topic of unifying multiple support centers. It should be of interest to all of you who are trying to bring together support centers separated by geography, history, or products. The article is A Unified Framework: How to make 50+ Contact Centers Function as One. You can read it at http://www.thesspa.com/sspanews/September07/article2.asp

Curious about something? Send me your suggestions for topics and your name will appear in future newsletters. I’m thinking of doing a compilation of “tips and tricks about support metrics” in the coming months so if you have favorites, horror stories, or questions about metrics, please don’t be shy.

Regards,
Françoise Tourniaire
FT Works
www.ftworks.com
650 559 9826

About FT Works

FT Works helps technology companies create and improve their support operations. Areas of expertise include designing support offerings, creating hiring plans to recruit the right people quickly, training support staff to deliver effective support, defining and implementing support processes, selecting support tools, designing effective metrics, and support center audits. See more details at www.ftworks.com

Subscription Information

To request a subscription, please drop us a note. The mailing list is confidential and is never shared with anyone, for any reason. To unsubscribe, click here.

You may reproduce items in this newsletter as long as you clearly display this entire copyright notice. Contact us if you have questions about republications.

Back to Newsletter Archive