KANA Global Consulting Services Blog

Latest Updates: search RSS

• 

  John Chmaj 09:16:12 pm on October 16, 2009 | 0 | # |
  Tags: best practices, knowledge, Knowledge Management, search, Self-Service

  FINDING Depends on How you SEEK -

  One of the most important things to think about in making knowledge delivery systems work is HOW users will find what they’re looking for.  At first glance it may seem simple:  type in a search, find your stuff.  But is it really that straightforward?  Do you really know what you’re looking for?  Do you really know what the right query is?  Do you even know what content exists in the system you’re using?

  One of the main reasons we all engage in building and managing support-focused search tools and portals is because we are trying to create a series of efficient, intuitive user experiences that lead people to the right answers to their questions.  However, my experience is that all questions – and all users – are not created equal.  Sometimes we know exactly what we need and how to ask, other times we haven’t a clue.  The same person, who may be expert on one issue, may be totally lost just looking for a slightly different issue in their own KB.

  In this context always think of one Christmas morning spent huddled over my sister’s computer, trying desperately to get the Disney Aladdin DVD to install and run properly, my little 4 yr old daughter wailing and pleading with me as I, the great computer expert in the family, struggled to figure out what query to enter in the Disney knowledge base to address the failure of this $5 DVD to load!  One is only as smart as the next problem, really –

  One of the most critical yet unrecognized features of a knowledge base is its ability to teach users about the terms, taxonomy, and content that is available to solve their question.  Most searches aren’t a one-shot deal – the user progressively browses to learn about an issue, scope the content, tries different queries to see what’s in the KB, and finally decides when to browse through titles and content for the best fit.  I find it useful to boil the types of interactions one needs to have based on how much one knows about an issue, and what one needs in terms of guidance from the knowledge base to get to the answer. A simple way to think about it is as follows.

  Three types of navigation

  1. I Know What I Know – Lookup

  This is the stereotypical “Google-esque” query – I know the data I want, I know the terms that should bring it back, I type in “error 99″ and voila!  There’s my stuff.  Support experts usually expect this type of behavior, and in fact the weaker a KB is the more they memorize special terms, document ID’s and keywords that will give them what they want.  But in the end they’re not really searching as much as looking up known content.  This is an important capability that must work well, but it’s far from the only interaction people have, ESPECIALLY in self-help systems.

  2. I Know What I Don’t Know – Guided Search

  In this scenario users know the TYPE of information they need, perhaps also the topic or potential terms, but don’t exactly know what content is out there.  They may browse to scope the issue, then type in a query or two based on what appear to be the common topics.  KM systems assist here by providing potential additional browse and filtering options that are relevant to the current query scope.  The user can go back and forth, examining the options provided by the system, to find the right fit of topic and query detail.  These systems work well when the user has some idea of what the right solution is and just needs assistance getting to the right area of the knowledge base.  But that’s not the final area, nor perhaps the most important…there’s still:

  3. I Don’t Know What I Don’t Know – Browse and Filter

  Many users, especially those new to a particular domain, don’t really know how to think about the information that’s in it, what terms or topics are relevant, maybe not even what they’re supposed to ask.  In my Disney DVD problem, I had some smart ideas but none turned out to be relevant.  Was it the display driver?  The computer RAM?  OS version?  Plug-in requirements for video?  And how should I query a simple Disney DVD for this kind of stuff?  These scenarios are where a good browse experience can shine.  Not only can it help users figure out what the key components of a product are, the topics and known problems, but should also quickly point up common questions the user is likely to have.  By seeing common issues and how they are organized users can get insight into what their questions are, or likely queries should browsing and filtering not bring back the answer immediately.

  At the end of the day we’re all just looking for ANSWERS, aren’t we?  If we think through what the process of acquiring knowledge entails, we can trace these patterns of inquiry and do our best to model them for particular audiences, users and issues.  When this is well done for all three query types, users experience the ‘magic’ of knowledge bases.  They DO indeed seem to ‘know exactly what you want’, yet you may not even be aware of how seamlessly the system allows you to move between these modes of inquiry and still get the scent of the answer you need.  As KM system builders, we just have to give a little THOUGHT to how people THINK….!

  John Chmaj
  “The Knowledge Advocate”

   

