Summer Reading! Lessons Unlearned

26 Jun

Just because a book is full of really great information doesn’t mean it can’t be fun to read. For example, take John Ragsdale’s wonderful first book:

Lessons Unlearned: 25 Years in Customer Service. John Ragsdale (@john_ragsdale).

Unlike the books I’ve reviewed earlier. I’m not even going to pretend to be objective here: I’m a big fan of John. He’s familiar to many of you as Vice President of technology research for TSIA; he came to that role having worked on the front lines of service delivery, as a manager, as a vendor, and as a Forrester Analyst and VP of their CRM research practice. So if it has something to do with service and support, he’s seen it, he’s done it, and he has a great story to tell about it, too. Lessons Unlearned is refreshingly free of corporate-speak; while he writes as a member of TSIA’s leadership team, what comes through is John’s warm, authentic, and positive voice.

Oh, and does that voice have some things to say.

For support professionals, he has a great section on metrics, showing how to use them in combination to assess what’s happening and to inform good conversations, rather than using measures blindly or in isolation to reward and punish. He also describes support employee archetypes—the Slammer, the Geek, the Socialite—that will have you smiling in recognition of the uncannily accurate portrayals of your colleagues…and perhaps yourself.

One section that should be required reading for anyone involved in a technology procurement exercise is “Selecting Technology,” which turns common practice on its head. (When you’re thinking back on a successful relationship with a technology vendor, did the 327 requirements in your RFP really end up being the high order bit?)

As a reformed product management and marketing professional, I especially enjoyed the advice to vendors about dealing with analysts and launching a successful startup. If anyone can figure out how to ship this book back to me in 1998, I’d appreciate it.

OK, there’s no mistaking Lessons Unlearned for 50 Shades of Anything. But you’ll enjoy it nearly as much, and you won’t have to hide it behind a copy of The Economist, either.

Hack Your Knowledgebase

By: David Kay 5 Comments

16 Feb

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.

Suggested New Years Resolutions for KM Vendors

By: David Kay 4 Comments

28 Dec

Memo

To: Knowledge Management Technology Vendors

From: DB Kay & Associates

Re: Suggested New Years Resolutions

Vendors, I’ve been watching your customers struggle with your products. I have a few simple suggestions that might help.

Streamline the interface. Here’s a question: how long does it take a user to do all the mousing and clicking required to set tags, change access levels, and perform other administrative tasks before she can even start to capture knowledge? In most cases, it’s at least a minute of work, which may not seem like much, but it’s an eternity when you’re trying to capture and structure knowledge in the workflow.

If there are pop-up windows, can they be pulldowns? Or can the interface be provided in the page with AJAX or other dynamic technologies?

If there are pulldowns, can they be radio buttons?

If there are radio buttons, can they be checkboxes that are only used by exception?

Can we just eliminate interface elements?

Use any modern web application – Gmail, for example. Is your software that responsive? Really? Buy your developers an O’Reilly book if they’re not sure how web apps were written after 2005.

Make linking from CRM cases (or incidents) to knowledge articles a part of every Phase I implementation. A reuse counter in your tool isn’t sufficient. Without this data, customers will be flying blind.

Don’t design for your most complex customers. I know customers come to you insisting that they need three independent taxonomies for entitlement, and fifteen levels of access, individually selectable visibility flags for each section in the template, and workflows that trigger separately for each kind of document.

I’ve met them, too. The thing about these customers is, they destroy your product for people who are more sophisticated about how knowledge actually works. Remember, overengineering knowledge processes is almost always a symptom of a lack of practical experience. If a feature is going to add an extra click for other customers, please just say “no.” Shoot us an email and we’ll try to help your customer see the light.

Best wishes for a wonderful—and streamlined—2011.

/s/
David