The FT Word – November 2007

By Technical Support

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 November 2007 edition of the FT Word. Please forward it to colleagues you feel would enjoy it. (To subscribe, send us email)

This month’s topics

· When selling support, can we say no to customers? (or how to nip discount mania in the bud)

· Creating effective SLAs (not too aggressive, not too wimpy, but just right)

When selling support can we say no to customers?

Thanks to Danielle Cole for suggesting this topic.

Here’s the scenario: you’re trying to renew a support contract. The customer asks for multiple concessions, which you reluctantly grant, trying to salvage your quota. Is there ever a point when it’s better to just walk away?

The quick answer is yes, absolutely, you can – at least if you’re willing to take the consequences of the lower revenue stream and clients that abandon the software because they cannot make it work properly. Here are 10 points to remember along the way.

1) Start the renewal process with a satisfaction check. At least for larger renewals, check the support activity for the customer in the past year. If the customer never called, it will be harder to sell the renewal (although the customer enjoyed the upgrades as well as the peace of mind that comes with a support contract.) If the customer called and had a bad experience, you may have more of a challenge. Ask the customer about their experience before moving to the selling proper.

2) Confirm the configuration. Many companies simply send an invoice with what they think the customer is using, but the invoice is often incorrect because of changes during the year (or simply bad data.) Make sure you have the correct configuration first, then build the invoice.

3) Have a clear game plan for pricing  and discounting. If you routinely give discounts with customers you are training them not to take the first price given. Define and apply guidelines for how much flexibility you will show for renewals. Typically there is none for small renewals, and only limited discounts for large renewals, much smaller than would be expected for product sales. And if you’re going to give a discount it may make sense to offer it immediately, then stick to your guns rather than start a “bargaining” session that has no logical end.

4) Offer options. Perhaps the customer won’t pay for 24×7 support with 2-hour hardware replacement but would pay for something more modest, say business-day support only and return-to-the-factory replacements. It’s often better to sell a smaller-scope package for a smaller price than to discount the larger package.

5) Along the same line, consider a “time and material” offer that clearly demonstrates the value to the customer of purchasing a contract. That is, if a customer without a contract needs help they can get it but at a price that’s high enough to justify purchasing the contract (and peace of mind.)

6) Allow purchasing less than a year of support (for a small premium.) Customers may find it easier to buy in 3-month increments.

7) Work with customers so the support renewal fits into their budgeting cycle. For most renewals approval is almost automatic if it’s budgeted.

8) Cut off support if the customer does not renew. Often the individual who is negotiating the renewal is not the person who needs the support. Once the support contact is made aware of the renewal it could be a swift resolution.

9) Keep trying. If a customer has been off support for 3 months they may start to feel the pain and be more receptive to renewals. Charge a small premium for renewing a lapsed contract or customers will play the “off again, on again game” to save money on renewals.

10) Monitor your renewal rates. If they are falling off sharply it could be that your offering is simply too expensive (or, another way to look at it, your support package is not attractive enough.) If that’s the case you may need to adjust your pricing or the features of the offering.

Bottom line: not every customer will renew every support contract. Don’t sell below your target profit just to keep a customer – and revise your offering if your renewal rates are low or dropping.

For more information about renewal sales, see the 10 Commandments of Support Pricing.

Creating Effective SLAs

Thanks to Steve Moore for suggesting this topic.

SLAs or service-level agreements are the foundation of good support. By defining specific goals for support delivery support managers can establish clear expectations with customers and, at the same time, define meaningful metrics to benchmark their success.

What’s an SLA?

A service-level agreement is a formal definition of how a service will be delivered to the customer. An SLA typically includes elements such as service hours, response time, escalation process, etc.

Related to SLA you may hear the term SLM or service level management, which is the set of processes required to define and manage an SLA. OLA or Operational level agreement is a term sometimes used to designate agreements between two internal groups when handoffs or escalations are required. For instance you may specify the conditions under which the Engineering team will provide assistance to the Support team. (many groups simply call that an internal SLA.)

Why is an SLA useful?

SLAs are useful in several ways

  1. By not promising anything you rely on the customer’s interpretation of what is normal. So you may think that responding to requests within a day is great but if your customers think an hour is what they need problems will surely ensue. Having a clear definition of expectations helps create a more orderly process.
  2. Services are, by definition, intangible. Anything you can do to make them more real is helpful if you’re trying to sell them, either literally if y our support is fee-based, or more subtly if you need to obtain funding for “free” support.
  3. Setting delivery goals helps clarify internal goals. If the entire support staff knows that phone calls must be answered within two minutes it’s more likely that you will see some hustling as the monitor boards turn redder.
  4. Knowing what you must deliver to customers gives you instant metrics

What’s in an SLA?

SLAs may include any variety of conditions but they usually cluster on a small number of basic items:

· scope of service: what is included in the agreement. This typically requires a description of products and versions supported and may also specify who is allowed to obtain service and sometimes sets a maximum amount of service requests. It’s very useful to also define what’s not supported and what happens if the request is about an unsupported item.