• John Chmaj 06:25:48 pm on September 18, 2009 | 0 | # |
  Tags: best practices, KM, Knowledge Management, search, Self-Service

  Why Support Search CAN’T Be “Just Like Google”

  Google is on my homepage.  I use it every day.  It’s an indispensable part of my access to Internet resources, and usually the first place I look to find something. But Google is NOT the tool I recommend for most support & service organizations to use for customer self-help.  Many organizations ask “why can’t support search be just like Google?”  Here’s what they WANT, and what they actually NEED:

  Why We Like Google

  • Google WORKS:  it’s fast, easy to enter whatever text you want, results always seem relevant
  • Google appears FLEXIBLE and FORGIVING:  even if you enter in text that isn’t quite what you meant usually something useful comes back
  • Google is SIMPLE:  type two words and go – what could be easier?

  These are all desirable aspects of finding good information quickly, and self-help should aspire to reflect all these capabilities.  So what’s the issue?

  THE ISSUES are the issues:  Google is geared towards worldwide access to the most popular or important resources for anything and everything.  Support & service inquiries are focused on very specific questions, applying to only a tiny subset of worldwide information.

  Most importantly, support & service self-help is a negotiation, a set of back and forth transactions by users and services resources to:

  • Define the real need (the users’ query is just a guess or vote for what that might be)
  • Explore the available resources to see what types of information is best suited
  • Bring back the specific tasks, data gathering, processes and steps required to achieve the services outcome

  All of this goes far beyond a simple two-word query.  If I enter “Sprint handset upgrade” into Google I might get all manner of interesting information, but I really haven’t defined my need yet.  Do I want a new handset?  Do I have one and want to activate it?  Do I want to know the programs I’m entitled to?  Do I have a billing question?  Furthermore, even if I could identify that in my query, do I REALLY want all the resources of the world returned as the answer to my question, or even all the resources of a large company like Sprint?

  At the end of the day an effective support & service self-service system needs to help users with these three critical phases of the support process.  Beyond just bringing back information from a query, the whole point of KM tools & technologies is to create a fast, intuitive, effective session with users to help them get quickly to the best answer for their services need at the moment.  So additional capabilities are needed beyond basic text query processing and results:

  1. Defining the Question:  helping users navigate the topics, top issues, terminology and overall way to think about the company’s products and services, so they can effectively express what they need in relationship to how support can help.  This may include additional field selection to narrow the focus, scripts that guide users to define their issue specifically, guided search interactions, filters, etc.  to help users refine and focus their need.

  2. Exploring Resources: giving clear feedback and quick navigation through the various information that is available.  All content is not the same when it comes to fulfilling a specific support request.  The answer to a question on “handset upgrade” may come from pricing tables, program offerings, technical support articles, documentation, etc.  Users need feedback from the system on what’s going to meet their need as it becomes more clear.  In many organizations the next step is not content related, it’s to generate email or even to call based on the customer and the issue.  So the support outcome is a function of the overall need, the user, and the organizational business model, not just a query and its results.

  3. Content Fit to Task:  Just finding “relevant information” is not the goal of a service inquiry.  It may be interesting to know all the Mexican restaurants in my town, but figuring out the dial-out codes to get proper roaming access internationally from my phone while in Sweden is not a casual question.  Almost WON’T count.  Support & services information itself must be written with the users in mind and with a focus on helping them navigate towards the answer without the benefit of any more details about their products than they need to get the job done.

  In the final analysis Google has performed an enormous service to the world, and to the support industry:  it’s made the Internet searchable, and provided a clear value proposition for getting good information online.  EVERYONE is interested in achieving more, better self-help.  But searching is only PART of the information definition, access and usage tasks associated with support transactions.

  Google is neither good nor bad – it just is what it is!  Beware of trying to make it more than it should be – a great search tool – and be sure to think through what service actually means and model those processes as best you can in your online tools.  We’re always searching for something better aren’t we?

  John Chmaj
  “The Knowledge Advocate”

   
