Surveys are top of mind for me right now.  We’re in the middle of a couple of survey projects, and surveys inevitably come up whenever we talk about loyalty, satisfaction, and self-service effectiveness.  Doing customer service and support surveys is a topic that deserves its own book—as a matter of fact, it already has its own book, by Dr. Fred Van Bennekom, which I strongly recommend.

In this blog post, let me share just a few points that I think every customer service and support professional should know.

Keep relationship and transactional surveys separate.  Fundamentally, there are two different kinds of customer surveys with very different purposes.  Relationship surveys are taken by specific customers on a periodic basis, generally once a year, and seek to understand their overall perception of a company, its products, and services.  (For a B2B business, the customers are generally the economic decisionmakers or key purchase influencers, not everyone in the company.) The survey is often managed by Marketing, although we’d prefer that the Services organization drove it.  It’s about the company relationship as a whole, not one person, issue, or event.  It’s where you get to ask the big-picture questions: do you trust this company? Is it responsive and easy to do business with?  Would you recommend this company to a friend or business colleague? (This is the Net Promoter Score “ultimate question.”)

Transactional surveys are about a single interaction, full stop.  They need to be extremely quick and easy, and only ask questions about the interaction.  It’s not fair to ask about the company overall, or to try to calculate a Net Promoter Score.  The person who had the interaction gets the survey, whether or not she is the ultimate decision maker.  You should throttle transactional surveys so people don’t get hit too frequently, but once a quarter or twice a year is generally OK.

Transactional surveys let you know about your customer’s experience; relationship surveys let you know about your customer’s perceptions and intentions.  Both are important, but don’t mix them up.

Take a stand against bias. “Bias” is survey jargon for the degree to which a survey’s answers don’t accurately represent the answers you’d get from all possible customers.  There are many causes of bias—asking only web users or people who call you, for example, because they may not represent your customers as a whole.  Or, bias can come from simply not asking enough people.  But for most service organizations, the real danger is non-response bias—that is, the fact that the only people who take your surveys are the ones who really care, generally because they’re applauding…or apoplectic.  The silent majority isn’t counted.

Non-response bias is a particular concern for “did this article help you” questions at the bottom of knowledgebase articles.  In our experience, these usually get 0.2% to 2.0% response rates, and it’s easy to see that the other 99%, give or take, may be pretty different from their more opinionated brethren.  Don’t extrapolate from the people who answer you.

Test your surveys. Just as you’d test software or a new web site, you need to test survey instruments before you roll them out.  We’ve asked questions that were clear as the azure sky to us, and resulted in a “huh?” from customers…or, “well maybe you mean this, but maybe you mean that.”  It’s best to fix this before you launch.

Consider picking up the phone. I know, I know—this Internet thing is going to take off.  And we use web surveys all the time.  But there’s just no substitute for actually talking with customers, asking not only the scripted questions but open ended ones, too.  I think as an industry we don’t do nearly enough of this, and a “customer success on the web” survey is a great excuse to do it.  Here’s a simple script:

• Thinking about the last time you came to our site, and thinking about the reason you came there, were you successful in accomplishing your goal?
• (If yes) If you hadn’t been successful, are you entitled to open a case with us, and would you have done so?
• (If no) Did you eventually open a case with us for that same reason?
• Is there anything else you’d like to tell us about your self-service experience with us?

For more on using surveys as part of estimating contact deflection, see Simple Techniques for Estimating Contact Deflection.

Ask fewer questions, and never ask if you’re not going to do something about it. Tell people you’re doing a survey, and it’s like you’re giving away free cookies or something—everyone has their hand in the jar.  “Ask about the website.”  “Ask about our RMA policy.”  “Ask if they liked the hold music.”

Resist.

I’d like a transactional survey to be no more than three questions, and fit easily on one page.  One question would be better.  Five questions and you’re pushing your luck with me; show me seven questions and two pages, I’m outta here.  Unless I’m really cranky, in which case I’ll respond but you won’t like it.  Long transactional surveys make for low response rates and high bias.

Get only what you need.  And if you think the answer is interesting, but not something you’re going to do something about—for example, if you’d like to know how people feel about your ending support for a product, but you’re going to end of support it no matter what?  Don’t ask the question.  Customers want to know that what they’re telling you matters—that you’ll actually take action based on what they say.

