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 February 2010 edition of the FT Word. Please forward it to your colleagues. (They can get their own subscription here.)
Topics for this month:
- From staffing model to reality: what do we do with the peaks?
- Revenue-share pricing for support: can it work?
- David Kay and I are launching the Third Tuesday Forum just two weeks from now on February 16th in Santa Clara, CA. Sign up now. Space is strictly limited to ensure a very interactive session with Victoria of Vocera who will be speaking about customer satisfaction surveys.
From Staffing Models to Reality: Handling the Peaks
Many thanks to Flo Oswald for suggesting this topic.
When we create a staffing model we try to be as realistic as possible. We use our historical experience to forecast incoming volume and productivity levels accurately. But even with the best staffing model we will get surprises:
- A new release that generates many more support cases than we thought it would
- Unexpected staff turnover that translates into many new hires whose productivity lags the “average” forecasted into the model
- Many more new customers than planned (this is a good problem to have, but it’s still a problem!)
- An inconvenient hiring freeze that forces us to function below the expected staffing levels, either for a little while or for a long time
- A temporary, unexplained influx of cases that feels like every customer needs help now.
Regardless of the cause for the spike, the outcome is the same: slow response, a spectacular increase in the backlog, unhappy customers, and frustrated staff members. So what do you do?
1. Anticipate. For instance, it’s not hard to predict that a new release will likely cause a spike, and historical data will suggest both the size and timing of the spike. Plan accordingly: schedule training for another time; limit vacations, reorganize the coverage schedule.
2. Monitor volume fluctuations. It’s a lot easier to dig out if you take action quickly. If you allow the backlog to build, it becomes a lot more difficult to escape the vicious cycle of customer escalations. Create a backup plan for any significant jump in incoming volume and backlog volume.
3. Look for a root cause. Handling a new release peak is by definition a temporary exercise. Working with an influx of new customers may not be as temporary.
4. For temporary issues, batten down the hatches. Most support organizations can temporarily (for a few days or weeks) handle 10, 20, perhaps 30% more volume by simply reorganizing schedules, cutting down on project work, and temporarily reassigning more staffers to handle customer issues. No need to change the process: everyone will just need to pull together for the duration..
5. For structural (long-term) issues, you must change the process. Organizations that are pushed to function in emergency mode for extended periods of time break: people leave (and often it’s the best people who leave, since they are also the ones that are most marketable), others lose faith and work less hard, and everyone works less efficiently in the ensuing crazed climate of customer escalations and multiple emergencies.
Assuming you need to change the process, here’s what to look for:
- More self-service. Getting the support reps to “work harder” is silly. You need to decrease the incoming volume. This may require a painful investment, that is allocating money or people to creating a better self-service environment at a time when you feel you need all hands on deck but it’s worth it. Again, if the current model is not working you need to change it.
- A streamlined case resolution process. Crises are an ideal time to make significant changes to your case resolution model. Inefficient habits you should target include: too many layers (2 layers should be just right for any support organization, really!); too much specialization (generalists are always a great goal), too much regionalization (3 regions are enough to cover the world, although naturally you need to allow for language specialization if needed); cumbersome procedures to elevate cases to the engineering organization; and any regularly-needed procedures that require manager approval.
- Saying no more. Can we really say no to customers? Absolutely. Rather than delivering poor service to all customers for all requests, wouldn’t it be better to deliver great service for fewer requests, or to fewer customers? For instance, why keep cases open (and statuses flowing) for cases associated with bugs that we all know will not get fixed this year? Close the case, keep the bug open, and tell the customer that the bug is relatively minor and may not be fixed for a long time. Clear the way for the really important work.
- Just-in-time mentoring. During a peak it’s likely that the support staffers are deluged with requests that they cannot solve themselves but could handle if only they had a little help. Organize regular (daily!) case reviews with a senior engineer to quickly go through the backlog. Naturally this will pull the senior engineers away from their cases but the multiplying effect is very powerful.
- An Engineering blitz. If the issue stems from poor product quality you need to be sitting in the office of the development manager, working on a strategy to address product quality. Nothing you can do within the support organization can make much of a difference compared to the engineering attention.
- Move to more affordable pastures. This is never a short-term fix, but if your cost structure is simply too high, even after your streamlining efforts, you should consider less costly locations including: home-based staff (maybe the same staff you are using today!) and offshoring. Training a new team can take a lot of time, however.
By the way, all these techniques apply to handling peaks at any level in the support organization, including sustaining engineering. If you have a big backlog of bugs to be fixed and no relief in sight your best bet is not to jump up and down and demand action. Rather, think of ways you can reduce the incoming volume, for instance by taking on the responsibility of declining bug fixes. Yes, it’s painful, but customers would rather hear a “no” today than the very same “no” six months down the line.
Revenue-Share Pricing for Support
Many thanks to Abdo Albeshelani for suggesting this topic.
We often hear the idea that we must use “value-based pricing” for support – that is, get away from a model of pricing based on cost. How about pricing support specifically on the value-add to their business?
Here are a few thoughts:
- Many vendors price support based on license price or subscription price (for SaaS vendors). Therefore the issue is not so much about support pricing, but rather license pricing.
- Today, almost all license pricing schemes depend on either the system the customer is running or the number of users for the system (concurrent or named).
- There are a few vendors trying to use different models, models that could be described as revenue-sharing or at least value-sharing. For instance, customers using an e-commerce architecture may pay a small fee per transaction in the system; or a case-tracking tool could be priced per case entered into it; or an e-marketing platform may charge by the number of individual messages sent out. All these schemes are based on the benefit to the customer of using the system.
- It’s a lot easier to implement such revenue-share pricing for a SaaS vendor since transactions are very easy to monitor and audit but there’s no reason why it could not be done for package software with proper auditing mechanisms. Since we find it normal to charge customers based on named users charging customers based on transactions is not that different.
- If the license (or subscription) revenue is based on transactions then it’s very easy and natural to base the support pricing on the same scheme. The interesting wrinkle of this approach is that it’s hard to forecast and lock the number in advance! We are spoiled in support to assume that we know a year in advance what we will charge and recognize from individual customers. With a transaction-based price it’s a surprise each month – but like all surprises it can be forecasted.
Will l transaction-based pricing take off? Customers don’t seem to like being nickled-and-dimed so I’m not sure it will have lots of fans but certain types of applications, notably sales applications, seem to be an attractive match for such an approach.
If you are using some kind of transaction-based pricing for support, please tell us about your experience!
And for more information on how to set support pricing, see The Business of Support.
FT Works in the News
Are you based in the San Francisco area (or will you be there on Tuesday February 16th)? That morning, David Kay and I will be hosting The Third Tuesday Forum, a roundtable for support executives to discuss the topics we embrace and wrestle with every day. Our first presenter will be Victoria Perkins, Vice President of Customer Services at Vocera Communications, who will speak about their customer satisfaction survey. Please join us in Santa Clara, CA, around a breakfast buffet. There is no membership fee, just sign up ahead of time and make a small contribution for the food and room fees ($40). Interested? Register now!
I can hardly believe it myself: my new support marketing book is going to the printer this week! It is still lacking the all-important title, so if you can think of a good one (the subtitle is “Desining and Selling Support Packages”), please let me know today. You will earn my eternal thanks and a spot in the acknowledgement section of the book. I am accepting advance purchases here.
I will be presenting a special pre-conference workshop on designing and selling support packages on May 6th in Santa Clara, CA. Click here for more details.
And a reminder to enter your Web support site in the ASP’s “Ten Best Sites” competition. Even if you don’t win, you’ll get a wealth of statistical benchmarking and feedback from our judges. Click here for details: http://asponline.com/whyenter.html The deadline for entries is 3/5. I will once again serve as a judge for the competition.
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.