How Busy are You Going to be?
The Science and Art of Support Forecasting

By Francoise Tourniaire

Are you putting together your budget for 2005? Are you planning for a new product launch? In either case, a key step is to figure out how many support cases (requests) you’re likely to get. As with any forecasting activity, forecasting your support needs isn’t an exact science, but following a set methodology will make a big difference both in the accuracy of your results and your ability to convince others that your forecast is correct – an important ingredient if you’re justifying headcount.

Many support centers use a “see what sticks” approach to forecasting. They ask for X more headcount and rejoice if the answer’s yes – and grimly bear it if it’s no. If you are still “guessing” your headcount, you’ll get much better outcomes by creating a formal forecast.

On the other hand, some support centers over-engineer their forecasts. They typically have enormous forecasting spreadsheets that are so obscure and complicated that only a few specialists dare to use them; and the numbers that these spreadsheets spit out don’t seem to match reality, probably because they can never be used properly. Over-engineered spreadsheets also tend to sport colors and fancy formatting – the better to hide how unwieldy they are. If your forecast is over-engineered, it’s time to start over.

Begin with the end in mind
This classic time-management advice works well for forecasting. Start by defining how you need to slice and dice your forecast. Many support centers staff by product lines, yet forecast by product. Doing this is a waste of time and a frequent contributor to spreadsheet over-engineering. Forecast only for the level of detail you need. In the same vein, don’t bother with a monthly forecast if a quarterly forecast will do.

Start with the installed base
Unless you’re just starting out or you only provide support for a limited warranty period, you’ll do very well by carefully forecasting the needs of your installed base. There are two benefits here: you know who they are, and you know what they do, or at least what they’ve done in the past.

If you sell support contracts, dig out the contracts and apply the proper rate of renewals. Adopt the model of the Finance group, making sure you understand and agree with their assumptions for renewal rates. It will save you having to compute the tedious 12-month recognition schedule for support contracts.
If you sell support by incident, simply collect the number of seats or licenses for the installed base.

Add new sales
New sales are more challenging since they’re by nature uncertain and they’re typically forecast in dollars without regard to what matters to you: contracts, seats, products, and the like. Fortunately they’re usually forecast by region, which is a big help if you run an international organization.
Do your best to transform the new sales dollars into usable numbers for your purposes, but don’t overdo it. For example, unless you have clear evidence that the product mix will change in the coming year, simply apply this year’s product distribution for new sales to next year’s forecast. If the sales team can’t forecast by product, what makes you think you can?
Note that this step is critical if you deliver support for a limited warranty period after the sale. On the other hand, if you provide support on yearly contracts to a very large installed base and new sales are tiny in comparison, don’t sweat it.
At this point, you should have the total number of seats or licenses that you expect for next year. Set up the forecast in the spreadsheet, using several worksheets if needed to distinguish between regions or products as needed.

Define the incident rate
The tricky part is determining the incident rate, that is, how many cases each customer (each seat, each license) will generate. The incident rate is truly a magic number for the forecast since variations in it go directly to your bottom line. How do you get a good estimate?

In most cases, the best predictor of the future is the past: what was your incident rate this year? Did it vary a lot from month to month? Product to product? Region to region? If you find a stable pattern, you can be pretty sure that you have a good number that you can use for the forecast.

If patterns are all over the place, you’ll have to dig a little. Was the rate high in July and August because you had a new release? Then you need to take new releases into account for the forecast and use a variable incident rate that matches your historical pattern. If rates are much higher for a particular product line or a particular region, you probably need to create a separate forecast with different assumptions for that part of the workload.

As you analyze your incident rates, don’t go overboard. Small variations don’t warrant creating separate forecasts. If the incident rate for product X is 2.5 per year and the incident rate for product Y is 2.9 per year, it’s probably safe to use an average across both products, especially if the volumes are small.

This is also the time to take into account improvements and changes. Are you rolling out a massive self-service initiative next year? Then your incident rate should decrease. But don’t be over-optimistic and forecast a 50% drop the very month the system rolls out. For one thing, schedules do slip, and cliff-like improvements are very rare in the support world.

If you’re starting from scratch, you’ll have to come up with a likely incident rate. This isn’t easy. Use whatever indicators you do have, whether it’s for similar products, your experience during beta, experience of other companies that support products of similar complexity, etc. Generally speaking, new products and new initiatives generate higher than usual case loads, both because the products are less stable and the customers are not as comfortable with them, so be conservative. For example, an incident rate well below 1 per year for a brand-new product means that you have a foolproof installation process. How reasonable is that expectation for your environment?

At the end of this thought exercise, you’ll have an incident rate (or a handful, corresponding to your different environments). The incident rate may vary over time or it may be constant. Set up the incident rate in your spreadsheet as an assumption so you can easily modify it. If the incident rate computation is complex, I recommend you document your assumptions in a separate worksheet of the forecasting spreadsheet so any user of the forecast can easily grasp how you came up with the incident rate and make appropriate changes in the future.

Compute the case volume
Armed with the seat forecast and the incident rate(s), you can compute the case volume through a simple multiplication, or more likely a series thereof since you’re likely to have several sets of products, several regions, and several incident rates.

Do a sanity check. Are the numbers much higher or much lower than this year’s? If so, can you explain why? If not, go back and make appropriate changes to the assumptions. I like to run both a “high” forecast and a “low” forecast, using different assumptions, to model both the best case and worst case before settling on specific assumptions.

It’s also helpful to do a reality check every month after you get the actual numbers for that month, even after the forecast has been turned into a budget. If you see a massive increase in cases, you may want to modify your forecasted incident rate based on that new information.

Voila! You’ve now forecast your support cases per month or quarter. In an upcoming article, we’ll discuss creating a staffing model to handle the cases.

About the Author
Francoise Tourniaire is the founder and principal of FT Works, a consulting firm that helps technology companies create and grow their support operations. She is the author of “The Art of Software Support”, a practical guide to running support organizations. For more information, visit www.ftworks.com or call 650 559 9826.