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.
Happy New Year and welcome to the January 2011 edition of the FT Word. Please forward it to your colleagues. (They can get their own subscription here.)
Topics for this month:
- Introducing The Number of the Month – a new feature of the FT Word, for fun and reflecting
- Selecting the perfect support model – scalable, consistent worldwide, and delivering a world-class support experience
- The Third Tuesday Forum breakfast for January 18th: Joe Hines of Apple Computer talking about the confluence of social support communities and content creation
The Number of the Month: 53%
I’m trying out a new feature for the newsletter. Each month, I will highlight an interesting statistic from the world of support, designed to trigger thoughts – and, I hope, a bit of controversy at times!
This month, I offer you 53%. According to CSO Insights and quoted in Customer Relationship Management in July 2010, this is the percentage of firms that use a SaaS CRM solution today, as opposed to on-premise. In 2003, the number was just 15%.
I believe it, if I judge by the number of my clients I have who are in the process of switching over to SaaS…
Selecting the Perfect Support Model
Many thanks to Tim Ozirsky for suggesting this topic, which is a nice follow-up to last month’s discussion of how to switch to Touch and Hold.
This time, we consider a more complicated task: selecting the “perfect” support model, one that is scalable, applicable worldwide, one that provides that always elusive consistent, world-class support experience to all customers, and (why stop now?) one that works well for all product lines, whether hosted or on-premise.
Perhaps the best way to start is by admitting that perhaps there is no miraculous support model that will work in every situation – so your task is to identify the best match overall and be able to adapt it without losing its essence.
Here are some suggestions for the design process:
1. Consider the entire support experience. Choosing a support model should not be limited to how you resolve issues logged by customers. You need to consider self-service and communities as well. A personal pet peeve is that the various support channels are too often disconnected, so customers who are disciplined enough to use the knowledge base first need to then navigate to a totally different place to log a case. Make it seamless.
2. Don’t worry about the status quo. It’s quite possible that your re-architecturing exercise will require changes in procedures, in metrics, and perhaps in organizational roles. Start with a blank slate and don’t handicap yourself by thinking too much about the consequences of the exercise, at least at the start.
3. Know your customers. If you are serious about delivering world-class support, you know that the arbiters of world-class are your customers. Ask them what they want, and don’t ask just the friendly ones, either. For access to a highly-selected, but devoted segment of the customer base, set up a booth at the User Conference and listen.
4. Focus on the major products. Pareto’s law says that a small set of products covers the majority of customers. Focus on them and treat smaller products as exceptions. And of course there needs to be an exception to each rule: if you have a small product on which the company’s future is riding, use it as your design centerpiece.
5. Be global. I find that my clients often plan model changes “at home” before deploying worldwide, and not surprisingly they find that the outside world holds unexpected surprises that interfere with their planned changes such as foreign language requirements, restrictive labor laws, and customers that demand features that are completely different from what home customers want. Anticipate the differences by making the project an international one from the start. You may want to pilot in one geography but at least you will be aware of global requirements from the get-go.
6. Get educated on the possibilities. If the organization is used to working with one particular model, it’s often difficult to think out of that box. Use the literature, this newsletter, support conferences, and outside colleagues to explore alternative approaches. Consider assigning different team members to research and report back on them.
7. Design the workflow in a group setting. I find that the best method is to get the stakeholders in one room (preferably not virtual) and draw a simple workflow, step by step, of customers’ interactions with support. Each step has just one owner and there’s a clear demarcation between steps. Include routine situations where you need other groups, such as engineering. Don’t bother, at least during the first pass, with rare issues or escalation management. Don’t stop until you get to a resolution. Within a day, two at the most, especially if you withhold food and sleep (just kidding!), you will have a support workflow.
And here are some more around testing the fit of the model:
1. Minimize (staffed) input channels. Any input channel will need to be monitored and staffed so don’t let them proliferate. Kill email (my motto). And tread carefully when adding channels for logging cases. They will need to be staffed.
2. Minimize case handovers. Customers don’t like handovers and handovers are expensive, so get rid of them whenever you can during your workflow-definition session. Typical targets include: a dispatch team instead of a direct-to-engineer model, more than two tiers of support (even if you are using a tiered model), any manual routing effort, any routine authorization scheme.
3. Remember that big is beautiful. Every time you add an additional step or a specialized task you will need to have a team for that, and as you create more specialized teams you also create smaller teams. Small teams create lots of staffing and scheduling challenges – avoid them whenever possible.
4. Consider product exceptions. Some edge products may not work so well under the new-normal model. For instance, a legacy product, or a brand-new product may require very specific technical skills that are not needed for other products. You’ll need to balance the skills required with the scheduling complexity.
5. Consider product exceptions (again!). In general it makes sense to use the same model throughout the organization, but there are situations in which the best strategy is to mix and match, and that is when products are sold to different audiences. The core of support models for assisted support is tiered versus Touch and Hold. Touch and Hold is best when most issues require research. Tiered is best when most issues are known issues. For instance, if you are supporting a SaaS solution it’s often a good idea to go with tiered, so the easy questions can be taken care at level 1, leaving level 2 to concentrate on the hard ones. But if other products are on-premise solutions and those customers have created internal help desk that handles easy questions, you may lean towards a Touch and Hold model for them. Is it ok to mix and match? Yes, so long as the boundaries are clear and it makes sense from a customer’s perspective..
6. Allow regional exceptions, when absolutely required. How to handle regional exceptions is probably the most popular question I get about support models. Most are related to tea size. How many Italian speakers can you afford – and those two will need to know how many products? Assuming that you must provide support in multiple languages the ideal solution is to recruit multilingual speakers for smaller language requirements. The other dilemma for geographical differences is the issue of special customer requirements. For instance, you may be hearing from Apac country managers that customers expect onsite service, which is not provided elsewhere and would be very costly. This is where working with a global team of support managers will help. It’s easy for a remote manager to appear insensitive to local concerns but the task should be easier if the message is shaped and conveyed by local support managers. This is not to mean that there can never be regional exceptions. Keep them to a minimum, though, and position them more as a temporary fix for smaller regions.
You’re not done yet! Now you need to ensure that the organizational structure will support the model.
1. Staff to the model. If you are pushing for lots of self-service, who will take care of the web site and the knowledge base? If you are implementing a Touch and Hold model, who will serve as Backline resources? If you are moving from a dispatch model to a direct-to-engineer model, who will handle the non-technical questions that the dispatchers use to handle in addition to their call coordination function? No model, however perfect in theory, will work if the staffing is not aligned. (And yes, this is where you will feel pain if major changes are required.)
2. Adjust individual objectives. If everyone (in Frontline) is responsible for solving cases it makes sense that resolution time should be an important objective for everyone. If you want Backliners to proactively offer assistance they should probably be goaled on customer satisfaction for the teams they oversee rather than just the number of assists they provide. Make the objectives match the new goals.
Selecting the right support model is the most important decision you can make to meet your goals of customer satisfaction and cost containments, so it’s worth reviewing and tuning it on a regularly (yearly) basis.
For more information about support models, see The Art of Software Support.
FT Works in the News
Customer Management Insight re-published an article I wrote about selecting knowledge management tools, initially published in June, in its December newsletter, Selecting a Knowledge Management Tool for your Support Center
Third Tuesday Forum
Are you based in the San Francisco area (or will you be there on Tuesday January 18th)? That morning, David Kay and I will be hosting The Third Tuesday Forum, a roundtable for support executives. Our guest will be Joe Hines of Apple and we will discus communities and content creation — a hot topic!
To register or for more details, click here. Space is strictly limited to ensure an interactive session.
If you cannot make it this time but would like to be on the mailing list, sign up. You will be the first to know about new events. You can also join the Third Tuesday Forum groups on LinkedIn and Facebook.
ASP 10 Best Web Sites Competition
This year, I will once again serve as a judge for the ASP 10 Best Web Sites contest. Entering the contest is a great way to compare yourself to others and get some recognition if your site is amongst the 10 that win. You can see details of the program and enter at http://www.asponline.com/awards.html (see the top left-hand side of the screen).
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.