Hack Your Knowledgebase

Posted on February 16, 2012 by David Kay

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.

 

Posted in KCS, KM, Lynchpins, Technology | Leave a comment

2012 Kickoff: What’s Happening in KM and KCS

Posted on January 3, 2012 by David Kay
Checkered Flag on 2011

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.

 

Posted in Announcements, KCS, KM, Social Support | Leave a comment

Writing? Or Communicating in Words?

Posted on December 14, 2011 by David Kay

“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.

 

Posted in Uncategorized | Leave a comment

Is Knowledge Really an Asset?

Posted on November 22, 2011 by David Kay

“Knowledge is the key asset of the support organization.”
The KCS Practices Guide, v5.1
The Consortium for Service Innovation

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.

Posted in KCS, KM, Measures | Leave a comment

The Big Ideas Behind KCS

Posted on September 6, 2011 by David Kay

Back when I was first exposed to KCS, in 1998 or so, it was very principles-focused.  Perhaps this is a polite way of saying, we hadn’t yet figured out very specific guidance to give support organizations, so we talked in generalities:  “align to demand,” “migrate content towards the users,” and the like.  It’s all good stuff, but not very actionable.

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.

 

 

 

 

Posted in KCS | 1 Comment

Six Simple Measures for Community Managers

Posted on August 16, 2011 by David Kay

Not long ago, it seemed like there weren’t any reasonable measures for the health and effectiveness of communities; now it seems like there are too many!  We often see eSupport and community leaders trying to grapple with page after page of bar charts, line graphs, and tables, unsure what to pay attention to, and unsure what to report up the management chain.

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.

 

 

Posted in Measures, Social Support | 1 Comment

Do We Really Have To Do This Globally?

Posted on August 2, 2011 by David Kay

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.

Posted in Culture, KCS, KM | 4 Comments

The Power of Feedback

Posted on July 11, 2011 by David Kay

Photo credit: iStockphoto.com

Last time in this space, we discussed the power of appreciation.  Let’s explore another primal human need—the need to answer the question, “how am I doing?”

It starts early.  Watch a small child doing something new:  she will be looking anxiously at a parent to see if the action brings praise or censure.  As we mature, we start looking inside ourselves more than to authority figures to answer the question.  Sometimes, our conscience or our “gut” provides us all we need to know.  But other times, we need data.

Sports and games are all about providing feedback.  Our golf scores, our lap times, how much Monopoly money we have, a perfect 10, all provide us unambiguous data to assess our performance.  Whether we choose to benchmark against ourselves (as I do as a lousy golfer) or against others (as I do at the racetrack), we get satisfaction from knowing where we stand.  And we use that data to motivate ourselves to improve.

Note that I’m not just talking about winning, and the sense of achievement this brings.  Win, place, or show, we want to know the score—literally.  Who would ever play a video game where you couldn’t see the points?

A recent excellent Wired cover story on using feedback to modify behavior got me thinking about this, and how much more we could do with feedback in our KM initiatives.  One example it cited:  radar-equipped speed limit signs—the kind that tell you how fast you’re driving—reduce speeds in school zones, even more than cops writing tickets.

The author, Thomas Goetz, suggests that there are four requirements to make feedback effective at changing behavior.  Let’s see how we can apply them in the support center:

  1. Evidence:  quantifying the behavior.  For KCS, these are the activity measures—each support staffer should be constantly reminded of his or her participation rate, create rate, edit rate, case closure rate, article quality index, escalation rate, or metrics on other behaviors we care about.
  2. Relevance:  providing context.  For activities, these would be historical trends and team averages.  (As readers of this blog surely know, we would never put goals on activities.)
  3. Consequences:  the larger goal or purpose. Show outcomes like net promoter score, renewal rates, or self-service success, because these outcomes are the reason we’re performing the activities.  Also, include knowledge performance as part of employees’ performance reviews.  This ties individual action and accountability to the organization’s mission.
  4. Action:  closing the loop.  This is where the support staffer decides to be more diligent about capturing, reusing, and improving knowledge—not because he needs to achieve a quota, but because he wants to narrow the gap between himself and high performers on the team, or he wants to be part of the team’s success.

This is all pretty basic stuff, but how often do we even get through step one?  Is your team constantly reminded of their knowledge performance?

Make sure everyone on your team knows the answer to the question, “how am I doing?”  And most of them will return the favor by making the response, “Better than ever before, thanks.”

Posted in Culture, KCS, Measures | 2 Comments

The Power of Appreciation

Posted on June 22, 2011 by David Kay

Really, it seems too good to be true.  If you heard about this in an email, you’d mark it as spam immediately.  “You’ll feel better, make the people around you feel better, improve relationships at work and at home, and make people more likely to listen to you.” Sure…do you have a Nigerian millionaire’s estate to split with me, too?

The funny thing is, though, it’s real.  Appreciation, given sincerely and consistently, does all that and more.

Before I say more about this, let me be clear about what I’m not talking about:

  • Flattery.  We can all tell when someone’s blowing sunshine up our skirts.  It makes us feel manipulated, and besides, no one trusts a flatterer.
  • The compliment sandwich.  Have you ever known people who only say something nice when they have something negative to say?  “Great work closing your cases this week…oh, by the way, if you don’t start attaching cover sheets to your TPS reports, you’re going to be in big trouble.  Nice tie!”  This isn’t very subtle, and appreciation from a compliment sandwich-maker leaves us wondering when the other shoe is going to drop.
  • A grateful attitude.  Don’t get me wrong; this is a great thing to cultivate.  But when I’m talking about appreciation, I’m talking about a specific set of behaviors, not a mindset or attitude.

Appreciation is the act of telling those around you the attributes or behaviors they have that you like.  For a coworker, this might be the fact that you can absolutely count on them to do what they say, or how their work makes your job easier, or how their positive approach just makes the office a nicer place.

Most of us notice these things, and we may even mention them to others.  But how often do well tell the person we appreciate?  Especially if we don’t do it frequently, it may feel awkward, or even somehow unprofessional.  But practice makes it comfortable, and it’s perfectly professional when applied to workplace topics.

There are as many ways to express our appreciation as there are reasons to appreciate others.  A quick face-to-face comment works, as can an email, or a post-it.  If you’re inclined, home-baked cookies or veggies from the garden are nice, but really, this is a case where the communication is what counts.

Appreciation works best when it’s

  • Specific—tell them exactly what you liked
  • Timely—as they say, “if you see something, say something.”  Now.
  • Personal—say why they and their actions matter to you.

If people know you appreciate them and what they do, they’ll be happier to do more of it for you.  They’ll know you value them, which means if you do need to have a difficult conversation, it’s based on mutual trust.  And it really does feel good to see someone smile when you let them know what you appreciate.

Appreciation is an extremely powerful behavior to cultivate.  Let’s all remind ourselves to do more of it.

(On that note, let me say how much Jennifer and I appreciate the fact that you’re actually reading this.  It’s fun putting our experiences and observations in writing, but knowing that more and more people are reading it makes it really satisfying.  Thank you!)

(HT to Beth Haggett, who developed the KCS Coaching workshop that got me thinking about appreciation in the first place.)

 

Posted in Coaching, Culture, KM | 3 Comments

Keep An Eye On Your Customers’ Success

Posted on June 8, 2011 by David Kay
Measuring a runner with a stopwatch

Generally speaking, in Support we measure our operations:  time to resolve and backlog, for example.  But in Marketing, they measure customer behavior, like click-through rates and conversion rates.  In this case, I think Marketing has it right.  And from what I’m seeing, more Support leaders think so, too.

The days of passively waiting for customers to open a case are over.  Dissatisfied B2B customers may just grumble to a colleague at an industry event, and consumers will share a derisive tweet…if you’re lucky.  In many cases the switching costs to a competitor are so low that they’ll just leave.  And the fact that you could have resolved their issue, if only they’d asked you, will do you exactly no good at all.

I often say that Support is in the customer success business—so that’s what we should measure, as best we can.  We have to watch our customers to see if they’re being successful, or at least if they’re acting as other successful customers do.  And we need to be proactive about helping them if they’re not.

I’m seeing great examples of this.  For consumers, Intuit’s support measures itself based on how frequently customers are able to successfully complete their tax returns.  And Yahoo! looks for customers who are sharing their concerns in social media forums—in some cases, they’ll jump in and help.  Yahoo! also measures user behavior to identify which features make customers more active and loyal; the Help team focuses attention on making it easier for customers to adopt these features.

For businesses, configuration health checks are becoming commonplace, as Support measures, in effect, how prepared for success their customers are.  And Salesforce.com has implemented what they describe as an Early Warning System—really, a customer success dashboard—that shows how fully customers are taking advantage of the capability they’ve licensed.  This lets Customer Success Managers (isn’t that a great title?) guide lagging customers to more deeply engage and get more value from Salesforce—and, in turn, they hope to reduce defections.

These programs all have a few things in common:

  • They measure the customer, not support operations
  • They’re focused on success and value, not simple uptime
  • They’re more impactful and practical in SaaS—yet another reason support executives should want to advocate for the cloud whenever possible

In Support, we love measuring things.  Let’s make sure we measure the things that matter to our customers.

(HT to Patsy Nations, Brad Smith,  Neil Deluca, and Mehmet Goker.)



Posted in Measures | 4 Comments