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 April 2012 edition of the FT Word. Feel free to forward it to your colleagues. (They can get their own subscription.)

Topics for this month:

Marketing support websites
Support SLAs – priorities and resolution commitments
FT Works at the TSIA Spring conference in Santa Clara: support website design, metrics fest, and a booth!

Marketing Support Websites

Thank you to Chris Woods for suggesting this topic.

How can we best market the support website? It’s tempting to jump straight to promotion ideas, but the first step is to make your website powerful and easy to use. A well-designed site will encourage first-time users to give it a try rather than to contact support as well as persuade returning users to go there first. (And a poorly-designed site may alienate users for the long term.) With that, here are 7 design ideas and 7 promotion ideas.

Design Ideas

Know your users. In most cases, you need to cater to users with different needs so identify your customer segments and create personas for them, which you can use to design and test the site so it matches their needs. The personas may match different product lines or different roles (e.g. administrators vs. end-users, new users versus legacy users, or enterprise users vs. SMB users). If you know your customers well you should have a good idea of how to segment them, but it’s always good to validate your guesses through a direct test.
Make sure the website is easy to find from the corporate site. Returning users may be capable of navigating to some secret location but isn’t it simpler for everyone to be able to locate the support site effortlessly? Don’t allow the links to the support website become invisible.
Be search-engine friendly. Many users expect to search for solutions from a search engineer outside your site. They should be able to retrieve relevant content – and since those users don’t necessarily enter through the front door their entry point should allow them to self-orient quickly.
Think tasks, not functionality. From the vendor’s perspective, we tend to think of support websites as a collection of functionality, from knowledge base search to case management functionality, to downloads, to communities. That’s not necessarily the way the users approach the site. They tend to think about tasks: troubleshooting, registering the product, getting a product repaired. Organize the website around tasks, relevant to each of your personas, naturally. For instance, getting troubleshooting information should allow users to retrieve information from the knowledge base, the community, and any troubleshooting wizard that exists.
Think tasks, not functionality. From the vendor’s perspective, we tend to think of support websites as a collection of functionality, from knowledge base search to case management functionality, to downloads, to communities. That’s not necessarily the way the users approach the site. They tend to think about tasks: troubleshooting, registering the product, getting a product repaired. Organize the website around tasks, relevant to each of your personas, naturally. For instance, getting troubleshooting information should allow users to retrieve information from the knowledge base, the community, and any troubleshooting wizard that exists.
Think tasks, not silos. You’re building the support website so there should only be support options there, right? Well, no, users don’t really care about the difference between support and repairs and training. Your org chart is probably organized in silos but customers don’t think that way: give them universal access to all the tasks they need to accomplish.
Don’t make them log in. Why put obstacles in front of self-service? Logging in is a chore. If you can dispense with it, all the better.
Don’t make them log in twice. If you must have a login (for instance to manage cases, since customers need some privacy for that), ensure that it works seamlessly with other logins on the site.

Promotion Ideas

Make sure the website is easy to find. Did I say that already? Let’s say it again: users won’t materialize if they have to jump through hoops to find the site.
Roll out the website as you would a new product. Why? Because it is, so it should get the same treatment: introductory webinar, a session as the User Conference, testimonials, whatever you are doing to promote products you can apply to the website
Reach out to the installed base. If you are rolling out a new, improved website, let your existing customers know. Unfortunately customers can have a long memory so don’t make a fuss if the website is only so-so – it will turn customers off and require arduous wooing back, even with future improvements.
Offer website tours. While good websites should be effortless to navigate, it’s also nice to show customers what they can achieve on the website. Webinars, live or recorded, are a great way to show off the various tasks that can be accomplished on the site (remember to organize the demo by task, not functionality alone!) For high-value customers, offer a personalized, 1-1 walk-through.
Enlist the support staff. If your customers are repeat users, the support staff can be the central force for promoting the website. Customers tend trust support reps, at least the good ones, because they are not selling anything – so they will listen to their recommendations. A heartfelt “you need to check our new community, it has all sorts of information you will find helpful” is more powerful than any other promotion you can run. The only hitch is that you’ve got to get the reps to believe in the website, both believe it’s helpful and well-designed and that it’s not a conspiracy to take their jobs away.
Run fun contests. This can apply to users and support reps. For instance, you can have a prize for a randomly-chosen new user, or someone who posts a helpful answer, or the most helpful answers in a week.
Keep it fresh. Remember the idea of treating the website as a product. Most products get regular new releases so do the same for the site, using the metrics you have been collecting all along (right?). And remember to keep the content fresh, too.

Who should drive the promotion of the support website? I like to see it as a joint Marketing/Support effort. The marketing folks have the know-how, but there’s usually little bandwidth so little bandwidth for support available for support-related initiatives. And if you have mostly repeat users the best way to promote the site is through interactions with the support staff, anyway.

Would you like to know more about designing and promoting support websites? Join me on May 7^th in Santa Clara for “Winning Support Websites: From Assessment to Customer Love”. You can find a description here and register here (use “non-member partner referral’ as the registration type).

Support SLAs

Many thanks to Madhu Bajpai and John Powers for suggesting related questions about this topic.

Support service-level agreements (SLAs) often rely on priority (or severity, there is no set terminology in this area) to set the timing for response time commitments, and sometimes resolution commitments as well.

Is it helpful to define SLAs by priority?

