Industry surveys ask.  Colleagues ask.  IT asks.  Executives ask, incessantly.

“What’s your contact deflection rate?”

Let’s leave aside for the moment that contact deflection isn’t the primary reason to expose your knowledgebase to your customers.  Let’s also leave aside the fact that it’s both practically and philosophically difficult to count things that didn’t happen.  (Do I get credit for all the times I wasn’t snippy to my family and colleagues?  No?  But I counted 39 instances of snip-avoidance last week!  I mean, if I hadn’t been so nice, I would have been a real jerk.)

So, like it or not, we have to come up with an answer for how many contacts we’ve avoided.  As an aside, I don’t recommend that you characterize this as a rate—that is, a proportion of something else.  People ask for this, but in my experience most don’t really know how to think about it that way, and there also isn’t universal agreement about what to divide it by.  Saying “We had 10,000 self-service sessions this week that deflected approximately 500 cases” is clear enough; saying “we had 68% contact deflection” seems less obvious.

I’ve written elsewhere about techniques for estimating contact deflection; if you’re interested, please look at this newsletter article, and I won’t wave mathematical formulas at everyone else reading this blog.

What I do want to say is, it’s not straightforward.  And I cringe when I hear that there’s some magical “X Factor” that you can multiply by page views or web sessions to calculate deflection.

For one thing, contact deflection is lower than many people expect, because the majority of customers using self-service, even entitled enterprise customers, wouldn’t have opened a case.  As charming as we all are, customers would usually rather not talk with Support if they can avoid it.

But whatever your customer’s propensity to open a case after an unsuccessful self-service interaction (or page view, or Google search, or in-product link, or…what were we multiplying again?), you have to acknowledge that it’s going to vary from customer segment to customer segment, and product to product, and perhaps by geography, even within your own company.  Certainly, your customer behavior around opening cases after self-service will be different from that of other companies, even in your industry.

So the idea that there’s a single multiplicand that can give you self-service contact deflection is, unfortunately, just another myth.  If you must have an answer, calculate escalation rates and success rates as best you can, and let everyone know you’re estimating.  Please don’t say that you’ve multiplied your web traffic by an “industry best practice” constant.

Daktronics is a South Dakota-based manufacturer of LED signboards, from high school football scoreboards to major league arena installations and Las Vegas spectaculars.  Their technicians have to be conversant with a very broad range of products, including complex hardware and software.  This makes KCS a natural fit for them, and they’ve done a great job of adopting it.

Anyhow, on to the message, from a technician who was on call overnight:

I wanted to share a win with you guys.

I had worked a long day yesterday, about 10.5 hours.  I go home, set up for being on call at night, and wait for the phone to start ringing.  Doesn’t take long and I get my first hit.  I work with the customer for approximately 20 minutes and schedule a call back for 30 minutes later.  In the meantime I’m needing to log off of our network to do some connection testing for a different customer’s secure network (I can’t be tunneled into our network and theirs at the same time) Shortly before I start this adventure I received an IM from one of our Customer Trainers in Australia.  She had some questions about [a product feature] not showing up: they were created but wouldn’t show up in [the software].  I’m going to be very blunt here, “I’m pretty bad at the software parts of our product” end quote.  When she initially asked me about this, my first thought was “aaawwww crap, I have no idea.”  So we restarted some services and checked a few other overall basics.  In the meantime I started searching the KB. I found very few articles describing anything close to my issue.  Then I broadened the search by using just a few more keywords.  Wouldn’t you know it, a bright light came shining down from the KCS Gods and delivered the right KB article right into my lap.  I had called the trainer about 5 minutes earlier so all I did was walk her through the article. After completing the steps (which took all of 15 seconds) her reaction was “OH, THERE THEY ARE, THEY SHOWED UP!!!!!!!!  YEAH!!!!!!”  I was then able to still test my network connectivity for the other customer, and still make my 30 minute call back.  Now if that’s not awesome, I’m not quite sure what is!

Hope this brightens your day as much as it brightened my night last night.  Have a great day!!!!!!!!!!!

Here’s a brief definition for those unfamiliar with Net Promoter.  Industry research led by Fred Reichheld and his team at Bain & Company determined that customers fall into one of three buckets: they’re promoters who advocate for your brand, detractors who will badmouth you in the marketplace, or neutrals—people who may be satisfied, but who don’t rise to the level of advocate.  If we think of the companies we’re customers of, we can probably easily slot ourselves into one of those three buckets relative to them.

After much quantitative analysis, Reichheld and team determined that the most accurate way of predicting whether a customer is a promoter, detractor, or neutral is to ask them how likely they would be to recommend the company, on a zero to ten scale.  Nines and tens are promoters; sixes and below get classified as detractors; and sevens and eights are neutrals.  If you survey your customers, take the percentage of promoters and subtract the percentage of detractors, you get your Net Promoter Score—that is, the number of promoters net of the number of detractors.  Neutrals don’t count for or against you.  A company that scores all 9s and 10s gets a 100%; a company with all low scores is -100%.  Bain’s research suggests that most companies are in the low positive territory, while leaders can be plus 50% or higher.  (If you’re in negative territory…sell your stock.)

Unfortunately, because of its power, NPS has also gotten trendy.  And trendy measures tend to be misused, or to put it more nicely, “reinterpreted.”  It’s these creative interpretations that are the NPS myth.  Here are some examples I’ve seen:

Redefining the Scale

It’s a small tactical issue, but Net Promoter is based on the zero to ten scale with break points between six and seven, and eight and nine.  I see companies talk about the “NPS,” but pick entirely different scales or endpoints.  There can be good reasons for picking a different scale, but you can’t call what you calculate from it Net Promoter Score.  It’s something different, and the research on NPS may not apply directly, and comparisons with actual NPS scores aren’t valid.

Measuring NPS for Support

The Net Promoter Score is designed to “measure how well an organization treats the people whose lives it affects—how well it generates relationships worthy of loyalty.”  What we’re measuring is the customer’s impression.  And customers don’t care about your internal divisions.  They don’t have one impression of support, another of product development, another of your CFO, and yet another of HR.  By and large, they think about the company overall, and they’ll certainly recommend the company overall (or not.) They can’t say, “Well, buy your accounting software from Company X, but use Company Y’s support organization.”

So why would we measure the Net Promoter Score for Support?  “How likely are you to recommend Company X’s Support Organization to a Professional Colleague?” is an unhelpful question.  It doesn’t work that way.  You either recommend Company X, or you don’t.

As we mentioned earlier, it’s understandable to want to try to measure things that are only under your control, but that’s not how customers experience things, so it’s not a very productive exercise.

Measuring NPS Transactionally

Even more extreme than measuring Net Promoter for Support overall, is measuring Net Promoter for a single support transaction.  It’s a great thing to send (very brief, recurrence-limited) surveys to people who have engaged with your support staff or online resources—but let’s not pretend that their willingness to promote your brand is primarily based on their last support interaction.  Transactional and relationship surveys are different: in transactional surveys, you ask about the transaction, and only in the relationship surveys should you ask about overall impressions.

In transactional surveys, stick to asking about the case, or the web session, and leave it at that.

Compounding this error, I’m sorry to say that I’ve seen companies that selectively measure transactions, exempting entire classes of cases from surveys and giving individuals the option to strike particular troublesome interactions from surveys as well.  Needless to say, there’s enough sample bias and nonresponse bias in most survey programs that adding more with malice aforethought is really a terrible idea, and ultimately self-defeating.  This almost always is a result of focusing too much on the numbers.

Focusing on the Numbers

The root cause for many of these myths is a mistaken belief that the NPS numbers you report, by themselves, mean anything.

NPS, as you’ll recall, was developed as a way of measuring loyalty.  That is, higher NPS scores mapped into higher customer retention, lifetime value, and referenceability.  Since those are future behaviors, they can’t be measured directly, so NPS at its best is a predictor of good things happening in the future.

There is no NPS Bowl where companies or executives get rewarded because their numbers are high.  Whatever credit an executive hopes to get when he presents his “82% NPS” falls apart as soon as a skeptical audience member smells a rat and starts asking questions—at which point, credibility is irretrievably lost.  And, more importantly, although independent research has been mixed in supporting the predictive power of NPS, at least there is some.  Gamed numbers (based on modified scales, limited to support transactions, selectively sampled) have no research supporting their predictive power.

Fred Reichheld himself has said that the important thing about NPS isn’t what the number is; it’s what you do about it.  In the case of Support leadership, it can help line up the entire company on Support’s mission of the customer experience and customer success.  This is a Good Thing.  If we instead create unreliable, Support-only numbers to try to win a nonexistent NPS Bowl, we’ve done our customers, our companies, and ourselves a disservice.

As with most of these myths, there’s a kernel of truth.  It’s important to stay ahead of problems.  The problem is a matter of execution.  And, in fact, human nature makes it very, very hard for weekly ops reviews to be conducted productively.

The discipline of behavioral economics has taught us a great deal about the biases that humans exhibit.  Unlike the rationally maximizing human beings who play the starring role in most economics textbooks, real humans make decisions using many mental shortcuts—shortcuts that provided evolutionarily advantage.  If your ancestors had performed a careful, logical analysis when saber-tooth tigers prepared to pounce on them, you wouldn’t be here.  But because we unwittingly fall back on these mental shortcuts, we’re not always as rational as we might be.  (For a comprehensive and wonderful treatment of this, read Thinking, Fast and Slow by Daniel Kahneman, cofounder of Behavioral Economics; for a faster, thoroughly enjoyable version, try Predictably Irrational by Dan Ariely.)

What do saber-tooth tigers and behavioral economics have to do with weekly ops reviews?  Well, when humans are confronted with data, they can’t avoid finding patterns and explanations—even if variations in the data are 100% consistent with chance.  (One last book recommendation: The Drunkard’s Walk by Leonard Mlodinow lays out many examples where even mathematically sophisticated people can’t help but believe in explanations that don’t exist.)

This bias towards pattern recognition turns ops reviews into the Theater of the Absurd.  We have all this data, so we need to perform analysis and take actions!  Page views increase, and some minor change in the website UI is given credit.  CSAT goes down, and managers are called on the carpet and demanded to explain themselves.  Culprits are identified and chastised.  Yet, rarely is there someone in the room with the statistical acumen, the fortitude, and the mandate to say, “hey, but maybe that’s just a normal variation.”

It’s not just any patterns we find, either.  “Confirmation bias” means we find the patterns we’re looking for.  (If you need proof of this, just listen to two people at opposite ends of the political spectrum explain how a particular news report supports their positions.)  If I change the website’s color, and knowledgebase page views go up the following week, is there any doubt in my mind where the credit lies?  This doesn’t make me a bad human; it just makes me human.

Also, a statistical curiosity called regression to the mean is responsible for reinforcing mistaken notions of cause and effect in ops reviews.  If my metrics are atypically bad, by chance, they’re likely to be more typical—in other words, better—next week.  This is true whether or not I get yelled at…but it certainly makes yelling at me look like a highly effective strategy!

I know of some businesses where the weekly ops review is anticipated much as a visit to the dentist: you can be pretty sure there will be pain somewhere in the office, and you mostly hope it’s inflicted on someone else.

So, what’s the alternative?

• In a normal environment, there’s no reason to have a full-cast review of operational metrics more than once a month.  This at least reduces the amount of metrics “jitter” and makes the signal stronger relative to the noise.  Two caveats: Note that individual operations analysts and managers may scan the metrics more frequently to look for large unexpected movements that may require interventions.  And during periods of rapid change, such as a short intense busy season or while rolling out new initiatives, more frequent focused meetings are appropriate.
• Be aware of the natural tendency to assign cause where a cause may not exist.  Be especially aware of conclusions that confirm your own instincts, or that explain a return to normalcy.  Confirmation bias and regression to the mean may be in play.  It’s not a bad idea to find someone who can calculate confidence intervals on your data: you may be surprised how little of the variation that your business experiences is statistically significant.
• Finally, remember that the purpose of metrics is to inform the conversation and to aid learning…not to reward and punish.  As Dean Spitzer points out, the effectiveness of metrics as learning tools is directly related to the health of the culture of measurement.  And nothing damages the culture of measurement more quickly than beating people up based on their numbers.

“The beatings will continue until morale improves” is a funny t-shirt, but it’s no fun in real life.  Keep your ops reviews grounded in reality, positive, and informative.

There are three critical success factors for KCS:

• Engaged executive sponsorship
• Measuring the right things, and using those measures the right way
• Having the right coaches, properly prepared, and given the time to coach

I can fairly say that I’ve seen lots of variation in successful KCS programs, but I’ve never seen a successful implementation without these three things.

Without appropriate training, your coaches will not:

• Feel confident enough in their own KCS skills that they’re able to model the behavior and provide feedback to others
• Understand how to use KCS measures to assess knowledge developers’ progress towards licensing
• Feel comfortable giving direct, helpful feedback
• Understand influence skills and how to use them
• Understand how beliefs, attitudes, and behaviors interrelate, and how to intervene
• Be able to tell when someone is ready for licensing
• Be calibrated with each other in using the Article Quality Checklist and the Content Standard
• Understand how to structure their coaching sessions, and have the right job aids for coaching

In other words, without this kind of training, your coaches aren’t going to be prepared to run effective coaching sessions.  Given the time that you’re investing in coaching, that’s an enormous waste of resources…and one that puts the success of the overall project at risk.

What’s your experience been with preparing coaches?  Am I overstating the risk of not training them?

(HT RW)

Benchmarking works best on truly objective outcome goals: revenue per headcount or per square foot of retail space.  Gross margin.  Hotel occupancy.  Share of wallet.

Unfortunately, support organizations own few of these.  Arguably, for some organizations, maintenance renewal rates are a clear outcome, although even then, this depends on many cross-functional groups.

No, support leaders tend to want to benchmark other, more operational metrics: first contact resolution (FCR), customer satisfaction (CSAT), website “did this help” ratings, contact avoidance, and the like.  And here’s where cross-company comparisons can confuse as much as enlighten.

First, on a very practical level, everyone measures these things differently.  You might think that there would be an industry-standard way of measuring FCR…but you’d be wrong.  (I was brutally disabused of this notion during a—I am not making this up—two hour conversation among ten service desk managers comparing and contrasting the details of their FCR measurement techniques.  These were among the longest, yet most enlightening, two hours of my life.)

CSAT, in particular, sounds like it should be straightforward to compare between companies, and yet it isn’t.  Survey results are notoriously sensitive to all kinds of details: how the question is worded and what scale is used for the answer can both substantially change the results.  More subtle forms of bias can creep in, too.  In our business, the most common is non-response bias—in other words, the small percentage of people who answer our surveys aren’t necessarily representative of all the people we want to reach.  Also, some companies exclude certain cases or customers from surveys, while others mix up transactional (post-case) surveys with relationship (periodic, overall experience) surveys. Comparing your “4.3 CSAT” against my “4.1 CSAT” really doesn’t necessarily teach me anything unless I really, really understand the details of how you measure CSAT.  If I’m simply using data from an industry benchmarking database, I have absolutely no idea how that particular brand of sausage was made.

If you have a deep and trusted relationship with a peer company, and you really understand how their measurement techniques match to yours, you might learn something from benchmarking.  Unfortunately, ethical access to the fine details of peer company operations is rare.

More strategically, measures reflect your philosophy of business. Zappos is well known for not measuring handle time, because they believe personal relationships in customer service fuel their corporate engine of growth.  So, what point is there in measuring your handle time against Zappos’s?

That’s an extreme example, but different business decisions drive different metrics, and obscure insights that might be gained by comparison.  I know some support leaders are fixated on time to first technical contact, others on contact rate, others on service levels, and still others on NPS.  None of these is wrong, but they will affect the measures.

So, benchmarking against other companies is fraught with difficulties.  Still, we need aspirational goals.  What to do?

First, sometimes benchmarks can be good to cause a deep rethinking of process.  For example, I worked once with a company that was very proud that they had engaged additional outsourced staff in order to move their time to publication for knowledgebase articles from 23 to 14 days.  When they heard that some companies do it in minutes, that data point spurred useful conversation.  (Clearly, this requires more than hiring some new reviewers.)

Secondly, the best benchmarks are self-benchmarks.  When I get on the scale, I don’t compare myself with the average male my height; I’m interested in where I am relative to where I was the week before.  Similarly, if I’ve improved my ability to capture, reuse, and improve knowledge, I’d like to see if my contact rate is going down, or my ability to close cases faster with reused knowledge is increasing.  Any metric I report on is a candidate for self-benchmarking, especially if I’ve been taking actions to change something.  Not every change is meaningful, but if you look at your own trends over time, in measures that are strategic to your business, you’ll have the best possible, least-gameable, most informative metrics of all.

Many of us “self-benchmarked” on doorways growing up.

Let’s back up and define our terms.  A Return on Investment (ROI) analysis is a financial model that calculates what net present value (NPV) implementing something, generally a technology, will deliver relative to its cost.  This can be expressed as a percentage (“returns will be 183% of investment within 24 months”) or a time (“We’ll break even after 14 months, and after that everything is upside.”)  Benefits need to be quantified in hard dollars: “better customer experience” doesn’t count as a return in an ROI model.  A thoughtful ROI captures all sorts of investments—not just software licenses or subscriptions, but also hardware, implementation costs, support contracts, ongoing maintenance, training, and project management.

Right away, it’s clear that ROIs are tricky.  Technology investments, by themselves, almost never generate benefits.  Benefits only accrue from technology when it supports process improvements, and when people follow the new processes.  Predicting the costs and benefits of an entire process change initiative is harder, and more speculative, than just adding up the costs of technology.

Still, as a sanity check, it’s a reasonable plan to come up with a rough estimate of ROI.  In particular, you might find out that the implementation is so expensive that you won’t make up the investment in any reasonable time period.  In this case, it’s good to stop and reconsider your initiative.

So, why do I list ROI as a “Metrics Myth?”

1. The complexity of program-wide ROIs means that non-technology costs tend to get swept under the rug, and we pretend that the new knowledgebase, search engine, or CRM tool will magically shorten handle times or deflect contacts by itself.  Needless to say, this kind of magic thinking isn’t conducive to good decision-making.
2. Also, as an industry, we tend to know what good ROIs look like.  A 10,000% or even 1,000% near-term return on investment isn’t seen as credible (although knowledge programs can, in fact, do this!)  A near break-even ROI isn’t compelling.  Spreadsheets make it easy to change assumptions to see what happens.  So, of course, program teams all turn in ROIs that are high enough to be interesting, but not so high as to look bogus. I’m not accusing anyone of fudging the numbers, and I’m sure we all have the best of intentions, but it’s remarkable how…consistent…the ROIs I see are.  This is probably why KM and HR thought leader Hubert St. Onge describes ROI analyses with a single, earthy, Anglo-Saxon word.
3. At any given time, there are probably 50 initiatives that have positive near-term ROI.  But the organization only has the ability to absorb so much change in the near term.  So, which of these 50 initiatives will it implement?  I guarantee you that the VP of Support and CFO will not rank order the candidates on the basis of calculated ROI.  They’ll find the financially attractive opportunities that best line up with the organization’s strategic goals and initiatives.  In executive decision-making, estimated hard dollars are less important than strategic alignment, perhaps because no one really trusts the hard dollar estimates, and perhaps because the strategic objectives are seen as the big opportunity for making money.

The bottom line is, do an ROI to sanity check your initiative, but spend more time on the strategic framework—how you explain how the initiative, process and technology together, will move the needle for the organization’s strategic goals.

Perhaps the saddest fact about ROI analyses is that, once the program is approved, they’re generally filed away and forgotten about.  This is a missed opportunity!  The ROI analysis contains specific assumptions and models about how the business will improve.  Once the program goes live, you have a wonderful opportunity to test those assumptions in the real world.  Are things working as you expected?  Great!  Now figure out what to do to make it even better.  Are things falling short of expectations?  Great!  Your ROI gives you a model that will help you troubleshoot and make incremental improvements, or perhaps invalidate certain assumptions and help you pivot to a better approach.  Either way, facts are friends: by overlaying reality on your ROI, you’ll learn lots about how your business really works, and how to make things even better.

It’s a cliché that you get what you measure.  So before we start picking from the standard list of reports provided by your KM, CRM, or BI system, let me ask you: what do you want to get?

If what you want is the same thing as everyone else, then the standard measures should do just fine.  But if you have ambitions to stand out…if you have a new insight about how to do support…if you’re seeking competitive advantage, I’d say, not so fast.

When Southwest Airlines emerged into prominence, there were many standard airline metrics to choose from: occupancy, revenue per available seat mile, and the like.  But Southwest’s then-CEO, Herb Kelleher, recognized that their chief limit to growth was the number of extremely expensive airplanes they could afford to own.  Or, to be more precise, their revenue is bounded by the number of airplanes in the air.  This led to a simple insight: an airplane on the ground isn’t making money, so let’s minimize the time spent on the ground.

To put this insight into action, Southwest started measuring and improving their turnaround time, or the length of time their planes spend idle at the gate.  Much of what’s unique about Southwest, from flight attendants who clean the planes as passengers are leaving, to boarding by groups and unassigned seating, are the result of Southwest’s obsession with turnaround time.  The result is sustained profitability in a generally unprofitable industry, and the equivalent passenger capacity of 35 additional multi-million dollar 737s.  “Strategic” trumped “standard” for Southwest.

Other industry leaders have taken the same path.  Dell focused on its Cash Conversion Cycle (CCC), the length of time between paying vendors for components and receiving money from customers.  Dell’s remarkable build-on-demand infrastructure, leverage with suppliers, and streamlined operations resulted in a negative CCC—that is, Dell gets paid by customers several weeks before it has to pay its suppliers.  This cash float is a real engine for growth, and it’s there because Dell focused on its own, slightly non-standard, metric.

We’ve seen this in the support industry, too.  When innovative support and customer experience leader Brad Smith was at the helm at Openwave Systems, he had his team focus on margin dollars per case.  He reasoned that he wanted more margin (through efficiency and customer retention), and fewer cases (through product improvements, self-service, and proactive support).  The more margin, and the fewer cases, the better their margin per case.  I don’t know if any other organization has measured margin per case—and it certainly isn’t in any standard Support dashboard.  But Brad and his team were completely focused on higher renewals, more efficient case handling, and helping customers avoid cases…all great things for Openwave and its customers.

“Transformational measures can help organizations focus on what is most important today and for the future,” says Dr. Dean Spitzer in his outstanding book Transforming Performance Measurement.  “When we change our ways of measurement, the fundamental ‘lens’ used to view things changes.  Organizational transformation is what happens when people begin to see their organization through the new lens.”

If you’re not sure what your strategy should be, or how you’re going to transform your organization for the better, then by all means, use the same measures as everyone else.  But if you have a vision for where you want to go—and I hope that you do—then pick what Spitzer calls transformational measures to track and motivate your progress on that journey.

Because, you know, that’s what support does.  Close cases.  Quickly.  In a way that satisfies customers.  Mission accomplished; let’s grab a beer!

Not so fast.

This myth begs the question of why the Support organization exists.  Because most of the activity, headcount, and budget are tied up in closing cases, it’s easy to assume that the business of Support is closing cases, full stop.  But that’s far too limited a view of our business.

Support is in the customer success business—as a colleague likes to say, helping customers receive and perceive value from the product.  Closing cases can be part of that—a means to an end—but it’s not the most important part, and it’s certainly not the most valuable.

First, let me back up my statement about why Support exists.  When I ask a group of Support executives why they do what they do, they often start out with (true!) statements like, “the product breaks.”  Using a gentle version of the five whys, if I keep asking why that’s important, we always get to some version of, “if the customer doesn’t get value from the product, they won’t buy more, and they won’t tell their friends to buy, either.”  Bingo.  There’s no intrinsic value to the business in closing cases; it’s all about customer retention, loyalty, lifetime value, and referenceability.  Support feeds the company’s engines of growth and sustainability.  The Technology Services Industry Association has made this topic a focus of their research; their findings are summarized in Consumption Economics.

But even if we believe that Support’s mission is to make customers successful, it’s still easy to fall back on our old operational measures: cases closed, service levels, customer satisfaction (CSAT), and the like.  What’s wrong with that?

The problem is that it dramatically overstates the significance of the assisted case-closing channel as a way of delivering customer value.  Cases are both more rare, and deliver less value, than most support organizations think.

If customers have a problem with our products, or are struggling to use them, opening a case is surprisingly low on their list of next steps.  If you consider your own experience with technology, other approaches tend to happen first.  Think about it a minute…what did you do last time you had a problem?  If you’re like most people, you Googled it.  Or you asked a friend or colleague.  (I should know.  I’m often that friend or colleague.  And then I generally Google it!)

Sometimes I go to the vendor’s site and seek out an answer there.  Sometimes I’ll start a new thread in a community, although I’ll do so only after looking for a while, because I don’t want to be That Guy who re-posts an FAQ.  I do open support cases, but not usually.

Now you might say, as a consumer and small business owner, I’m not entitled to great assisted support, so I tough it out, making do with free resources.  But you know what?  I’d really rather figure it out on my own—even if the vendor is there to help me, I’d rather not jump through their hoops and explain it all to someone else if I can be self-sufficient.  Many people feel the same way.

At least, that’s what the numbers show.  As we look at our clients’ data, enterprise customers open a case only a small single-digit percentage of the time they want help.  (The number is much, much smaller for B2C support.)  The rest of the time, they’re using Google, the self-service site, in-product help, and social networks of various kinds, including of the sneakernet variety.  Sure, they tend to open cases for higher severity issues, but when it comes to customer success, every moment of need is important.

Do a perfect job on 100% of the cases you receive, and you’re only making a difference 5% of the time.  Or less.

So, when do customers open a case?  Generally when things have hit the proverbial fan.  When there has already been significant value erosion.  The system is down; something needs to be replaced; it’s throwing an error and not completing a task; it isn’t doing something it is supposed to be able to do; or, it’s doing something it shouldn’t be doing.  By the time the customer picks up the phone or logs in to our support portal, we have a problem, Houston, and we’re in recovery mode.

Closing a case quickly and well simply makes the problem go away.  It gets customers back to where they expected to be.  It doesn’t make things better than expected.  Certainly, herculean recovery efforts can engender a sense of personal gratitude, which is nice, but it’s doing a job well that never should have had to have been done in the first place.

Of course, once a case has been opened, closing it quickly and well is the best outcome.  But that doesn’t always happen.  Then things get really ugly, as you know from having been on both sides of this experience.

So, closing a case can be important, but only in so far as it gets us back to where we started.  What else can support organizations do?

• Provide feedback to Development to help them improve the product and the customer experience, avoiding problems in the first place
• Expand into a Customer Success Management role that proactively advises customers to help them get the most value from their products
• Build and implement configuration health checks and other utilities that help customers avoid problems in the first place
• Create knowledgebase articles, video tutorials, and automated fixes to empower customers with the expertise they need to be successful themselves, and to get themselves back to value more quickly when needed

All of these tasks  help customers receive and perceive value more than simply closing a case.  What else do they have in common?  Most support organizations are too busy to do them.  Why?  They’re closing too many cases.  Hmm.

Followers of popular business books will recall the BHAG—the Big Hairy Audacious Goal—proposed by James Collins and Jerry Porras in Built to Last.  These goals are long-term, viewed as a long shot by outsiders, but considered possible by insiders.  They act as a unifying vision for the company, much as Lencioni’s “Rallying Cry” did in the last myth.

This kind of overarching, companywide, long-term goal is great, although, given how “goal” is commonly used at work, I’d prefer to call it a “measurable vision.”  Great executives set these, communicate them, and stick with them.

But most of the goals we have in companies aren’t like that.  They tend to be more tactical, more operational, and shorter term.  You can’t have a BHAG on service level compliance—BHAGs are a brass ring for the company overall, which service levels most decidedly are not.  So executives should stay away from these operational goals.

Why? Because they’re a means to an end—a way of achieving the BHAG.  And it’s the people actually doing the work who are in the best position to know how to get there, and how to hold themselves accountable to the work.

Those of you who have been to a KCS Foundations or Design Workshop may remember the Process and Change exercise we do with a ball.  While I’m not going to spoil it for future participants, I’ll say that the team estimates its own ability to improve its processes, and, especially after a few iterations, it’s remarkably good at setting its own goals.  The team is better that I as the facilitator would be, and I’ve led the exercise tens of times.  But they have a secret ingredient that I don’t have: they know each other, and they have hands-on experience with the process they’re measuring.

Forget the director in the corner office.  It’s way better for the people doing the work to set their own goals.

Now a cynic might ask, won’t they sandbag?  Won’t they set easy goals for themselves?  My experience is, unless the organization has completely stamped initiative and self-respect out of a team (in which case you need a different blog, or maybe just a different job), teams will challenge themselves and each other.  Almost all the people we work with want to do well, they want to feel a sense of accomplishment, and they want to be part of a high-functioning team.

Not only will teams do a better job of setting goals than their managers will, they’ll have that special something that comes from owning a goal.  If you tell me I have to do something, I might just argue with you.  But if I tell you I’m going to do something, just try and stop me.

So, executives should set an ambitious, exciting, and plausible vision.  When it comes to setting the goals along the way, let the people doing the work take the lead.  Support them.  And get out of their way.