Home > Retired: KCS Practices Guide v5.3 > Section 2 KCS Practices and Techniques > The Solve Loop > Practice 1: Capture > Technique 2: Capture the Customer's Context

Technique 2: Capture the Customer's Context

Table of contents

With KCS, we seek to understand the customer's experience before solving. This understanding requires information about both the perceived issue (in the customer's words) and the environment in which the problem is occurring. By capturing the customer's perception of the situation in the first interaction, we dramatically improve the findability and relevance of the KCS article to other customers who might have the same or similar perception of this issues in the future (context is as important as content).

 

capturecontext.jpgThe objective of capturing KCS article elements is to "frame" the customer's situation—to capture their need, perception, experience, and relevant aspects of their environment as input to the problem-solving process. The objective is to use this input to improve the KCS article set. We use the framing information to either create a new KCS article if one doesn't already exist or to improve an existing article by reflecting another customer's experience.

 

 

Even if the customer's perception of the situation proves to be wrong, preserving it will improve the findability of this article for other customers. The Support Analyst's job is to capture with precision and accuracy the relevant environment factors, the resolution, and the cause in the article, not to correct the customer's description of the problem. However, Analysts may capture additional technical details to more precisely characterize the problem.  Technical accuracy in the problem statements is not required.  Of course, technical accuracy is critical in the environment, resolution and cause statements.

 

Some of today's knowledge tools enable the capture of the customer's online search activity before they contact us for help. Having the words and phrases the customer used to search is very useful - this is their context. The customer's search terms can be used to create the problem statements in a new KCS article, if one doesn't already exist, or can be used to modify an existing article and improve its findability.

Every Search Matters

In the case of incidents submitted via a self-service model, good things can happen if we capture the customer self-service activities (search strings, articles viewed, and in some situations product and version information). First of all, this guarantees that we are capturing the customer context, and secondly, making this information available to the Support Analyst helps the customer feel like the effort spent pursuing a resolution through self-service was not a waste of time (no dead ends).  This information can help expedite the problem-solving process as we can review what the customer has already done. 

 

Customer submission of issues via self-service also helps us create new or modify existing articles. If we need to create a new article for this issue, the search words and phrases the customer used to look for a resolution are valuable content for the new article.  If, as the KCS practices suggest, we have captured the information the customer used to search the web in a Work-in-Progress (WIP) article as we were working the issue, we have already created a new article and simply need to review the environment statements and update the resolution field. Because the problem statements came from the customer search activity they are in the customer's context.

 

If, in working on the issue, we eventually find an article in the knowledge base, we should improve that article so customers can find it. We have already captured the information in the Work-in-Progress (WIP) article, which we can use to update and improve the findability of the existing article.  If the existing article was available to the customer but not findable, we use the customer experience (and their context) to improve the findability of that article. If the existing article was not available to the customer, can we publish it?  Are we licensed to publish, are we confident in the resolution, and is the article compliant with the content standard?  See the Content Health section for more on article states and transitions.

Viewing 5 of 5 comments: view all
Hi,

I have 3 questions around customer context.

In referring to capturing customer context, is this word for word on their phrases or comments?

As with every problem being different, is there an guideline on how to capture customer's context, in the sense of capturing word for word for each situation?

Or, are we paraphrasing what the customer says?

Would really appreciate an answer to this.
Posted 21:07, 19 Jul 2015
Do not capture word for word, capture complete thoughts not sentences.

The same problems can have different symptoms. It is important to capture the symptom the users experienced because that's what they will search for. It is ok to have several issues/symptoms in the same article

For example: The user may describe the issue as "The right side of my head hurts when I am swimming in the Atlantic ocean.

KB Article
Issue: Right side of head hurts when swimming
Environment: Atlantic Ocean

Another user may describe the issue as " I have headache after surfing on Cape Cod.

The same article could be updated to contain:

KB article
Issue: Right side of head hurts when swimming
Issue: Headache when surfing
Environment Cape Cod
Environment: Atlantic Ocean
Posted 05:35, 20 Jul 2015
Ok, so when phrasing what the customer has said, doing it word for word is the best approach?

Even though it may be technically inaccurate, but as long as we capture their "context" (i presume how they interpret their problem) we're doing the correct thing?
Posted 17:57, 20 Jul 2015
Until the problem is solved you don't know if there description is technically accurate or not. It is best to capture it in the workflow as stated. Then let the flag-it or fix-it take care of something that is technically inaccurate.
Posted 04:25, 21 Jul 2015
I find people easily catch on to the idea of including the technical specifics in an article. Then a little less easily they catch on to adding customer context when they create an article. Going the third step - ie modify existing articles to include new customer context, is the hardest of the 3 for people to catch on to. It has to be communicated many times before people here the message. This isn't because the idea is difficult - its mostly a listening issue. When they hear "modify the article to..." their mind immediately completes the sentence with "...improve technical accuracy" and they completely miss thst you are actually saying "...to add aditional customer context.". Then after someone has actually heard - when it comes time to do it they discount the value of doing it beacuse its so easy ("...well that seemed trivial, I didn't think it was worthwhile to add it - but I did make these really technically indepth changes...") It was a surprising phenomenon when I first encountered it I think its because of the mindset of support analysts is heavily biased to "technical details" being important (which they are), that things like customer context seem unimportant (which it isn't). Once they see the way these seemingly unimportant words and phrases improve article findability - then the penny drops and they start doing it consistently.
Posted 14:00, 17 Feb 2016
Viewing 5 of 5 comments: view all
You must to post a comment.
Last modified
12:09, 15 Oct 2013

Tags

This page has no custom tags.

Classifications

This page has no classifications.