Sometimes. The idea behind priorities is that some issues are more urgent than others so setting a priority allows customers to prioritize their issues – and the vendor to organize the work more efficiency.

How many levels of priority do we need??

Before you happily embark on defining multiple priority levels, stop and think: do you need priorities at all? If most issues coming in are how-to questions, priorities may not be needed. And if you do, don’t define multiple levels just because you can. Most support organizations can do well with just two levels: emergencies and everything else. Remember that you are not trying to reproduce the severity ladder used for bugs, but rather to model your support process around the various levels. It’s hard to think of any support organization that truly needs and uses more than three levels productively.

Can we define priorities absolutely precisely?

No, but it doesn’t mean that you should not try. For instance, if you define priority “1” as “system down”, that should help you define the boundaries with other issues. But in this situation how do you work with the customer who estimate that the system is down if severe performance issues are preventing users from doing any work. My preference is to define priorities in terms of customer goals (for instance, emergencies versus not) so you don’t have to engage in unproductive discussions with customers. The vast majority of customers will not take advantage of customer-centric priorities so don’t be afraid of them.

Are priorities forever?

It’s perfectly fine to adjust the priority of cases over time, but should you? If priorities essentially define response time (urgency), then their job is done once the initial response is made. If they are associated with other deliverables then it makes sense to adjust them, up or down, over the life of a case, but I’m always leery of compulsive readjustments of case priority: just work the case, and work it quickly, rather than worry about the perfect priority level.

Case priorities often dictate the priority of the issue once it becomes a bug but it makes more sense to define a separate severity for a bug. It’s absolutely possible to have a P1 case (highest priority) that completely impedes the customer’s ability to conduct business receive a good workaround so that it is associated to a low-priority bug. Decouple the two systems.

What does response time mean?

Response time commitments define the targets for the initial response to customers. For instance, you can commit to respond to emergencies within one hour and everything else within one business day (note that in this example non-emergencies are not worked at night and on holidays). This means that you will have a skilled support rep engaged in the resolution process within that timeframe, not that a resolution will be reached.

Are update commitments helpful?

For issues that will take multiple days to resolve, it looks like it would be a great idea to have update commitments. So for instance, we will give you daily statuses for P1 issues. But meeting update commitments can quickly turn into games, with reps firing off the obligatory emails to customers but without putting any thought into them. I must prefer to train reps to set clear commitments for each step, and meet them.

How about resolution time commitments?

It’s perfectly fine to offer resolution commitments if you are committing to sending a replacement part. But making resolution time commitments for troubleshooting tasks is a terrible idea since some problems are just very complex, and a few may never get to a resolution. It is an excellent idea to have an internal target for resolution time but when customers push for resolution time commitments, try the following:

Explain why a resolution commitment is unwise (because software problems can be intractable or unfixable).
Suggest an escalation mechanism instead. This takes care of the “black hole” problem, which is what most customers are concerned about. Customers who are able to escalate upwards (for serious problems) become less interested in guarantees.
Focus on mitigation rather than full fixes. Often a code fix would take weeks, or be entirely impossible, but a workaround would get the customer back on track. I’m seeing more instances of “temporary fix resolution” or “relief” commitments with my clients.
Focus on high-severity issues. It makes little sense to commit to fixes on low-level issues, and it creates a tracking nightmare.
Propose targets rather than a 100% guarantee. Since we know that most issues can get to a swift resolution but some issues simply cannot, despite our best effort, you can consider giving a 90% guarantee that you will offer a resolution in 24 hours (say). That way, you have the leeway to handle those extraordinary problems that cannot be fixed quickly and still be within the contract range.
Negotiate directly with the business unit manager. Buyers can be inflexible and dogmatic about guarantees. If you can speak with the business unit manager you can create a trust relationship and that may matter more than the contract itself.

Can I set Engineering commitments?

Absolutely, both for response and resolution time, although both will remain internal. It’s very helpful to distinguish between requests for fixes and requests for troubleshooting help on the one hand, and emergencies versus others.

For more details on defining SLAs, see Selling Value

FT Works in the News

Next Month: Will you attend TSW in Santa Clara?

FT Works will have three events at the upcoming TSIA conference on May 7-9th. Hope you can join us!

We will have a booth in the expo hall
I will present a pre-conference workshop on Monday 7^th entitled “Winning Support Websites: From Assessment to Customer Love”. If you’ve always wondered why your website doesn’t work as well as you’d like, join me. John Ragsdale has a nice write-up about the workshop here http://jragsdale.wordpress.com/?mtcCampaign=-1&mtcEmail=12149681. Registration information below (you can register just for the workshop if you prefer).
I will have a joint presentation with Scott Sieper of Autodesk on Tuesday 8^th at 9:45am entitled Measure Twice: Cut the Useless Metrics in which we will present a comprehensive support dashboard.

The details of the schedule can be found here.

And you can register to TSW at a discount from the non-member rate by clicking here and registering as a ‘non-member partner referral’.

New Article about Metrics

Foreshadowing the presentation in May, I wrote an article for the Call Center Insider entitled Expert’s Angle: Less is More (Better): Building Fewer and Smarter Metrics. Read it here.

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

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.

Subscription Information

To request a subscription, please drop us a note. The mailing list is confidential and is never shared with anyone, for any reason. To unsubscribe, click here.

Back to Newsletter Archive