What “aha” moments have you had in doing your surveys?  Please share in the comments below.

<shameless commerce> There are still slots available at the One Day Introduction to KCS immediately following TSW in Santa Clara, May 10.  Our KCS Foundations Workshop in Plano is sold out, but we have openings in the Bay Area Foundations Workshop in July. </shameless commerce>

Source photo credit: iStockphoto

At a recent Consortium for Service Innovation team meeting, Adam Strong of Red Hat said something that really resonated with me:  “KCS is a whiteboard.”  I knew at once what he meant—and it’s a really powerful way of thinking and talking about KCS.

I don’t know about you, but there are few things in life as motivating as a clean whiteboard with a set of colored pens beneath, and maybe a pack of big sticky notes nearby.  When I visit a company with lots of whiteboard space, I’m pretty sure we’ll get along well.  There’s a sense of possibility about the big, blank expanse of board—a friendly challenge, an invitation to think up something interesting and capture it in a way that it can be communicated with others.

Perhaps the only thing more motivating than a clean whiteboard is one that’s in a room with other people who have ideas they want to share, too, with half-formed thoughts taking shape on the board as you collaborate in search of a shared vision, an vision too big and too diverse for any of you to have found on your own.

The eraser is really important.  Whiteboards invite fearlessness, because it’s almost as much fun to erase and start over as it is to write on the board in the first place.

The lack of finesse is really important, too.  Whiteboard drawings aren’t polished, keeping the focus on the ideas, not the beauty of their representation.  Even the rough draft of this blog post I’m writing in Word now looks way too finished, with good kerning and a smooth left margin.  If I didn’t know better, I’d think I were finished.  Whiteboards never let you imagine you’re done.

So, I think Adam’s right: KCS is like a whiteboard.

• KCS spurs creativity.  The article structure sets the boundaries, but there’s limitless white space inside.  If a customer asks you to solve a new problem, a knowledge article inspires you to unleash your creativity to solve it—maybe quickly, and maybe through a long journey of discovery.  When you’ve solved the issue, the knowledge you acquired is up on the “knowledgebase whiteboard,” ready to share with others.
• KCS invites collaboration.  From informal discussions over a cubicle wall to war rooms convened to resolve critical customer issues, it’s critical that the work of the group is captured in articles as the discussion unfolds:  collaboration is creation.  I look forward to the day when all KM tools support Google Docs-style real-time collaborative editing.
• KCS makes revisions natural.  Knowledge is never done: in KCS, every use of an article is an opportunity to improve it, and make it more comprehensive.  Just as we erase a word or shape on the whiteboard, and replace it with something more fitting, KCS encourages us to keep making articles, especially frequently used articles, ever better.
• KCS emphasizes ideas over formatting. KCS articles aren’t like the brand-designed, tightly edited webpages that Marketing produces.  But ask a customer if she wants glamour or a quick, accurate answer to her question, and the answer wins every time.  The fact that KCS articles are spare and simple means they’re easy to extend and improve.

The only problem with whiteboards is, it’s tough to work with the information after the fact.  (I should know: I have a smartphone full of pictures of whiteboards.)  So if you see your customer-facing staff having an animated discussion around a whiteboard, encourage them to continue—and remind them that their good work deserves a better future than can be provided by a “Do Not Erase” sign.

-30-

BTW, our Plano KCS Foundations workshop in April is nearly sold out—please sign up soon if you’re joining us.  And we’re confirmed for the post-conference one day KCS workshop after TSW in Santa Clara—a perfect way to introduce a colleague (or yourself!) to the what, how, and why of KCS.

Effective, persistent communication is the cornerstone of KCS.  Team members need to be engaged emotionally—to feel like they’re part of a big, important quest—and practically—knowing exactly what they need to do.

Rather than saying anything more about this, I’m going get out of the way and let one of our customers show you.  Having participated in end-user training to kick off Wave I of a brand new KCS initiative, I was delighted to be cc:d on this fabulous email that program manager Joe Young of Intuit’s Virtual HR team sent to the new KCS candidates.  My notes follow.

Congratulations!  We have launched KCS for Intuit HR with an initial wave of nineteen participants.  That’s pretty amazing to me.  Just imagine how quickly we will be able build a central repository of shared knowledge with that many really knowledgeable people. (1)

KCS Mantras

