Search-failure investigation log
Turn failed help searches into a documented diagnosis, one focused change and a retest, without confusing article views with customer resolution.
A customer who cannot find an answer may need a better title, a missing permission, a corrected policy or a genuinely new article. Writing another page before diagnosing the failure can add another result to the wrong search.
Use this log after a knowledge base health audit identifies a high-value problem. Work on one cluster of related customer goals at a time. Preserve enough evidence to reproduce the search while removing personal information and secrets from copied query strings.
1. Define the question
Choose a task the customer is trying to finish, not just a popular word. “Change billing email without changing login” is more specific than “email.”
| Investigation field | Fill in |
|---|---|
| Customer task and affected audience | [goal / product / locale / account state] |
| Query cluster | [customer phrases / redacted error terms] |
| Evidence window and source | [dates / approved log or observed sessions] |
| Sampling method and sample size | [selection / number of sessions] |
| Expected answer and canonical owner | [article or answer / owner] |
| Actual result | [no results / wrong rank / wrong content / inaccessible] |
| Impact and priority | [blocked task / uncertainty / observed repeat effort] |
| Investigator and review date | [name / date] |
Keep “no results” distinct from “no usable answer.” A query can return many results and still fail the task.
2. Reproduce before editing
Run the customer's words in the intended locale, account state and interface. Record the first results, the opened article, whether the instructions apply, and whether the task can be completed. Try the common variation that changes the meaning; this catches changes that help one query while damaging another.
| Query / task | Customer context | Results and positions | Article applicability | Task outcome observed | Evidence / date |
|---|---|---|---|---|---|
| [phrase] | [locale / access / version] | [titles / order] | [current / wrong scope / blocked] | [completed / blocked / unknown] | [test record] |
A staff account may see answers customers cannot. Reproduce access constraints rather than assuming that an internal successful search closes the issue.
3. Classify the cause
| Suspected cause | Evidence to seek | Small first intervention |
|---|---|---|
| Missing answer | No approved source covers the task | Assign a subject owner to supply a verified answer |
| Vocabulary mismatch | Correct answer exists under different terms | Revise title or add customer language and synonyms |
| Ranking problem | Relevant answer exists but misleading results lead | Test metadata, duplicate removal or a scoped ranking change |
| Stale or conflicting content | Current policy differs from retrieved guidance | Correct the canonical answer and retire contradictory derivatives |
| Access or locale problem | Answer is hidden or unavailable to intended users | Repair permissions or localization with the accountable owner |
| Answer unusable after discovery | Reader finds it but cannot follow or verify success | Observe the task and repair missing steps or prerequisites |
These are working diagnoses. Record evidence against your first theory too. Avoid changing titles, ranking, navigation and article content together if a smaller experiment can identify the cause.
4. Copy the change and retest log
| Hypothesis | Baseline tasks / observations | Single change | Release / owner | Retest tasks / observations | Other changes or limitations | Decision |
|---|---|---|---|---|---|---|
| [cause → expected effect] | [same task set / evidence] | [specific edit] | [version / name] | [date / results] | [mix / access / sample] | [keep / revise / revert / investigate] |
Choose the observation window before looking at results. Use matching tasks for a controlled usability check and describe any differences in live traffic. A change in searches or contacts could reflect demand mix, product releases or instrumentation, not your edit alone.
5. Fictional worked example
The following cases and counts are invented; they illustrate different diagnoses.
| Query | Finding | Intervention | Retest |
|---|---|---|---|
| “card charged twice” | Current duplicate-charge article appears below unrelated payment setup | Add the customer phrase to its title; keep policy unchanged | Repeat the same three query variants and inspect applicability |
| “cancel second shipment” | No approved procedure covers an already released shipment | Assign fulfillment owner; publish an honest escalation path after approval | Confirm the path reaches a capable owner |
| “download invoice French” | Article exists but the customer locale cannot retrieve it | Repair the locale relationship | Repeat with a French customer test account |
For the first case, an observed test changes from two of five participants finding the applicable answer to four of five. Report exactly that small test result. It is not a claim that self-service resolution doubled across the customer base. Record the remaining failure and its cause.
6. Finish with an owned decision
Link the change to the original query cluster. Give unresolved work an owner and a date, retire any superseded answer safely, and add the task to a small regression set. The knowledge manager role guide explains who governs this cycle while subject owners remain responsible for factual correctness.
Sources and limits
The Consortium for Service Innovation explains capturing the requestor's context and search technology for KCS. This is an original investigation worksheet informed by those practices. Query counts, clicks and article views are diagnostic signals; none independently establishes that a customer completed the task. Respect access and retention rules when handling query evidence.
Continue exploring