• 

  Keith Holt 07:00:06 am on October 9, 2008 | 1 | # |
  Tags: Collaboration, Customer Support, future technology, Knowledge Management, search, Self-Service

  I’ve seen the future

  Well it’s October and that means that Halloween is just around the corner. What better time to pull out the crystal ball (which looks suspiciously like a Lava Lamp in my case), put on my swami turban and do my Karnak the Magnificent impression. That’s right, it’s time to predict . . . the . . . future.

  But seriously – a year ago at a self-service conference in San Diego, someone in the audience asked a panel of industry representatives I sat on, “Where do you see self-service in fifteen years?”Fifteen years!? I can’t predict what I’ll have for breakfast tomorrow. I was lucky enough to be the last of four to respond so I had some time to make something up. I didn’t give the distant future much thought after that. That is until last week when I saw the following question on a Request for Proposal (RFP) from a prospective customer: “Where do you see the knowledge management industry in five years?” OK, it’s not fifteen, it’s only five but still that’s a long time in a field so intertwined and interdependent with information technology. Just look at the advances that have been made in computing in general, and search and database technology in particular in the last ten years. Now consider that the rate of advancement is not linear but rather it’s an accelerating curve. There was only one place to turn for insight – science fiction.

  Now understand – I’m a SciFi nut. I have read literally thousands of novels and short stories from every sub-genre and generation of science fiction from H.G. Wells and Jules Verne to David Brin and John Ringo. I just didn’t imagine those fantasy worlds ever intersecting my “real life”. But Verne predicted nuclear submarines and spacecraft landing on the moon. Heinlein predicted both the commercialization and the governmental regulation of space. What do my favorite authors have to say about the use of knowledge in self-service and customer support?

  It didn’t take much searching in my library to find two great examples: William Gibson’s novel Neuromancer (©1984) and Vernor Vinge’s short story Fast Times at Fairmont High (©2001). In Neuromancer, characters have access to knowledge libraries and skill enhancements on a kind of memory stick (called a “microsoft” – no connection to the corporation of the same name) that plugs directly into their brains via a “wetware” implant. Usage of these devices gives the user access to previously unknown facts as if they had been memorized in a more conventional way as well as the ability perform tasks for which they have no previous experience. Maybe that’s a little far-fetched. Maybe that’s what we have to look forward to in the fifteen-year realm.

  Vinge describes capabilities more in the nature of “just around the corner”. His characters, primarily middle-school students, are engaged in the usual day-to-day activities of school, friends, the latest entertainment and interacting with peers all over the world via laser links, broad-band wireless and virtual reality equipment micro-miniaturized right into their clothing. To call up information – text, live or synthetic imagery, anything – or open live interactions with other people, they have merely to make subtle gestures and sub-vocalize commands that are picked up by the wearable computers as input and requests. The visual portion of the output is projected directly into their eyes through special contact lenses. The audio arrives through sub-mini ear-buds. These characters routinely enjoy interactions much more interesting to (and closer to home for) us in the customer support and knowledge management industry. Assigned a programming problem in computer class? Collaborate with a cyber geek in Belarus. Someone uses a word you don’t know in a conversation? A gesture noticeable only by your personal interface calls up a definition with examples and overlays it in your field of view.

  Just imagine a technician servicing a complex medical diagnostic device being able to review a service manual or watch a tutorial video without taking their hands – or their eyes – off the device they’re working on. Imagine an auto service representative being able to hear the noise your car makes only when it’s at least twenty miles from the shop. Imagine your personal system hearing your boss ask you for the latest sales numbers and sensing your request to display them like a queue card so that you appear to have been prepared for the question. Imagine your current checking or credit card balance appearing in your field of vision while your looking at that new gadget at the local electronics store. Imagine . . .

  In a nutshell, that’s the future of support technology and knowledge management. And it could be within that five-year window. It’s the idea that knowledge, information and even transactions are available in real-time, while you’re doing what you need help with, aware of your current context and –most importantly – without you having to leave what your doing to go get it. My twelve year-old daughter told me she saw video contacts just like those in Vinge’s novel on the Discovery Channel last week and she is usually ahead of me on these sorts of things. Now where did I put my Lava Lamp?

   

• Keith Holt 07:00:04 am on September 18, 2008 | 0 | # |
  Tags: efficiency, Knowledge Management, query intent, search

  Once more, with feeling

  How many licks does it take to get to the center of a Tootsie Roll Pop(tm)?  One lump, or two?  If I’ve heard it once, I’ve heard it a thousand times.  We as a intelligent beings are obsessed with numbers.  We always want to know how much, how many  or how few something takes.  I heard once in a course on effective presentation style that a good way to get an audience’s attention was to just list a seemingly random set of numbers on a whiteboard or screen, then fill in the labels to indicate the significance of those numbers as the presentation progresses.

  A number that comes up often in the field of knowledge management is how many clicks it takes to reach a resolution during a knowledge query operation.  There is a well founded concern for efficiency at work here but what is a reasonable number of clicks to find a resolution?  I’ve read requirements for maximums and averages of from five all the way down to one.  I’ve even heard a marketing VP state that their goal for their product was zero clicks which would apparently involve the system answering the query correctly before it’s even asked.

  So while R&D works on precognitive query engines, those of us still on the sunnier side of the Twilight Zone must work with what we have available.  Not that we have to give up the farm but most things worth doing involve compromise and trade-offs.  Give a little in one area to get a little in another and you can end up with a much more robust and valuable solution.  In the case of searching and querying knowledge management repositories the trade-off I propose is to accept the fact that the typical query of knowledge is a two-step process.  (Numbers again.)  It might be difficult to give up on the ideal of jumping straight to the answer but let’s try starting with just finding the question in the knowledgebase first.  A searcher has the following advantages working for him or her when searching for a question:

  • The searcher knows more about the question than anything else.
  • If anything at all is known about the answer that knowledge is likely vague and possibly inaccurate.
  • The searcher is more likely to recognize the question when they see it appear in a list of search results.
  • Even if the initial query results in the best answer being at top of the list, it might as well not exist if the searcher doesn’t recognize it when they see it.
  • Once a matching question has been found, there will likely be a small number of matching answers to consider – the searcher will have to evaluate only those answers matched to the selected question instead of every answer that matches their query in some obscure way.

  Just to be clear, I’m using the term “question” here in a somewhat generic way.  It might be a literal question for which exists a known answer.  It might be a goal the searcher needs to accomplish for which their exists one or more processes that reach that goal.  It might be a symptom or an error message that the searcher might encounter while using some product or service.

  Imagine a scenario where the user inputs their question, goal or symptom as a query to the knowledgebase – the first click.  The available targets and potential search results for that query are in question, goal or symptom form so, with even a nominal degree of natural language processing, there is likely to be a good match.  That match, highly ranked, is presented as a search result and, because its author has been careful to use the voice of the customer, the searcher recognizes it as being relevant to their quest and clicks it – that’s two.  Now, in the special case where there is only one possible answer or resolution for the selected question, the user is done – two clicks total.  There might be more than one possible resolution to consider but it will be a relatively small set to evaluate and the searcher will have more confidence that the correct resolution is findable because of their initial success in finding a match to their question.  There might even be additional assistance in the form of tagging or clarifying questions to help the searcher select the best answer – one or two more clicks.

  So on that trade-off we talked about earlier we’re up to from two to four clicks to get to the answer.   But on the gain side of the equation, there should be much more consistency in those numbers as we avoid the somewhat common scenario where the searcher clicks through several answers trying to find one that addresses their issue or leads toward their goal.  And the worst case scenario is that the searcher’s question is not in the knowledgebase at all.  This isn’t as bad as it sounds though because the best way to fail in a search is to fail quickly and cleanly – confident that there’s nothing hiding in the content.  And we will have captured in the logs the question that’s missing so it will be relatively easy to evaluate what if anything should be added to the knowledgebase.  And there’s still plenty of room for automation to (for example) filter any available solutions according to something known about the searcher or their context – subtract one click.

  I admit it’s a bit of a departure from the typical approach to searching knowledge.  Leave a comment and let me know if you’ve tried it – or if you’re willing to give it a try.

   

• Keith Holt 07:00:43 am on July 22, 2008 | 0 | # |
  Tags: Customer Support, Knowledge Management, search, tagging content

  Have we found what we’re looking for?  It’s similar to the well-known question, “Are we there yet?”.  You can’t answer the latter until you know where you’re going and you can’t answer the former until you know what it was you were searching for in the first place.  Of course I’m talking about knowledge management, specifically as it relates to customer support, in this case and not the meaning of life or a lost TV remote (by the way, if anyone has a tip on either of those please let me know).

  What I’ve seen in my 13+ years of experience working with knowledge management tools is that there has been  a lot of attention given to search – the “search engine”, indexing, processing of queries and rendering search results – but very little if any thought to what is being searched for.  At this point you may very well be thinking or even poised over the keyboard to write the comment, “It’s obvious what we’re searching for – the answer to a question, the solution to a problem.”  Really?  That is, I agree, usually the goal of the search but it is not, can not be, literally what we’re searching for, the query that’s entered into the search field.  After all, if we knew the answer or solution well enough to search for it effectively in the first place, we wouldn’t be going to the support site or calling the support center in the first place except for the special case of just needing the details to an already identified solution.

  Now I’m not attacking search or trying to downplay its importance in knowledge management and customer support.  But the best search engine imaginable will be of little use unless it is guided and targeted by consistent structure in the content.  This structure must go beyond “tagging” content with topics.  It’s not enough to say an article is “about Product X” or “about Installation”.  The particular questions that an article answers or the particular problems that a solution addresses must be explicitly listed.  Those lists must be given priority when searching because a match in such a list to a customer’s question or problem description will have the highest value.  Then the features and capabilities of a great search engine – for example, the ability to give a correct match to a query even when an alternate way of stating a concept is used – will have the most positive effect on the outcome of the search.

  Think about how search is usually tested and evaluated.  The tester typically starts with knowledge of the content and has in mind a particular item that they want to try to retrieve.  Then they enter a variety of searches that more or less specificly match that item’s title or some text in its description.  If the item is ranked with a high score when the search is more specific, lower as the queries grow less specific and the item disappears from the search results list when there are no matching terms in the query then search is considered to be working properly.  Instead, think about testing search strictly from the perspective of the customer – What questions are they likely to ask?  What problems are they likely to describe?  Search should be considered successful only if items directly addressing the problem or specifically answering the question are ranked highest or are the only results returned.  Items that merely mention the query terms, even if they do so exactly – but do not specifically address the customer’s issue should be ranked lower if an item that does specifically address the issue is available.

  It’s a higher standard of success and, yes, it takes more effort to markup articles for this approach but it is the only way to get better customer support results from a good search engine.

   

• Keith Holt 08:00:43 am on July 1, 2008 | 0 | # |
  Tags: content, content management, knowledge, Knowledge Management, recognition, relevancy, search

  And what’s the difference, anyway, between Content Management and Knowledge Management?

  A little theory and some practical examples are needed to help define and distinguish between Content Management (CM) and Knowledge Management (KM).

  First consider how CM and KM are similar.  Both types of technology . . .

  • Support the creation and maintenance of content of virtually any size
  • Provide some means of controlling who may create or edit content
  • Support routing new and changed content through an approval cycle
  • Provide an interface to search for and find content based on some form of full-text index. (Some or all of various search methodologies may be supported – natural language, keyword, Boolean, etc.)
  • Provide means of controlling who may view content

  Other similarities may exist but those are enough to work with for now.  So what differences are there?

  • CM systems tend to provide more control over not just the content itself but the style of the content – style guides that streamline the creation of standard documents with business rules to enforce adherence to established styles over large quantities of documents and large groups of authors.
  • CM systems typically include the capability to publish content in portable formats, such as PDF, and/or print in professional layouts.  Content in and of itself is something of a product of the system and the content, once produced, can exist and be used apart from the system in which it was created and maintained.

  While perhaps not obvious at first, this last difference holds a clue to the key argument for needing a Knowledge Management system.  Once created, content can be used apart from a Content Management system because the system offers little or no assistance in using that content.  In fact, we expect so little (and are offered so little in this respect) that we don’t even miss it.  When’s the last time you read an owners manual or the safety placard in the seat-back pouch of an airliner and wondered, “What Content Management system was used to produce this document?”

  So what’s missing?  What is needed when “using” content that is not provided by the Content Management system that did such a good job in producing the content in the first place?  One word sums it up – relevancy.  Which document, and which part of that document, is relevant to my situation – and under what circumstances?

  It’s time to take a closer look at some terms that we’ve been using without asking whether we have a good – or at least a full – understanding of their meaning.  Words like “search”, “find” and even “knowledge” get used freely, especially in our industry, but what do we really mean and what expectations do we have when we speak, hear or read them?  Now entire doctoral theses have been written on the meaning of knowledge, technical white papers weighing several pounds have been produced on various search methods.

  There’s no intention to go to that level here.  But all we need do to start is to develop an understanding of some key concepts that explains how a Knowledge Management system offers assistance not provided by Content Management in determining the relevancy of content.  For our purposes, let’s start to think of these key concepts in a certain light and frame their definitions in such a way to draw out the importance of relevance.

  • Search – to look for a piece of content with the intention of answering a specific question or solving a specific problem.
  • Find – what happens when a search engine matches a piece of content to a user’s search and when that user recognizes that piece of content as relevant to their intent or need.
  • Knowledge – what content becomes when it is able to be found when searched given the provided definitions of the terms “search” and “find”.

  The importance of the highlighted terms in these definitions must be understood if we’re to build a compelling case for Knowledge Management providing relevancy and that relevancy being of value.  Of particular importance is the term “specific”.  The need for specificity is where Content Management starts to fall short.  If the user wants to read everything available on the history of credit in commerce, or some similarly general topic, then a Content Management system with a basic search engine will supply the need quite well.  But if that person needs to know what, if any, benefit or penalty there is if they payoff their credit balance early they had better be ready for a research project if all they have is the Content Management system that produced their Cardholder Agreement and a search engine.

  In conclusion (for now) Content Management systems can serve as excellent sources of content for Knowledge Management but they can never deliver the same results and value – the turning of that content into usable knowledge – without the addition of a good Knowledge Management tool and methodology.  They should never be considered as one versus the other but rather as different tools with different needs serving an organization in complimentary ways.

   

•  

  November 2009

  M	T	W	T	F	S	S
  « Oct
  						1
  2	3	4	5	6	7	8
  9	10	11	12	13	14	15
  16	17	18	19	20	21	22
  23	24	25	26	27	28	29
  30

• Search for:

• Pages

  • About

• Blogroll

  • Church of the Customer
  • CRM Mastery
  • Customer Experience Crossroads
  • Customers Are Always
  • Customers Rock!
  • First Coffee
  • Jive talks
  • Marketing 2.0
  • Ragsdale’s Eye on Service
  • The Invisible Crowd
  • Think Customers
  • WordPress.com

• eVergance

  • Contact info
  • Home page

• Industry resources

  • CIO.com
  • CRM Magazine
  • CSI
  • SearchCRM.com

• Tags

  best practices CEM Collaboration Communities content management CRM Customer customer acquisition customer acquisition costs customer centric Customer Experience customer experience management customer loyalty customer relationship management customer satisfaction customer service Customer Support efm email enteprise feedback management enterprise feedback management erms Experience experience management feedback Feedback Management forums Kana KM knowledge Knowledge Management LinkedIn loyalty process satisfaction scorecard search Self-Service service experience SSPA strategy surveys user generated content Voice of the Customer Web 2.0

• Recent Comments

  • Hype or Hyper-Measurement? « KANA Global Consulting Services Blog on Evidence Based Service-The How is harder than the Why
  • Hype or Hyper-Measurement? « on Evidence Based Service-The How is harder than the Why
  • Chill on Customer Support Myths…Or are they really myths?
  • kate leggett on Customer Support Myths…Or are they really myths?
  • Esteban Kolsky on Customer Support Myths…Or are they really myths?

• Blog at WordPress.com
  Prologue theme by Automattic