• Tight Focus on Specific Question
 This will be hard for many of us.  (2) KCS is not about writing articles that detail many variations.  The focus is on that one question from that one person.  If you did not include a detail in the chat, phone, or case, it does not belong in the article.
• Good Enough
 Perfection is the enemy of the good.  Don’t dither and don’t agonize over the “right” wording.  Get the essence of the issue into an article, save it, and move on. (3)
• Create Articles “In the Moment”
 When creating new articles, customer context is key.  Use the words that the customer used in describing the issue.  Don’t “improve” the wording.  And don’t wait until you “have time to write.”  You will lose that customer framing.
• UFFA
 Mindset shift.  On every question that you get, walk through these steps:

• Use It: Search for an article that addresses the question in [our tool] (4).  If it exists, use the information.  Capture the ID and paste in into the [incident tracking system] case.
• Flag It / Fix It: If the article you find could be improved, Flag it for improvements (Candidates) or edit it directly (Contributors).
• Add It: If you determine after searching that no article exists that answers this specific question, write one using [our authoring environment](4).  Do it now, even if people are waiting on the phones or chat.  Senior leadership (copied on this email) understands that our service levels will dip as we populate this new resource.  The benefits we derive will pay back a hundred-fold. (5)

Training Materials for HR KCS

I had a request in the last training session to provide the decks we used for the online training.  I almost attached to this email, and then realized that a better way to model the new behavior we want to see would be to post these files in our repository.

I have created an article that contains two training decks and the current version of the Content Guidelines.  I am sure everyone on this email will have no trouble locating it. (6)

Job Aid

I have laminated versions of the Quick Reference sheet.  It’s the first two pages of the Guideline document, two-sided.  If you would like a copy to have at your workstation, let me know how to get it to you. (7)

Coaching Assignments

Expect to be contacted by your assigned KCS coach shortly, if this has not already happened. (8) [T]eam members should expect to spend an hour a week with their coach through the Candidate process.  [People taking escalations in] the first wave will likely have more customized arrangements based on their situations.  Look for further communication.(9) [List of coach assignments followed.]

David’s notes:

1. What a clear, compelling vision—who doesn’t want to be part of that?
2. It’s OK to acknowledge that we’re building new skills, and that it can be hard.  This “sufficient to solve” guidance for Solve Loop content is, ironically, often hardest for your best and most thoughtful team members.
3. In its crispness, this paragraph models KCS style at its finest
4. In the original, this was an actual link to the appropriate tool.  Nice.
5. When leadership acknowledges that they’re willing to take a short-term productivity hit, they rarely actually have to
6. It seems like a little bit of a trick, but putting information people want into the knowledgebase really is a good ice breaker.
7. Simple, helpful laminated cards with the quick reference guide are both useful and a tangible reminder of the program.  This is especially useful for a highly distributed or homesourced group.
8. Often, after training, I feel like participants are still somehow waiting for permission to start doing KCS.  Taking the practical step of setting up the first coach meeting often supplies the needed incentive to start.
9. No one communication, even one as good as this, does the job on its own.  This message closes with a reminder to all of us that communication is the job that never ends in a KCS program.

ps – Know someone who is coming to TSW in Santa Clara?  We’re running our popular one-day Introduction to KCS the day following, May 10^th, at the TSW site.  Enjoy another day in California: send a colleague, or come join us yourself!

We all hate our knowledgebase tools sometimes.  We might like the people we work with at the vendor, and there are those really cool features, but…seriously?  I can’t just get a list of all the articles Joe has written?  I can’t use bullets without ruining the formatting?  I have to hit “publish” three times after I’m finished with the article?  It makes you tear your hair out, and you sometimes get the impression vendors have no idea how their products are used in the real world.

As a knowledge program manager, every time you meet with a KCS coach, or sit down with a staff member, you get both barrels about the technology.  “Search doesn’t work—why can’t it be like Google?”  “It’s too cumbersome to author in the workflow.”  “It takes a half hour to create a KB article even after you’ve captured the information in the case.”

It’s easy for consultants, industry pundits, and even program managers to say it shouldn’t matter that much—that many knowledge programs have succeeded with technology that’s no better, or even worse.  It may be true, but it’s not very helpful to say to a complaining colleague.

Based on some recent experience with customers, I’d suggest a different approach.  Tell your team to hack their knowledgebase.

