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 2006 issue of the FT Word. Please forward it to your colleagues who are interested in support issues. Subscription information is at the end.

Topics for this month:

Scaling staffing models: do I need to grow staff in a linear manner?
Boosting renewals or alienating customers: walking the fine line

And an invitation to visit the new, improved FT Works web site at www.ftworks.com, now featuring the full archives of the newsletter.

Scaling Staffing Models

Thank you to Ram Ramadas for suggesting this topic.

Here’s the dilemma: having carefully prepared a staffing model, you plug in some big numbers to see what will happen when your customer base triples and, horror! the staffing model faithfully computes that your support staff will also triple. Will you need to rent an additional building to house all those people? Will the CFO have your head on a platter? Probably, not, especially if you are starting from a small base.

Let’s start with a quick overview of how staffing models are created.

1. Start by evaluating the size of the customer base, using both the existing base and the forecasted sales for the period you are considering.

2. Find or estimate the incident rate, that is the number of support cases logged for each customer in a given month. You should be able to get a good starting estimate by simply using your current metrics. The incident rate can vary widely depending on your customers’ maturity, the complexity and stability of the product, and the availability of self-serve solutions. I’ve seen number from .01 to 10 incidents per customer per month: it all depends on your specific situation.

3. Multiply the customer base by the incident rate: you now have a forecast for the case volume.

4. Then, estimate the productivity of your support staff, that is the average number of cases that each individual can close in a month. Here again, use your current experience as a guide. The productivity number is greatly influenced by the complexity of the support issues. If you support highly complex products, you may be lucky to get something like 2 cases closed per day. If you support relatively simple products, you may get 50 cases a day.

5. Divide the case volume by the productivity and voila, you have a rough measure of how many people you need.

6. Massage the number to take care of: shift work (if you have extended hours, you will need more people since the off-hour shifts are typically less busy, hence less productive); very small staffing numbers, which will need to be rounded up to allow for vacations and such; specialization requirements (big is beautiful in support centers: small specialized teams are comparatively less productive); and finally desired responsiveness if you provide phone or chat support with tight response requirements (you will need to overstaff slightly to ensure that customers don’t have to wait).

So, assuming you have an accurate staffing model for today, what can go wrong when you scale it (way) up?

1. Customers get smarter. Over time, customers become more knowledgeable about the products and need less assistance. Typically, new customers consume more support than long-time customers. If you expect to keep customers for a long time, you will find that the incident rate (use for step #2) should decrease for that reason.

2. Products stabilize. Over time, products get more stable (at least we hope so!) so overall the incident rate goes down. This, of course, may work in reverse when new products are introduced or new versions of existing products that include major changes.

3. Customers buy more products. Since a customer with 10 systems does not generate 10 times as many requests as a customer with a single system, your incident rate per system should go down as you acquire larger customers, or as existing customers acquire more systems. To confirm this effect, track both your incident rate per system and the incident rate per customer.

4. Your knowledge base gets smarter. Each time a customer can resolve an issue without contacting support, your incident rate goes down. And if the same knowledge base can help agents resolve issues more easily, their productivity goes up as well, so you win twice over. Quite a nice plug for knowledge management, don’t you agree?

5. Your staff gets smarter. Over time, as your staff becomes more experienced, productivity should go up. Naturally, if you lose a bunch of them on a regular basis all that experience and high productivity walks out of the door. High attrition is very bad in support centers. Also note that if you do a great job with self-service, productivity may decrease since the complexity of the cases that are reported to support will increase. That’s ok since the lower case volume will compensate for it, but it’s not an absolute rule that productivity increases over time.

So what happens when we scale support? The incident rate should go down while productivity should rise slightly. The two combined means that you don’t have to scale with the customer base, not even close in most situations.

Model the improvements cautiously. Staff productivity won’t suddenly get multiplied by two, even after a wonderful training program. And the incident rate won’t plunge magically when the long-awaited maintenance release becomes available. Phase in any improvements. And make sure that your incentives match the staffing model: if no one gets measured at least partly based on productivity, you can bet that productivity will not increase.

Boosting Renewals or Alienating Customers – It’s a Fine Line

Thank you to Neil Baron for suggesting this topic (as well as many other business topics in the past.)

If you charge for support, and if you package support into annual contracts, you know the importance of a careful renewals process, the key elements of which include the following.

a database that tracks contract expiration
a method to generate accurate quotes
a timely contact with customers to request renewals, typically 90 days prior to the contract expiration date for business customers
a system of reminders so customers are reminded several times prior to the expiration date that they must take action on the renewal
a policy to discontinue support if payment if not received promptly
ideally, a process to co-terminate support contracts for a given customer who has made multiple purchases

If you have all of the above in place, congratulations! The next step is to ensure that the prices you quote are appropriately stepped up from the prior year contract, especially if the customer got a special support price as part of the initial purchase. In other words, don’t blindly quote last year’s price or you will risk leaving money on the table. But don’t forget to compare last year’s price to this year’s. If the increase is steep, and even if this year’s price is “correct” as computed, you may want to take special action to avoid an angry reaction from the customer.

1. Check if the contract includes any limits on year to year price increases. Many larger contracts include price increase ceilings, typically linked to a particular government index. If your customer enjoys such a clause, respect it. Note that the ceiling usually applies to increases in any particular year, so if you forgot to charge a higher price for many years you may be able to increase it only a little bit for now, up to the ceiling.

2. Spot large increases. Even if the contract does not include ceilings, expect the customer to react (badly) to any increases higher than 10% or so. I would not send a bill with a large increase without doing some preparation.

3. Preempt negative reactions with a preplanned discount. Customers who feel they are being gouged will likely request a discount. Why not serve one up proactively, avoiding the entire discount discussion for this particular renewal, and perhaps preempting future discount requests as well? If customers feel they are being treated fairly they will be more likely to accept quotes “as is” in the future. Do show the list price on the quote along with the courtesy discount so the customers can see how good a deal they are getting.

4. Highlight special circumstances. Say your customer got a special deal last year to pay support for only half the year. It will look like their bill for this year has doubled, right? Be sure to show their cost for the last 6 months of last year alongside this year’s bill.

5. Help customers plan for the future. If some customers are looking at repeated increases over the next few years to “catch up” on a low historical support cost, talk to them about their likely future support bills so they can build their budgets appropriately. In many organizations it’s very difficult to get additional resources once the yearly budget is fixed, but it’s not so difficult to get money in the regular budget cycle: make it easy for them to pay you.

Bottom line: don’t charge the customer the “regular” support price without comparing it to last year’s and offering a reasonable middle ground if the increase would be enormous: save yourself a fight this year and buy some goodwill for the future.

FT Works in the News

Check out our brand-new web site at www.ftworks.com. Among other improvements you can now browse the FT Word archives and even search through them. Many thanks to the many readers who suggested and pleaded for this functionality.

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