· support hours: when is support provided for each geography and each special case (nights, weekends, holidays). It’s perfectly fine to provide different levels of support at different times but it should be made clear in the SLA

· support channels: how can customers report issues – by phone, chat, web site, email, in person, fax, etc. Here again it’s fine to have different channels available for different purposes or different types of customers, but that must be specified in the SLA

· response time: how quickly can customers expect a qualified individual to start the troubleshooting process. This is one of the crucial and messiest areas of SLAs. Response time is often tied to the type of issue reported, with more urgent issues deserving a faster response. Response time is often presented as a target, that is: we will meet a (say) 4-hour response time 90% of the time.

· resolution process: how are issues typically resolved. This would describe likely when and why handoffs may happen and how communication would flow throughout the process. This is an optional element for an SLA – and even when included the SLA only presents a high-level description of the resolution process.

· resolution time: how quickly can customers expect a partial or complete solution to the problem they reported. There’s a real exposure here: in many situations it’s basically impossible to guarantee a specific resolution time. What if a software product is found to have a severe defect that will take days to track down, let alone fix? For that reason, many alternative items can be included instead of resolution time. Read on.

· escalation process: what happens if the resolution of a problem does not unfold smoothly. This is a good alternative to a fixed (and dangerous) resolution time commitment.

· uptime commitment: how (un)likely is it that the underlying system will fail. This is a common SLA item for SaaS.

· SLA management process: how will the customer and the provider maintain visibility on achieving the targets. This is common for internal SLAs and SLAs with large external customers, not at all common otherwise.

SLAs may include a slew of additional items depending on the type of products you support, your customer requirements, and the capabilities of your support team. For instance if you support hardware you may have an onsite response commitment (a specialized response time commitment for hardware). Customers may require performance reports against the various targets. And most software vendors define priority levels for support cases so they can define different response times for different levels of severity.

SLAs include targets for each item. For instance uptime may be 99.9%; response time may be 1 hour.

SLAs may include penalties (and occasionally incentives) for failing to meet (or exceeding) targets

What do SLAs actually look like?

SLAs are essentially contracts so if you are creating one for an external partner you should see your attorney. For internal use an informal approach is fine.

Regardless keep the language as simple and straightforward as possible. More words usually create more opportunities for confusion. As long as you are able to clearly describe what you are providing, a shorter agreement is preferable to a longer one.

What’s different in an internal SLA?

Internal SLAs are not that different from internal SLAs, although they may capture slightly different elements essential to the relationship. For instance, internal SLAs often capture minimum achievements for customer satisfaction or percentage of issues escalated to the next level, items that are rarely present in an external SLA.

Since internal SLAs (or OLAs) exist mostly to provide service to the end customer it’s crucial that they be coordinated with the external SLA. For instance, if you are relying on an internal Engineering group to handle code-related issues and you provide 24×7 service to your customers you’d better have the Engineering team on a 24×7 schedule as well. Your external SLA can never be better than your (worst) internal SLA.

What mistakes should I avoid?

The overwhelming mistake is simply failing to have an SLA. The most common reason I hear for not having one is that it creates expectations that cannot be met. Not true: the expectation that’s impossible to fulfill is the silent one created by the absence of SLAs.

Another common failing of SLAs is fuzziness. Are you open 5am to 5pm Pacific Time or 5am to 5pm customer time? What if the customer is based in Europe? Do you provide a toll-free hotline in the US or around the world? Does resolution time start when the issue is first reported or when it’s (finally) reproduced at your site? Be clear and specific to avoid problems.

A more subtle issue is relevance, or lack thereof. It’s great to define your hours as 8-5 but if the customer typically does backups at nights and needs support then you have an obvious mismatch. Work with your customers to determine what their real needs are. You may not be able to meet them all, but at least you’ll be aware of the gaps.

Some SLAs also suffer from delusions. I often see SLAs with 15-minute response targets around the clock. Great goal, but organizations that rely on an answering service or cell phones have a very hard time meeting such a tight deadline. Another example would be resolution time commitments for software.

What makes a great SLA?

A great SLA is

· complete: it covers all aspects of the service

· agreeable to the customer: so, for instance, if the customer needs extended hours the SLA should provide it (at least if the customer’s willing to pay for it!)

· realistic: no 15-minute response times if you just can’t meet them

· measurable: achievement metrics should flow naturally from the SLA.

· clear: no obfuscated language that only lawyers could decipher

· known to all end users: if the SLA only reaches the buyer of your services and the end users never sees it you lose the benefit of defining clear expectations

· supported by internal SLAs, if appropriate: you need to define a cradle-to-grave approach to issue resolution

· updated regularly: needs change so it’s important to review and adjust the SLA periodically to match new business conditions. A well-designed SLA should be able to last months or years but some tinkering is useful and normal

· aggressive: it should not be too hard to deliver 24-hour response times, but can you do 4? 2? 1?

It’s a good idea to review your SLAs on a regular basis to see if customer, competition, or internal changes warrant a revision.

FT Works in the News

We added a new face to the FT Works’ team. Rajib Akhter is based on the East Coast and has a wealth of experience with support tools, among other talents. You can read more at RajibAkhter.html

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

Tagged under: