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 August 2007 edition of the FT Word. Forward it to a colleague!
Two topics for this month, one nicely tactical and the other one strategic:
- Is auto-closing cases a good idea? (tactical)
- Increasing productivity in support (strategic)
Is Auto-Closing Cases a Good Idea?
Thanks to Ben Thompson for suggesting this topic
It’s easy enough to set up your case-tracking system to automatically close cases after they have been open for a certain number of days under a specific status. But is it a good idea from the customers’ perspective and as it relates to internal efficiency? The answer, as for most complex issues, is a resounding It depends.
- When working with low-complexity issues such as customer service issues it’s fine to close cases as you provide answers, without specifically asking the customer for confirmation. Some proportion of cases will need to be reopened because the customer has a follow-up question but it should not be large.
- When working with high-complexity issues it’s best to wait for the customer to confirm that the answer you provided is indeed the one that works, since so many factors are in play. However for truly simple cases it’s fine to do what I call an optimistic close: close the case as you answer, hoping that the answer will do the trick.
- Automatic case closure can incent case owners to simply let issues slide until they get closed automatically. This is particularly common if the case closes silently, without alerting the customer about the closure. If you tell customers that the case is being closed and provide an opportunity to reopen the case if needed, the problem is lessened but you still need to audit cases to ensure that all necessary precautions are taken by the case owner prior to closure. A good start is to keep an eye on the amount of reopened cases. It should be very low (and relatively even across all the staff members.)
- If you choose to close cases automatically you may want to give customers a heads-up before the closure, as in “We think this issue is resolved and will close it automatically on X date. If you need more assistance about this issue, please let us know by adding a comment online at URL or by calling us at NUMBER.”
- Automatic closure should occur reasonably fast. For instance, selecting a two-week delay for automatic closure is silly: either the issue is resolved and you can close the case within a couple of days at the most, or it’s not, and you should not close the case at all.
- Closing cases automatically is never as good as the positive confirmation of the customer declaring that the issue is resolved. Train all staff to request and obtain confirmation most of the time.
Bottom line: auto-closing a good tool when used within appropriate limits, but waiting for customer confirmation is best.
Increasing Productivity in Support
Thank you to Rick Morris for suggesting this topic.
Is your CFO leaning on you to cut costs without impacting customer satisfaction? Then you only have one alternative: increase productivity. But how can you possibly squeeze more out of your overburdened staff? Here are ten ideas to improve productivity.
1. Define productivity
Exactly what is productivity in a support environment? Many people would think about cases per staff member but that’s not really the best way to look at it. Start with customers: if you consider your entire customer base, how many customers does one staff member serve? Include all staff members, not just the ones who actually respond to cases. (Many support organizations are bloated on the non-customer contact side, as we’ll see later.) So say you have 2000 customers and 20 staff members: you are looking at a 10:1 ratio – that would be a low ratio, not uncommon in a high-complexity environment. If you have 20,000 customers and 20 staff members the ratio would be 100:1.
When you compute the customer:staff ratio only include customers who are likely to contact support. So if you have 4000 historical customers but only 2000 still using the product then use the 2000 figure. This exercise should be easy enough if your customers are required to purchase support contracts (and yes, I know many support customer databases are in shambles – great time to fix yours!)
If you don’t have support contracts and especially if you don’t track individual sales, as would be the case if your company operates with an indirect sales model, you may never know the exact size of the customer base. Do your very best to construct a reliable approximation – your Finance partners should be able to help you with that.
So your goal should be to increase the customer:staff ratio over time.
2. Promote product quality
The #1 cause of support requests in any environment is the quality of the product and its accessories such as documentation and implementation assistance. So always keep an eye on making the customer’s experience as painless as possible. And remember that quality is not just measured by a small number of bugs: ease of use is also very important.
3. Beef up self-service
If customers need help, it’s probably much cheaper to provide it in self-service – and customers actually like well-designed self-service support so you’re not short-changing your customer satisfaction scores on the altar of productivity. If you support low-complexity products, you may be able to shift over half your current cases to the web. Even in a high-complexity environment, shifting even 5% of cases to the web would translate into savings of a similar magnitude, at least past your initial investment.
So your goal should be to decrease the incident rate, that is, the number of cases per customers, shifting the burden to the self-service system. With fewer cases your team should be able to support more customers with the same amount of effort.
Note that improving self-service support may increase the overall usage of support by customers: customers may switch from 2 cases a month to 10 self-service sessions and 1.5 cases, but the total cost would still be less than the original 2 cases.
4. Build up the knowledge base
Certainly a better knowledge base will improve self-service but it also has great leverage on the productivity of your support staff. Encourage the team to improve the knowledge base.
5. Streamline the case resolution process
A painless and liberating way to increase productivity is to make the resolution process simpler. Try easy changes such as removing the requirements for approvals for various actions and switching to a “trust and verify” model. Remove bottlenecks. Simplify recordkeeping: if closing a case means wading through 355 resolution codes, it will either be done badly or very, very slowly.
6. Make productivity increases a part of everyone’s goals and objectives
As every manager knows, what gets measured gets done. If productivity is an important goal for you (and it should be!) then all members of the team need to see that goal as part of their individual goals and objectives.
For an individual working on self-service, a good metric is probably the incident rate. Yes, the incident rate is influenced by many factors such as product quality but over the long run a decrease in incident rates coupled with increasing usage of self-service and high levels of satisfaction with self-service would paint a convincing picture that self-service is working.
For an individual working on cases, cases resolved is the standard metric, although never allow it as the only method of measurement unless you’d like to field lots of complaints from customers about cases terminated abruptly and from staffers about cherry-picking in the queue. Also be careful about relying on cases per head if you are simultaneously engaged in a self-service initiative: case loads should go down with better self-service, but complexity will increase, so you may need fewer people, but they will also resolve fewer cases…
The simple act of measuring productivity and discussing it overtly will help focus people’s thinking toward making individual improvements.
7. Eliminate non-support tasks
Do you believe that each page of documentation needs to be personally checked by a support staffer to ensure quality? Are you spending a sizable chunk of your headcount doing tasks that are not really your responsibility? Perhaps you should bow out of non-support tasks – or at least get some kind of compensation for it. For instance, many support teams regularly teach customer training classes. Wonderful! Then they should share in the revenue opportunity, or get some kind of cost relief.
8. Streamline non-customer duties
It’s rare to find support teams with too ample a staff to work with customers, but it’s not unusual, in my experience, to find pockets of low productivity associated with non-customer tasks: planning, self-service, quality control, and even managing. My strong recommendation is to ruthlessly seek out and remove any fat in areas with no direct customer contact, including the managers of customer contact areas.
9. Raise the bar regularly
It’s good discipline to regularly increase the targets for productivity. So if you are supporting 10 customers per support head, aim to support 11 (or 10.5: the number is less important than the principle.) Ratchet up quarter by quarter, year by year.
10. Hire well, manage performance, and control turnover
While process changes (described so far) are very important in improving productivity, there are amazing differences between individuals, as you will quickly realize when you put measurements in place. It’s not unusual to see 1:2 differences in productivity between individuals, even if you are careful in your measurements and compare individuals with similar duties (and also forbid cherry picking and other “gaming” activities.) Clearly the quality of the staff members has a huge influence on productivity. Hire carefully, seeking out individuals who have demonstrated productive involvement in prior jobs. Manage up or out: do not tolerate mediocrity or worse. And hire for the long run, especially if you support high-complexity products: you want to keep people at least twice as long as it takes for them to get “really good” at what they do. One year is a good target at the low end; aim for two years or more for high complexity.
For more information on these topics, see the following FT Works tools:
- Collective Wisdom: Transforming Support with Knowledge
- Best Practices in Support Metrics
- The Complete Guide to Hiring Great Support Staffers (and its companion, The Complete Guide to Hiring Great Support Managers
FT Works in the News
SSPA News published an article I wrote entitled Leveraging Support Data to Drive Product Improvements. You can read it at http://www.thesspa.com/sspanews/July07/article4.asp
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