The FT Word – May 2012

By Technical Support

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

Topics for this month:

  • Innovation in support – practical suggestions

  • FT Works at the TSIA Spring conference in Santa Clara next week: the Winning Support Websites workshop, a metrics presentation, and a booth

  • An invitation to the upcoming Third Tuesday Forum on May 15thOperational Innovation

Innovation in Support

I just finished an interesting book by Eric Ries entitled The Lean Startup and I was struck by how many of the suggestions and ideas in it could be applied to support. I am afraid that, generally speaking,  support organizations are not a hotbed of innovation. We are too busy keeping up with customer demands to spend much time strategizing. And we know that it is risky to change the status quo: what if customers don’t like the new ideas? So we often shy away from innovation, and it keeps us back. I was inspired by this book, and I hope you can be too.

Here are some ideas from it. Note that the book does not claim to be entirely original and quotes many techniques and strategies that are referenced elsewhere, together with some unique ones.

Use a Build-Measure-Learn Loop

While we can strive to get it right the first time, often the only and best way to develop a new idea is to just try it out. Instead of pretending we can build the perfect offering, the perfect process, or the perfect implementation of a tool, why not build a test system on which metrics can be run so we can draw lessons from it (and go to a more successful second iteration)? The secret of success is to shorten the duration of the feedback loop so learning happens quickly.

Practical applications for support

When designing a new support offering, create a likely candidate and immediately market it to likely customer candidates. Do they react positively to the features that are included? Do they buy it?

If you want to change your escalation mechanism, test the alternative with a particular product team and see whether resolution time and customer satisfaction improve.

Genchi Gembutsu

Genchi gembutsu is a Japanese phrase from lean manufacturing that means “go and see for yourself” (I hope that’s what it means – my Japanese is weak!). The idea is that, regardless of how much good analysis can be done inside the company, there’s no substitute to going directly to customers and testing ideas directly.

Practical application for support: When designing a new support website, create A|B alternatives and test them side by side: which ones is most successful with users? Even the best website designers cannot anticipate every customer action – and good ones will indeed recommend direct user testing at critical points during the process.

Validate Leap-of-Faith Assumptions Early

Many business plans rely on assumptions: so many customers will try the product, so many will buy it. A critical discipline is validate the assumptions, as early as possible, so we can be sure that the model is viable.

Practical application for support:

When designing new support offerings, common assumptions include the initial attach rate (the likelihood that customers will purchase the offering together with the product) and the renewal rate (the likelihood that they will elect to continue with the offering at the end of the initial contract period). The attach rate can be tested very quickly. While you may need to wait a year to see about the renewal rate, you can at least ask customers 90 days into the contract whether the intend to renew.

If you think a new internal community would decrease troubleshooting assistance requests to engineering by a certain percentage, which in turn can be used to justify the expenditure for the technology, test the assumption in a specific product area.

Create a Minimum Viable Product (MVP)

If you want your feedback loop to be as fast as possible, you don’t have the luxury of creating and testing a fully featured product. Instead, create a basic product that allows you to test the hypotheses. Note that this will require extra work, in the sense that it must be designed for a customer test, not just an internal test, and you must be able to get reliable numbers from the test, which requires integrating metrics into the product.

Practical application for support: if you are testing internal communities, don’t worry about first obtaining the perfect tool and integrating it into the case-tracking system, although you will want to do that if the test is successful. Perform a test with a functional tool but without bothering with a full integration – and instrument it to measure adoption, participation, and resolution time.

Go Concierge First, then Automate

It’s fine for early adopters to get a lot of hand-holding. You are in testing mode and it’s fine to eschew scalability, for now. It’s fine to lose money on the experiment, as long as you are making progress on validating your product and your assumptions.

Practical application for support: when you are rolling out Knowledge-Centered Support, you may see a decrease in productivity while you train everyone on the technique and you (likely) create massive amounts of new content. But over time the support staff will get more skilled and you will see an inflexion point, as long as you can show that productivity is increasing as a result of the knowledge management work being done.

Use Actionable Metrics Rather than Vanity Metrics

This one is a little painful in support, because we’ve all boasted of our ever-increasing number of user signups for the support portal, for instance, or ever-increasing amount of page views But what does that mean, if the page views are just making customers more frustrated that they are not finding the information they need quickly, or the users never come back to the portal? Measure outcomes, not just activity; measure effectiveness (did the customer find what s/he wanted?) and repeat visits.

Part of making metrics actionable is making them simple: no one (really) knows that a page view means. But everyone throughout the company knows what a visit is.

Practical application for support: get rid of all asterisks and caveats in metrics definition so you can measure outcomes. If you are testing whether your new internal communities are reducing resolution time, don’t carve out the time “waiting on customer”. No one really knows what it means, least of all the customer, and it’s o so gamable…


The idea of a pivot is that, if your build-measure-learn loop shows that a particular idea just isn’t working, you should pivot and do something else. It’s hard to give up on an idea you like, but it must be done if customers don’t like it as you do! There are many flavours of pivots: zoom-in (focus on one feature), zoom-out (build more features), customer segment (go after a different segment than anticipated), customer need (change the product to fit the real need of the customer), and many more.

Practical application for support: you tried internal communities and they did not bring about the resolution time decrease you expected, but feedback from participants shows that they just loved the scheduled “expert times” that were organized at the tail end of the experiment, too late to have a big impact on resolution time. Sounds like a customer need pivot: the customers (support staff) want direct, scheduled access to experts rather than the communities.

Five Whys

This is another classic lean manufacturing technique: ask “why” five times to get to the root cause rather than staying with the first, often superficial answer.

Practical application for support: why did the customer escalate? Because they encountered an implementation-stopping bug during the last week of their testing cycle. Why was that? Because the bug was classified as P2 since it was not against a production environment. Why? Because we had no idea that they were going live in a week. Why? Because we have no account management function. Why? Because we assume that it’s done in Sales. Voila! An opportunity for collaborating with the sales team on a solution to accompany customers better throughout the implementation period.

I highly recommend reading the entire The Lean Startup book for more inspiration. For a practical guide to a strategic approach to support management, see Managing Support Strategically.

FT Works in the News

TSW in Santa Clara – May 7th through 9th (Sign up now!)

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. Come by and chat, please. I plan to be there on Monday 7th and Tuesday 8th.
  • I will present a pre-conference workshop on Monday 7th 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 Registration information below (you can register just for the workshop if you prefer).
  • I will have a joint presentation with Michael Helland of Autodesk on Tuesday 8th 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 at

You can register to TSW at a discount from the non-member rate by visiting and registering as ‘non-member partner referral’. Enter “FT Works” as the referring partner company and you can enjoy a special rate of $1,595, 40% off the regular price.

New Article about Support Websites

As a companion to the workshop on May 7th, I wrote an article entitled Support Websites: A Checklist, which was published by Inside Technology Services in the April 2012 issue. You can read it at

Third Tuesday Forum Lunch – May 15th

The next Third Tuesday Forum lunch is on May 15th and will feature Jeremy Largman of Atlassian. Jeremy will speak about Operational Innovation, sharing with us what Atlassian has done  to gain efficiency and better help their customers by questioning the conventional wisdom, taking advantage of insights from the social world, and rethinking their support operations from the customer in. (undoubtedly, many ideas from The Lean Startup were used – come and find out!)

We are again meeting at lunchtime, based on the success of the March meeting. You can read more here and register. Space is limited so we can bring you an interactive experience – guaranteed to be PowerPoint-free.

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.

Françoise Tourniaire
FT Works
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

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

Tagged under: