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 October 2009 edition of the FT Word. Please forward it to your colleagues. (They can get their own subscription here.)
Topics for this month:
Avoiding the feature request black hole
Kill email – a rallying cry for support organizations everywhere?
Avoiding the Feature Request Black Hole
Thanks to Laura Tom for suggesting this topic.
Another month, another dilemma involving Support’s relationship with Engineering – with Marketing added to the mix this time. Here’s the dilemma. In most cases, customers who wish to request new features contact the support organization who logs the requests and then… nothing!
Specific SLAs are rarely defined for feature requests. Most of my clients do not make any promises whatsoever when it comes to feature requests, starting with whether they will be studied at all from someone other than the original requester. True, even (minor) bugs are frequently treated with the same disdain, but at least someone usually bothers to confirm that they are, indeed, bugs, before leaving them untouched.
Cradle-to-grave tracking of feature requests is vanishingly rare (unfortunately). Since many feature requests lie completely unexamined it’s not surprising that very little feedback ever returns to customers, and that’s too bad because vendors are missing out on the opportunity to give customers good news. After all, some feature requests do get implemented, but rarely is the tracking good enough to be able to go back to the customer(s) who made the request in the first place and confirm that the feature is now available in a new release. Shame, really.
So what should we expect with feature requests?
- Feature requests are just that, requests. There should not be any guarantees that any one of them will be implemented, and certainly not in a particular length of time. The reality is that customers often have requests that are very specific to their circumstances and may not benefit or even be of interest to other customers, so it’s quite normal that many feature requests will not be implemented. Customers should be told very clearly when logging a feature request that there are no guarantees whatsoever on implementation.
- Most fundamental product improvements are not driven by customers. While customer requests can be very interesting they are usually confined to modest, incremental changes. In my experience it’s the very rare customer who suggests a revolutionary change. The Product Marketing team must own the leadership of product innovation – and anyone championing customers’ feature requests should not be deluded into thinking that they will change the world. They usually don’t.
- Individual feature requests are often fragmented and overly specific. Part of the reason is the way they are generated (one particular customer looking at one particular use of the product) and part of the reason is the way they are logged (usually in a hurry by a support rep whose natural instinct may be to look at pine needles rather than the tree, let alone the forest, and who knows that not much will come out of the request anyway, even if beautifully crafted). So the result is that many feature requests are barely decipherable, let alone useful as guides to product decisions.
With that, here are some practical approaches for managing feature requests that ensure no good one is neglected and also that customers receive appropriate feedback.
- Support is the right channel for feature requests. What I mean by that is that creating a different channel just for feature requests is rarely a good idea, at least if your customers typically have a support contract. (See the note below about online communities for a different view.) Support is also the voice of the customer so it makes sense to funnel all requests through it.
- Improve the quality of the tracking. I bet that you carefully review each bug to ensure it is documented accurately. Don’t tolerate a slapdash approach to feature requests. Carefully check for duplicates (the bane of feature requests) and fuzzy thinking. If the support team cannot understand a feature request, what makes you think that Product Marketing can? If you have a high volume of requests you may even want to have support perform a pre-review of the requests, in particular bundling similar ones together to expedite their adjudication.
- Fast-track the key requests. It’s easy to get lost in zillions of feature requests. Why not accept that priorities make sense for feature requests just like they do for bugs. A high-priority feature request could be one that’s critical for a particular customer or simply one that’s popular with many. Push the critical requests to be reviewed swiftly, perhaps at a weekly or biweekly meeting if there’s enough volume for that, or in a ad-hoc manner. The goal of the review is to get an agreement on what requests are likely to be implemented vs. not, and for the ones that make the cut to assign a likely timeframe for it.
- Implement a bulk review process. While only a handful of critical requests can reasonably be considered under the fast-track process it’s possible to review all requests logged in a 1-2 month’s period (yes, all!) and accept or deny them in a surprisingly short amount of time. Experience shows that it’s best to consider the requests in batches so duplicates, near-duplicates, and close matches can be easily recognized and marked as such. Then for each bundle a decision needs to be made, which could be: no, will not implement; yes, will consider at some point in the future; or yes, will consider “soon”. Declined requests can be communicated to customers immediately. It sounds like an enormous amount of work but an experienced product marketing manager seems to be able to make decisions on dozens of requests accumulated over several weeks over the course of a couple of hours. A required tool for this step is to be able to group requests into larger sets.
- Close the loop. Once requests are grouped into sets it becomes quite easy to shepherd them through the implementation process – so one of the key learnings for customers is to accept high-level feedback on general improvements rather than require specific feedback on individual requests.
- Enlist the User Group. The main challenge with feature requests is their individualistic approach. So if customers can get together en masse to vote for a particular set of feature requests it becomes a lot easier for the PM team to respond to a manageable number of requests. It also makes it harder to respond in the negative, since the handy excuse that the requests are applicable only to a couple of customers cannot be used!
- Leverage online communities. Online communities are just a virtual version of the user group and they can absolutely be leveraged to gauge the interest of customers for particular feature requests, with the benefit that they function continuously and allow a larger democratic process than the user group. The problem with online communities is that they can foster a one-by-one view of the requests that can be tedious and counter-productive. In contrast, a debate at the User Group meeting must focus on larger clusters of requests, which is often more productive.
The bottom line is that it’s possible to improve the processing of feature requests, as long as (1) support buys off on logging better, more accurate, more detailed requests and (2) everyone accepts that requests are best aggregated in sets rather than treated individually.
Thanks to Jan Ingham for suggesting this topic.
Email support has been a staple in support organizations. In addition to providing a support hotline (and sometimes instead of providing one), vendors invite their customers to email their questions to some mailbox, say firstname.lastname@example.org. While email is a standard channel for logging cases I – and many support managers – believe that it’s a terrible one and should be dispensed with. Kill email! I say.
Why email is a poor case-logging channel
Let’s start with an inventory of what makes email a poor channel for logging cases.
- Spam. Even with decent spam filters an open email channel accumulates spam messages.
- No categories, no routing. One of the first things many support organizations want to do with new cases is route them appropriately. So installation questions go one group and performance-tuning questions to another and how-to questions to yet another. It’s almost impossible to route incoming emails accurately (although dedicated email-handling tools sure try!) so this first step is often missed, creating extra work
- No entitlement checking. Since anyone can send email to the support mailbox it also means that entitlement checking must be done after the fact. And even if a properly-entitled customer emails a new case it’s sometimes difficult to tell who s/he is (for instance if using a personal email address).
- Few details. Customers who send email messages often send very few details of the problems, details that would speed up the troubleshooting process such as the version number they are running, or system logs.
- Cut and paste overhead. If you enter email requests manually into the case-tracking system the cutting and pasting will get tedious fast .
- Messy response/new case mix. In many support organizations responses to requests and new requests live side-by side in the support mailbox. This makes it hard to meet response time if the support reps have to wade through responses as well as initial requests.
How to kill email
So how do you make it go away? Simple: first create an attractive alternative and then… switch over!
- Provide a web form instead. While a full-fledged portal is best a web form is an excellent substitute if your budget and tool are limited. Don’t go crazy asking for loads of information, that will only make customers mad. Ask for what you really, really need to troubleshoot the issue, no more.
- Better, provide a full-fledged case management portal. Many case-tracking tools these days include a portal that allows customers not only to create cases but also check their status, add comments, close cases, etc. Use a portal if at all possible. Customers will quickly train themselves to use it.
- Advertise the portal. If you build it they may come – but only if they know about it.
- Reward the portal users. The carrot is always better than the stick. If you respond to requests logged via the portal faster than those logged in email, customers will switch .
- Make the portal the norm. Update your support policy and contracts to commit to response time targets only when cases are logged via the portal, not via email .
- Get the support staff to praise the portal. It does take a little more effort to log a case on the portal compared to sending a quick email. So if customers are already primed to use the portal to manage their existing cases and to use self-service options they will develop the new habit of logging cases there, too. So ask the support reps to say things like, “Thanks for attaching the log to the case. It really helps” (positive reinforcement) as well as “When you log a case on the portal you can attach the log right then and there” (urging a customer to abandon email).
- Turn email off. Really! Now we are not talking about never emailing customers, or allowing them to email back, but simply about turning off email as a case-logging channel. Create an automatic responder that says “thanks for your note; please go here [URL] to log a case.” The URL can be either a web form or the portal.
Customers are often surprisingly docile when email support is turned off, at least if there is a good alternative. So don’t let worries about a negative reaction prevent you from turning it off.
FT Works in the News
I’m still working on the support marketing book, revising and rewriting. I’m hopeful it can be released by year’s end! In the meantime check out the support marketing blog, Marketing Wise.
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