The FT Word – December 2008

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 December 2008 edition of the FT Word. Please forward it to your colleagues. (They can get their own subscription by clicking here.)

This month’s topics:

Moving from Supporting Licensed Products to SaaS Offerings

Many thanks to Abdo Albeshelani for suggesting this topic.

As SaaS solutions gain recognition in the market some vendors are moving from packaging their products with a traditional licensing agreement to offering subscription services. What does this migration mean for the support team? One way of thinking is that this makes no difference: customers are customers and the product is the product, so the licensing arrangement matters little. On the other hand, a switch to a SaaS model is likely to bring subtle and not so subtle shifts in the types of customers likely to purchase the product as well as the type of requests they make on the support organization. Here are 10 ways your operation may need to adapt.

1. The revenue stream is different. Support for licensed products is usually purchased via a separate support fee, which is assessed yearly. In contrast, SaaS vendors usually charge a monthly fee that bundles the use of the product and the support itself. If you are accustomed to getting a separate income stream, get ready to arrange for a carve-out from the subscription revenue. And in most cases the fee will need to be collected monthly so no more “war chest” of collected but not yet accrued support revenue. Note that you can (and should) retain the concept of premium support levels with SaaS by offering faster response time, designated contacts, technical account management, and all the other bells and whistles you may already offer on the licensed support side.

2. Demos and trials are more common. SaaS vendors often offer limited-time trials to entice new customers. While trials may be supported by sales engineers, there may be more pressure to provide support from the post-sales support team since the options for customizations are typically limited so specific expertise is not required. The administration of trials and demos (e.g. terminating them after a set period) may also fall into Support’s responsibilities.

3. The customer base may move to smaller customers. SaaS offerings are that they are more accessible, financially and technically, to smaller customers so you may find that many of the new customers are from the low-end of the existing customer range. This means more basic “how-to” questions, more handholding, and fewer truly complex cases.

4. Get prepared to support end users. Compounding the shift to smaller customers you may find yourself increasingly pulled to provide support to end users when you were used to providing support only to the system administrators who, in turn, provided support to their end users. This would translate into requirements to hire a different profile of staff. Note that it’s perfectly possible to provide support only to system administrators even under a SaaS model and that you can price end-users support as an extra, but you won’t likely escape the requirement of providing support to at least some end users.

5. You will support a better-defined product. While many SaaS offerings give customers plenty of opportunities to customize the application the possibilities are much more limited than with the typical licensed product. Furthermore the code lives right on your machine so it’s a lot easier to access for testing.

6. SLAs will change. Your current support SLAs probably say something about response time, and little else. With a SaaS offering you will need to add uptime to the set of commitments you make.

7. You need close connections with Operations. Remember that the main component of customer satisfaction is product quality (some things never change!) So instead of, or rather in addition to, the absence of bugs, customers will now scrutinize the system uptime. Therefore the Support team becomes tightly dependent on the Operations team for success and you will need to forge good connections and processes with it, even more than with the Engineering team. Actually for many vendors it’s the Operations group, not Support, that interacts with Engineering for bugs.

8. You may have to provide more phone-based support. With high-complexity products and when supporting system administrators electronic support is king. With end users you will likely need to beef up your phone system and processes.

9. You may experience more 24×7 demand. In the old, licensed product days, the expectation for the vendor was to have emergency support available off hours, and that only for the skilled system administrators who, in turn, took care of the end users’ issues. In the SaaS world, and especially if you are support end users, there’s a stronger expectation that support will be available around the clock, and not only for major issues.

10. Provide specific implementation assistance. SaaS systems can usually be used from day one but that doesn’t mean there are no rampup requirements. If you don’t make specific provisions for new users they could suck Support dry – and still come away dissatisfied with the level of assistance. Instead, provide abundant written documentation for beginning users; hold regular webinars on system use and customization, and assign account managers during the implementation timeframe to ensure that the customer experiences success from the start. With a SaaS offering you definitely need to invest more in the customer at the beginning, but if you can keep the customer for the long term you will generate profit then.