No, I don’t mean hack in a bad way.  I mean hack, like, figure out how to make it their own.  Come up with new clever ways of using the system.  Devise workarounds.  Write a script.  Show off, and have some fun!  You have smart people in your organization…maybe all they need to use the tool better is permission, and encouragement?

As program managers, we helped implement the tool, and we built the training content, so we come to think of ourselves as the experts.  But we’re not, really, at least, not compared with the people who use it every day.  Here are some things I’ve seen end-users figure out, all within the last three weeks:

• How to use a “hotkey text” feature to automatically paste a template into a new article (a workaround discovered by two different users in two different systems)
• How to eliminate rich text formatting problems by slightly changing the content standard
• Metadata entry that can be skipped, because no one ever looks at it
• How to generate “reports” that aren’t available in the reporting system by cleverly using an administrative interface
• How to keep a shared stash of article IDs to link for common issues

These MacGyver moves all came about because users were frustrated with the tool, and rather than complaining, they rolled up their sleeves and did something about it.  As a program manager, you’re not always in a position to figure this stuff out.  But you can prod and encourage would-be hackers, recognize their contributions to the program, and most importantly, make sure that everyone on the whole team knows when a colleague has come up with a better way to do things.

2011 Takes the Checkered Flag. Photo credit: iStockphoto

I was going to do a “New Year’s Resolutions for Knowledge Program Managers” blog post, but really, it’s the Tuesday after New Years.  Who wants to be nagged?  So I decided to highlight some of the things that we think are new and notable in the world of KCS and KM.

1. KCS practitioners get industry certification.  Industry certification had been a gap in KCS for many years.  Sure, certification is a part of the KCS practices, but that’s in-house certification, which doesn’t have the same credibility as industry certification.The for-profit arm of the Consortium for Service Innovation has set up a rigorous process by which support practitioners participating in KCS for six months can receive KCS Publisher certification.  Like other serious industry certifications, it’s a big deal: it requires a demonstrated commitment to the practices, and the test is pretty tough.  (Full disclosure:  Jenn on our team contributed to the questions.)From our perspective, it’s about time that KCS practitioners have something to put on their LinkedIn profiles that tells the world they’re proficient at capturing, structuring, reusing, and improving knowledge in the service delivery workflow.  And we think it’s great that program managers have a new tool to motivate and evaluate progress.

   We think this is so useful, we’re building certification in to our customer engagements…and we’re working with the CSI on the next round of certifications, too.  Please comment below if you have thoughts or suggestions, and let us know if you have questions.

2. Social gets rational.  Last holiday season, it seemed like all the Facebook pages were hung by the stockings with care, and visions of tweets were dancing in people’s heads.  Fortunately, the sugarplum rush seems to have passed and support leaders have settled into a more balanced approach to social.Yes, social support continues to be important (and it always was, of course; it’s just that you have better visibility to it now with new technology.) But most organizations have stopped incenting customers to complainin public by providing better service.  And most organizations realize that social isn’t just another channel.The social tulip mania we experienced for a while was a good reminder that most of the support that happens doesn’t happen in the support center.  It was a good reminder that customers are talking, and that we now have new ways of listening to and engaging with them.  And it paved the way for a more rational strategic approach to social, one that will continue to build on successful support communities and the knowledgebase.
3. KCS has officially “crossed the chasm” in support.  Next stop?  The enterprise.  Go to an industry event and ask how many people are doing KCS, and watch the hands fly up.  (How closely they’re following KCS practices is another story, but for now, we’ll say perception is reality.) As thought leaders, we miss the early adopter cachet, but as pragmatists, we don’t miss the hypothetical objections about why KCS can’t possibly work.If support has crossed the chasm, it’s time for a new bowling pin, and fortunately, we have a whole lane set up: the rest of the enterprise.  We’re seeing major KCS adoption in professional services, field services, sales, and HR, among others.  We expect that much of our business in the coming years will be helping to migrate and adapt successful KCS practices from support to the rest of the enterprise, accounting for the fact that measures, workflows, and organizational personalities are very different.

What are you seeing?  Please leave a comment and let us know.

ps – consider starting 2012 with a jumpstart in KCS.  We’re offering the KCS Foundations Workshop on February 1-3 in the Silicon Valley / San Francisco area.  Register or find out more, and contact us for discounts for multiple attendees.

“KCS seems like a good idea…unfortunately, our people don’t have the writing skills to create knowledgebase content.”

“You know, English isn’t the first language for many of our people.”

“Maybe in the future, we’ll hire people who know how to write.  As of now, we’re stuck with the people we have.”

We hear variations on this theme over and over again.  Sure, capturing, structuring, and improving knowledge in the course of resolving customer issues is a good idea, but the current crop of agents wasn’t hired to be technical writers, so of course they’re not up to the task of knowledge capture.  KCS will have to be restricted to a small number of the most literate staff…or it’ll just have to wait.

This would be a depressing refrain if it were true.  Fortunately, it isn’t.

We’ve worked with teams of all kinds: technicians nearing retirement; native speakers of German, Italian, French, Swedish, Mandarin, Japanese, and Hindi; temporary staff; übernerds; and former truck mechanics.  None of them thought of themselves as skilled writers, yet all of them ended up creating value in the knowledgebase.  So where’s the disconnect?

I think it’s a misunderstanding of the job.  See, KCS isn’t about writing.  It’s about communicating in words, using a structured format.  And that’s a much easier task.

Writers have it tough.  They start with a blank sheet of paper and a blinking cursor (or a tapping pencil.)  Good writers use all kind of techniques to tame the featureless, empty page—tools such as outlines, the inverted pyramid, and stacks of 3×5 cards.

People doing KCS are filling in a template.  That’s much easier.

Writers have to deal with all the conventions of prose style:  paragraphs and topic sentences, for example.  They are told to stick to active verbs, and use a mix of sentence structures—simple, complex, compound, and complex-compound.  (You do remember your complex-compound sentence structure, don’t you?  I thought so.)  Split infinitives, dangling participles, and terminal prepositions are all no-nos.  Subjunctives and the serial comma are all topics for serious discussion.  No wonder we don’t expect our agents to be writers!

People doing KCS don’t have to worry about that.  Their model is Sgt. Joe Friday from Dragnet:  “just the facts, ma’am.”  Write down the customer symptoms.  (“Green LED flashes during Power On Self Test.”  “Gears grind when shifting into third.”  “Application exits abnormally after writing ‘Warning: type mismatch’ to the system log”).  Write down the environment.  Write down the resolution as a series of steps.  They had to say all this to the customer anyhow, either live or in an email; they’re just writing the same information down in the right section of the knowledgebase.

See the difference?  They’re communicating in words.  It’s much easier than writing.

I guarantee that if you have someone who can effectively answer questions and communicate resolutions to your customers, they can do the same thing in a knowledgebase article.  It may not be completely easy and natural; in fact, it may take some work, some coaching, and some focused practice.  Even after time, there might be the occasional misspelling or odd phrasing.  That’s OK; your customers judge you by your answers more than your literary talent.  The important thing is that they’re contributing to the collective experience of the team.

This is good news for your KCS program.  You don’t have to wait for a new workforce to launch, and you can benefit from anyone who has knowledge to contribute.

But perhaps more importantly, this is good news for your staff.  Their eighth-grade teachers might have convinced them that they’d never make a living by writing, and they may believe that to this day.  But with encouragement and good coaching, they can write—OK, communicate in words—in knowledgebase articles that can help hundreds or thousands of colleagues and customers.  That’s pretty heady stuff.

Write on.

Photo credit: iStockphoto.com

If I had a nickel for every time I quoted the KCS practices guide and asserted that knowledge is an asset…I’d have a lot of nickels.  I say it because it’s important to remind people that knowledge work isn’t just something “nice to do” if we get around to it.  Knowledge is central to the work of the service and support organization—and, to most of the other knowledge-intensive functions in the organization like development engineering, sales, product management, and HR.

So is it time to capitalize the knowledgebase?  (I know accounting probably isn’t your favorite topic, but please bear with me—this could be important.)

When we talk of knowledge as an asset, we’re generally speaking metaphorically.  Knowledge is a productivity enhancer, just like a lathe in a machine shop.  It costs money up front, but makes it faster, easier, and cheaper to do work over its lifetime.  A lathe should have positive ROI—that is, it should save more money over its lifetime (and ideally, over its first year or two) than it costs.  Knowledge should be the same way—it should generate more value that it costs to produce, maintain, and deliver.

