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 to the May 2008 edition of the FT Word. Please forward it to colleagues who would enjoy it.
Only a few days until the first Marketing Wise workshop, where you can learn everything you need to know about support marketing. There are still a few seats left. Sign up here. And if you can’t make it but would like to learn more about support marketing, read on…
This month’s topics:
- Could support pricing be too low?
- The “support” process – what to do when the problem is in Engineering?
Could support pricing be too low?
How’s that for a revenue-boosting strategy: increase support pricing. It can be hard to increase prices, but sometimes it really makes sense because prices are set too low. How can you tell?
- Salespeople will typically complain that prices are too high: after all, it’s always easier to sell something, anything, for a lower price. But if some of them suggest that prices could be higher do listen, especially if they happen to be the top salespeople and are selling a lot of support.
- Customers often say that prices are too high and it’s unlikely that any of them, under any circumstances, would suggest raising prices. Do not automatically assume that customer complaints about high prices are grounded, however. Complaining about price is a common approach when the real issue is quality.
- The competition is charging way more. While it can be exceedingly difficult to find out competitive pricing and to interpret the pricing (especially when discounted) if everyone else is charging 20% and you’re charging 15% you have wiggle room.
- Discounts are killing you. It’s mighty difficult to raise prices but plugging the discount hole is usually much easier. While the new accounting rules have made discounting less wild, at least in larger companies, there’s still a hefty amount of enthusiastic discounting going on, especially at quarter-end. Prevent out-of-control discounting.
- Smaller accounts pay too little. Many times support prices are defined as a percentage of the license price, which leads to absurdly small amounts for smaller licenses. If you find yourself delivering similar amounts of support to tiny and medium customers it’s time to use the support friend: floors (or minima) a la, support is 20% of the license with a minimum of 5k/year (say.) Floors are very common for the higher levels of support and can be hefty.
- Very large accounts pay a small amount. If you charge fixed prices for support you are probably leaving money on the table with the larger accounts. Say you charge 80k for technical account management, a hefty amount to be sure. If all your accounts are about the same size that’s a fine strategy but if you have some mega-accounts that require very large investments in account managers you should be charging them more. Beware of fixed prices if you have a large range of customers. It’s better to use a percentage and a floor so you can capture that high-end revenue.
- Some products get a cheap ride. If you’ve always charged 18% of list but the new product line, while just as complex to support, is half the price of the old one, you will suffer. It’s fine to charge different amounts for different products (within reason: I once worked with a customer that had a different pricing percentage for each product line and just reading the price list was enough to make me dizzy.)
- You’re spending more than you should. Failing to meet your margin goals does not automatically mean that your prices are too low: it could be that your expenses are too high! But if there’s no way at all to meet customer demands within budget it could be an indication that your prices are too low. Do some competitive analysis first.
The “Support” Process: what to do when the problem is in Engineering
Most, perhaps all support organizations could do a little better when it comes to executing on internal processes: a little faster response time, a little tighter backlog management, a little more effort with the knowledge base… But this article is not meant to make us feel guilty (we’ll leave that for another day); rather, let’s focus on a common problem: the support team is working quite well, but the minute it needs help from Engineering it encounters a vast black hole. Customers are complaining about “support” but the problem lies within another organization.
1. Run a tight ship
Before you go fight the good fight with Engineering (or any other organization), make sure that your own organization is in decent shape. If response time performance is off the charts (in a bad way) or the support staffers are known to tell customers off, you won’t make much headway trying to address external issues. No, you don’t need to be perfect before reaching outside the organization, but you should be in reasonably good shape. In particular, routine cases that do not require Engineering assistance or involvement should be under control.
2. Confirm & measure the problem
Make sure you understand the problem and the scope of it thoroughly. Rather than relying on hearsay, dig into the data a bit: is it one outrageous story that is driving the complaints or is there a steady stream of comparable issues? One of the challenges you will probably run into is metrics, or lack thereof. Ideally you should have a way to track requests into Engineering, how long they sit until a response is obtained, and how long until the resolution is achieved. If you do not, by all means see whether you can implement the changes required to track the requests. The cleanest way to do this is to track Engineering requests separately from the original Support request that created it, perhaps by using a subcase so you can track response and resolution time (and steps.)
At a minimum, tracking tools should allow you to tag requests as being escalated to Engineering. Once that’s in place, you will have a rough idea of incoming volume and backlog. And you can perform a simple audit on this week’s or this month’s requests to obtain manual metrics.
3. Approach the issue gently but firmly
It could be that your counterpart in Engineering will welcome you with open arms and take your word for it that the process needs to change. On the other hand, you will probably need to exercise your vaunted people skills to get an audience and some semblance of attention. Couch the issue in terms of customer satisfaction, not your team’s travails. And use the metrics you gathered in step 2 to present a dispassionate picture. “Customers are waiting an average of a month to get confirmation that a suspected defect is, indeed, a defect” is a much better start than “You never respond.”
4. Be reasonable
If you’re starting with a large mess, insisting that three years’ worth of neglect be cleaned up within a quarter, or that every small defect must get a formal disposition will get you nowhere. Think of a huge support backlog: wouldn’t you first start with high-priority items? Wouldn’t you contact the customers on very old cases to make sure they’re still looking for a solution? It’s a pain for the support team to have to contact customers on the old cases or to review each request again, but it makes sense, really.
5. Define goal posts
Defining, measuring, and adhering to internal SLAs is the only rational approach to working with Engineering (or any other team). For instance you may settle on a one-hour turnaround for emergencies, one week for anything else (again these are internal metrics, not to be shared with customers.) And this is the time to invest in measuring tools so you can actually tell whether the goals are being met. If you cannot measure a particular goal perhaps it should not exist?
In my experience many Engineering organizations resist SLAs because of a deep-seated feeling that they won’t be able to meet them 100% of the time. (We in Support are quite relaxed about missing SLAs from time to time – we’ve done it so often!) Take pains to reinforce the idea that an SLA is a target and a 100% success rate is not expected.
6. Get help from above
Most Engineering VPs are quite ready to help with support issues, but they have other responsibilities, and more often than not their goals don’t include working on customer problems – only cranking out releases. See if you can garner assistance from above to press the cause of customer assistance, ideally to the point of including the internal SLAs into Engineering’s goals.
7. Don’t automatically dictate a Sustaining Engineering group
Many support executives believe that the only way to get timely assistance from Engineering is to create a Sustaining Engineering group, whose only responsibility is to work with Support on customer issues. While a Sustaining team certainly avoids conflicts between new releases and support work, it can also be isolated from the main Engineering group, and often staffed with junior engineers that are limited in what they can achieve. Especially with a small Engineering group or one with highly specialized subteams it’s often best to distribute support-related work throughout Engineering. So let the Engineering VP decide on how to provide the assistance. Stick to the goal posts (#5) rather than the implementation details.
8. Beef up Support’s technical abilities
The most timely technical help is what you can provide yourself. Invest in your own team. For instance, it’s often a good idea to develop staff who can read code and isolate issues to that level. Yes, it’s a big investment but service to the customer will be better.
9. Be open to changing the submission process
Typically the first request from Engineering when Support requests better SLAs is to institute a review process, a gate through which all support issues must go before they are escalated to Engineering. This is because Engineering teams have a keen memory of the “silly” cases that came to them and shouldn’t have (there are always some.) Many Engineering groups also vastly overestimate the proportion of escalations to Engineering. You may be asking for Engineering assistance on no more than 10% of cases (and most of that is bug-related, anyway) but Engineering may feel that virtually all cases come to them beyond the simplest ones.
Is instituting a pre-Engineering review a pain? You bet it is. If the support staff is competent the vast majority of Engineering requests are sound and reviewing each and every one of them adds time and delays to the process. But reviews (or checklists, another common requests) are very useful for more junior staff so see what you can do to accommodate the spirit of the requests, if not the letter.
10. Set up regular review sessions
One of the most frustrating aspects of trying to fix Engineering/Support problems is how people will fixate on a couple of bad escalations, where either organization dropped the ball, and disregard the 99% of issues that went through the process normally. An effective technique is to hold regular review meetings where the first item of business is to review metrics, reinforcing in everyone’s mind a dispassionate view of what’s going on, before moving on to the special cases.
FT Works in the News
We’re just a few days away from the debut of the one-day workshop, Marketing Wise, that covers everything you always wanted to know about support marketing. It’s still possible to sign up here. Get a makeover of your entire support marketing efforts and network with other like-minded professionals.
In conjunction with the workshop I am launching an interactive blog. Check it out.
I will be presenting at the SSPA conference in Santa Clara on May 5th and 6th with my colleague and client Don Frye of The MathWorks. Come join us at 2pm on Tuesday for an inspiring story of rolling out KCS with limited resources.
I just completed the web site evaluations for this year’s ASP awards and the good news is that support web sites have improved tremendously in quality over the past five years of serving as a judge. I’m particularly impressed by the candidates in the “Small Vendor” category that manage to pull off very serviceable web sites with small budgets. (And for some entrants in the general categories I had to think long and hard about suggestions for improvement, my favorite part of the evaluation…) More about this in next month’s issue.
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.
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.
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.