The Best Way to Cut Costs: Overhaul your Processes

It’s not difficult to cut support costs: simply lay off a few people. For most support organizations, headcount costs make up 70-80% of overall costs, so clearly any reduction in staff will translate into immediate savings. But taking a hatchet to the organization is a terrible way to go: as you cut people (even open reqs) you can also hurt customer satisfaction. The best way to minimize support costs while maintaining custom satisfaction is to streamline your processes. Reviewing and improving processes should be a recurrent exercise for the organization (a yearly audit is a wonderful idea) but it’s particularly important in cost-cutting times. The beauty of the process approach is that the savings are permanent, not just a quick fix, and that they will grown over time as the customer base increases. Process improvements are often accompanied by increases in customer satisfaction so you get a double benefit of savings and customer satisfaction.

Making process changes can be difficult as it requires change, and people tend to cling to the established system. But in difficult times it’s actually easier to make changes, as everyone understands the need to do more with less. Here are 6 ideas for improving the case resolution process. Try one today.

1. Route cases directly to the support staff.

This is a perfect example of a change that is typically feared by the support staff initially so may be pushed through more easily in difficult times. (The good news is that the support staff will probably appreciate it within months or even weeks!) Instead of having customers talk first with a dispatcher, have incoming calls go directly to someone who can resolve the issue, at least if the customer passes the entitlement check. Having fewer touches is a cost saver but more importantly you avoid costly phone tag. And I guarantee that customers will love this change!

2. Avoid time-based handoffs.

Are there any opportunities to get rid of handoffs? Handoffs are costly because even under ideal circumstances it takes time for the individual who is taking over to become familiar with the problem. IT may make sense to mandate a handoff if a level-1 staff member is not making progress after 15 minutes, but what if the solution is in sight? Wouldn’t it be better to grant an extra 5 minutes to complete the request?

3. Route accurately.

Still under the theme of avoiding handoffs: handoffs are common when cases are misrouted. Take a critical look at your routing logic. Too often the categories offered to customers don’t make sense to them, so they do what any reasonable human being would do: pick at random. Scrutinize the choices and make them “obvious” (and don’t have too many: choosing from 5-7 options is ok; choosing from 13 options is a hassle.)

4. Avoid over-specialization.

Routing problems (#3) often arise from tight specialization that requires fine distinctions between requests. While it makes perfect sense to specialize for very complex issues, over-specialization gets in the way not only of routing but more dangerously of resolving issues: a support engineer who’s an inch wide and a mile deep will resolve issues flawlessly within that one inch, but we know how customer issues have a nasty habit of not announcing that inch of width when they get started… Try to get your team to be a mile wide and one inch deep on all topics before boring down that one-inch width.

5. Get rid of useless reviews and authorizations.

Many support organizations require a manager approval for the smallest refunds, or require a senior staffer’s approval before filing a bug. If the approvals are positive the vast majority of the time, let the staff work without them beyond the basic training period (do record the requests and perform regular audits to ensure that everyone is following the rules.)

6. Standardize processes.

If you have multiple product teams, support centers, countries, or what not, try very hard to use the same general process throughout. It will make everything easier: customers who cross your boundaries won’t get disoriented; you will be able to share the load between centers more easily; you will save on having to customize your tools one way rather than many. By all means allow for necessary variations but actively discourage local interpretations.

Read more about intelligent cost cutting in the newly revised booklet 20+ Ways to Cut Support Costs from the Smarter Support Library SM.

FT Works in the News

Check out the new posts at Marketing Wise, the FT Works support marketing blog:

You can get the latest support marketing news at  http://ftworks.wordpress.com/. Subscribe to the blog and recommend it to others

Read more about intelligent cost cutting in the newly revised booklet 20+ Ways to Cut Support Costs from the Smarter Support Library SM

20+ Ways to Cut Support Costs has been completely revised and enhanced in November 2008. You can purchase it here. You can find the entire Smarter Support LibrarySM here. The latest addition is Budget Magic.

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

Back to Newsletter Archive