Enterprises know how to account for lathes, and buildings, and mainframes, and other physical items that return value over years of use.  Accountants treat them as a capital expense, and depreciate them on the balance sheet throughout their usable life.  This isn’t accounting trickery; accountants are required to match the expense (the depreciation) with the same time period as the benefit.  And it’s not just tangible goods that should be treated this way: for example, home-built software that runs a web store can be capitalized just the same way a brick-and-mortar store can be.

So, are we serious about “knowledge is an asset?”  Should we fund knowledge development out of the capital budget?

I’m not an accountant, so I’m not going to weigh in on the GAAP aspects of this—I hope more knowledgeable people will in the comments.  I know some smart companies are at least looking in to it.

I am very interested in what this might mean for our knowledge programs:

• If we can move some portion of funding for knowledge development to a capital expense budget, can we make ourselves less susceptible to capricious budget cuts?

• For companies moving from licensed knowledgebase software (capital expense) to SaaS (operational expense), does this move free up capex budget for the knowledge asset?

• Is it easier to convey the value of knowledge if we capitalize it?  Or do we risk undermining the core KCS message that knowledge is a byproduct of solving problems?  (Maybe if we just focus on capitalizing Evolve Loop content?)

Anyhow, at this stage, I certainly have more questions than answers.  But I’ve always thought it a little bit backwards that we capitalize the knowledgebase tool, but not the knowledge itself.  Maybe it’s time to set it straight.

ps – a programming note: we’ve been very remiss about contributing to this blog.  As many of our support clients tell us, “this job would be perfect if it weren’t for all the customers.”  We’ll be back to our regular every-other-week or so schedule now.

Starting with KCS v3.0 in 2003 and continuing today with KCS 5.0, we’ve made tremendous progress in documenting a body of practical advice for KCS adopters.  But sometimes specific advice isn’t enough to cover the interesting situations our clients find themselves in: being an insurance company with content regulated by all 50 United States, for example, or hiring a new temporary workforce every year.  At times like this, it’s important to seek guidance and inspiration from the principles.

Photo credit: iStockphoto.com

Here’s my take on the ten big ideas behind KCS:

1. No incremental effort:  it’s done in the workflow.  The most fundamental principle is that “KCS isn’t something we do in addition to solving problems; it becomes the way we solve problems.”  It’s fundamental, but still uncommon.  Technology often gets in the way.  And, sometimes individuals don’t really force themselves do capture, structure, reuse, and improve knowledge during the case.  In the workflow is a little like touch typing, in that it’s pretty tempting to cheat while you’re learning, but if you take the time to really learn, the long-term benefit is tremendous.
2. Structure: let go of the words.  Technical writing isn’t the goal; the goal is streamlined, simplified, and structured facts and actions.  We want less Homer and more haiku, less James Joyce and more Sergeant Friday:  “just the facts, ma’am.”  Don’t tolerate brain dumps, and encourage those who don’t think they’re writers.  KCS doesn’t want writing; it wants people to communicate with words.  That’s a big difference.
3. Learn with every case.  What a loss it is if the only thing we’ve done when we close a case is to help that single customer!  If we’re capturing, improving, and reusing all the time, we’re continuously learning, helping us help future customers, too.  As a support engineer once proudly told me, “I’m solving customer problems while I sleep!”
4. Make tools support the process.  This seems obvious, but when you have an enormous IT project that’s behind schedule (and aren’t they all?), they may not want to hear that their publication workflow doesn’t support KCS practices. Get in front of the technology implementation; be agile, delivering the most value and exposing the most risk early on; and make sure that KCS isn’t a slave to poor technology decisions.
5. Invest based on demand.  Capture everything, but promote and improve selectively.  Some early KCS advocates made you feel like you were doing something wrong if you worked on knowledge outside of the workflow; modern implementations take a more balanced approach and recommend that resolution flows, videos, process wizards, self-healing tools, and other value-added (“Evolve loop”) content be developed when capture-in-the-workflow (“Solve loop”) content goes viral.
6. Certify based on proficiency.  If you don’t have a real certification program with teeth, how can you be confident your users will all do a good job?  Certification should be hard to achieve, and it should require sustained good performance to keep.
7. Use coaches for change.  Peer coaching is an essential enabler of KCS, and if you don’t have an effective coaching program, it’s unlikely you have a strong certification program, and it’s unlikely people are capturing in the workflow.  Training without coaching isn’t sufficient.
8. Share the measures.  As we recently posted, we all want to know how we’re doing.  Take advantage of this human desire to drive performance.
9. Track, trend, and analyze activities.  This is a positive way of saying not to put goals or quotas on activities.  This doesn’t contradict the previous principle about sharing measures, by the way:  share the data, but make sure everyone understands how you’re using it, and that activity isn’t the same as quality or value.
10. It’s a program, not a project.  There’s no end date.

We’ve been involved in some out-there KCS implementations, and of course no two are alike.  But every effective KCS implementation I’m aware of has implemented all ten of these big ideas in some way or another.

How about your KCS program?

ps – Coming to TSW in Vegas?  Consider joining our workshop there, or in Chicago in October.

When we look at communities, we simplify matters by cutting things down to six measures—three activities, and three outcomes.  Activities, and trends in activities, will tell us if the community is healthy.  The outcomes let us know if they’re effective—or, more precisely, part of an effective eSupport strategy.

Activities:  Monitoring Community Health

Activity measures tell us if the things we’re planning on are happening.  Good activity measures don’t guarantee success, but poor measures are a good indicator that something’s wrong.  (A cocktail party with 30 guests isn’t necessarily a good party, but one with only three guests is likely to be a bust.)  Community activity measures tell us if people are participating in the conversations.  If enough people are participating, that suggests they’re finding it valuable.

• Page views.  We’re still not sure whether a tree falling in a forest makes any noise, but it’s a sure bet that a post that isn’t seen isn’t doing any good.  More page views equals more opportunities for value creation.  This is important to trend over time.  It’s also interesting to see where the page views are coming from—your community site?  Self-service search?  Google and other Internet search engines?  This can help you refine your marketing strategy, and perhaps help you fend off those colleagues who want to lock your community behind a paywall.

• Active contributors.  How many people are not only registered and looking, but actively participating in a discussion (either starting a thread or following up) within the last thirty days?  In the standard 90/9/1 model of community engagement, this measures the nominal 9%—although in the real world, the number is often significantly less than 9%.  Trends are as important as the actual numbers for this measure.

• Posts per day by forum.  This is what communities researcher Dr. Michael Wu refers to as “liveliness”—is there a good buzz?  Are we at critical mass?  For a specific forum, it takes at least five posts a day to be lively; those with fewer might best be merged with other forums until the topic attains sufficient momentum.

Outcomes:  Gauging Community Effectiveness

Outcomes are the business results we are seeking from our community initiatives…and in fact, from all our eSupport initiatives.  If the activities tell us the “what,” outcomes tell us the “so what.”

A challenge with outcome measures is that no one activity can “take credit” for the outcome.  This is frustrating when trying to justify investment in a specific program, but it makes sense:  wouldn’t it be odd if a self-service program and a communities program were trying to accomplish different outcomes?  Shared goals encourage teamwork, and are a fact of life in the enterprise—no one group gets credit for company profitability, either (not that Sales won’t try.)

If teasing the value created by communities apart from other efforts becomes a paramount consideration, the activity measures at least provide a rough order-of-magnitude starting point.  If there are 100 times as many community interactions as there are live chats, it’s reasonable to argue that the community program is a more significant driver of Net Promoter Score, while if there are ten times as many page views in the knowledgebase than in communities, the knowledgebase might be making a bigger impact.

• Deflection.  The most easily quantified financial benefit from communities is contact (or case) deflection.  Deflection in communities is measured just like deflection in self-service:  it’s the percentage of people who are successful in accomplishing their goal, times the percentage entitled and intending to open a case, times the number of times people use the communities to resolve an issue.  That is, Deflection = Success Rate x Escalation Rate x Sessions.  While calculating success and escalation rate are worthy of a paper all their own, the quick answer is that you should call your community users and ask them about their last experience—were they successful?  Did they / would they have escalated?  Verb. sap.: escalation rates are lower—often far lower—than people assume.Note that communities deflect contacts by having a customer ask a question and get a helpful response.  But it’s far more common that a third party—a “lurker”—comes along later, sees the exchange, and uses it to solve his or her problem.  Accordingly, if community posts are returned by self-service search or by Google, it makes sense to calculate a blended deflection number across communities and self-service.

• Satisfied demand for support.  Support is in the business of creating value for customers, not just closing and deflecting cases.  So every successful interaction in the communities provides value.  It’s hard to assign a dollar value to satisfying a customer’s need, but that doesn’t make it less real.  Satisfied Demand = Success Rate x Sessions.  As with deflections, this may be a combined number across self-service and communities.

• Loyalty.  However you measure loyalty—typically Net Promoter Score, Renewal Rate, or Repurchase Rate—communities should affect this positively.  Look for changes in loyalty especially when community activity measures have changed significantly within a given time period.

Six measures, two slides…and a very telling picture of just how your communities are going.

(Thanks to the Association of Support Professionals, who kindly let me repurpose this piece from a contribution I made to their excellent report Successful Support Communities.)

ps – to our KCS friends who aren’t out on the coasts, sorry if it seems like we’ve been ignoring you!  DB Kay has a KCS Workshop coming up October 5-7, Chicagoland-style.  We hope you can join us there…and please let your colleagues know.

Photo credit: iStockphoto.com

“Oh, sure, I mean, we’ll roll it out globally eventually, but is it really worth it to fly people in from all around the world for a design workshop?  Can’t we just figure it out first, and then tell them what to do later?  Travel budgets are tight.”

Travel budgets are tight, and accommodating global time zones is a huge pain.  But yes, it’s worth it, starting with face-to-face meetings to design your KM program.  Don’t think headquarters always knows best.  (Trust me:  your remote offices don’t.)

The astute KM program manager will fight hard for funding for global participation in process design. Here are some arguments to use.

The core challenge in implementing KCS isn’t the process, or the technology, but leading change in the organization.  That’s because KCS makes fundamental changes in how people think about their jobs.  They’re no longer case closers; they’re knowledge workers.  Their expertise is recognized through knowledge reuse, not by how many people ask them questions.  Case documentation isn’t an afterthought; it’s the heart of their job.  And by creating and improving knowledge, they no longer just help customers one at a time.  They help many customers at once—even while they’re sleeping.

Yet, from unhappy past experience, people view change at work with suspicion.  New measures hold them accountable in new ways.  Work is always added, and never removed.  Change is designed to benefit the company and customers, but never them.  Besides, change is hard—will they get in trouble for low performance while they’re learning new skills?  Will they feel foolish having engaged when this new program turns out to have been only a passing fad?  Thanks, but no thanks.

People want to be in control.  They want to be asked, not told.  You can tell them what success looks like, but don’t tell them how to get there.  Besides, they know how the work really gets done, no matter what your Visio workflow diagrams say.  Ignore their input at your peril.

KCS adopters need to feel like they’re part of a team—and being on a team is an emotional, not a logical, state.  It requires a level of relationship that is difficult to initiate in any way other than through in-person shared experiences, although it can be sustained remotely.

All these factors are exacerbated in remote locations and geographies.  They’re not swimming in the same meme-sea as people at HQ.  What’s obvious in Silicon Valley may not be obvious to people in Milton Keynes or Hyderabad.  They may not see the same kind of pressure for change—the status quo may be working better for them than for people Stateside, or wherever headquarters may be. They also don’t have the personal relationships with executives that lead to trust.  And, to top it off, they know they’re most at risk of being disrupted by outsourcing or other business model changes.

I’m writing this from the hills above Silicon Valley, so bear with me for a moment as I take a parochial view.  As painful as change is here, I personally believe there’s no culture more accepting of change than North America, especially Silicon Valley.  If change is hard here, I think it’s harder everywhere else in the world.  (And, people may be less likely to tell you what they really think in a conference call.)

There are different specific issues, but fundamentally the only reason KCS and other KM initiatives fail is that people choose not to engage.  Telling knowledge workers that they must do something is, unfortunately, not sufficient to get them to do it effectively.  You need to get them onside, truly believing that this change, as painful as it is, is worth it for the personal benefits they accrue—the “what’s in it for me” has to be big and palpable.

The only way I’ve seen these challenges overcome is to bring people together, physically, to design the processes they’ll all be living with—and, ideally, to define how their collective success will be measured.  Even though not all global staff will be there in person, they know their local colleagues are representing them.

KM initiatives can be expensive, especially when technology and integration is required.  If the process doesn’t take off, most of the value of the technology investment will be lost.  Honestly, paying for a few plane tickets and hotel nights is a small investment in an effective team to drive a worldwide KM program.