Quick answer
Define the eligible population first, then take a census or documented sample of 100 tickets. Redact to the minimum necessary view, split tickets into traceable issue units, replay knowledge search for the intended audience, assign one of five primary outcomes, cluster by reusable task and resolution, review counterexamples, prioritize specific actions, and measure after release.
Five knowledge coverage outcomes
| Outcome | Evidence | Typical action |
|---|---|---|
| Covered and found | Accessible article is found and tested answer is adequate | Reuse, monitor, flag or fix during use |
| Covered but not found | Adequate article exists but queries, labels, language, index, or navigation fail | Improve discoverability, metadata, links, search, or translation |
| Partial or outdated | Article is relevant but incomplete, inaccurate, stale, inaccessible, or wrong for current version | Update, split, merge, validate, translate, or restrict |
| Missing article | No suitable reusable knowledge exists after reproducible search and review | Create with owner, audience, evidence, and acceptance criteria |
| Not suitable for self-service | Needs identity-specific, live, dangerous, regulated, or specialist handling | Keep agent-assisted; publish safe routing or preparation only |
Three validity tests before calling something a gap
Selection validity
Can another analyst recreate which 100 tickets were eligible and selected? If not, frequency and coverage statements are unstable.
Search validity
Was the intended audience, exact query, permissions, language, index, results, article version, and answer test recorded? One failed query is insufficient.
Decision validity
Does the proposed action solve a reusable need, and did a reviewer check counterexamples, risk, ownership, effort, and acceptance? Volume alone is not priority.
Nine-step analysis of 100 support tickets
Execute the steps in order because later judgments depend on earlier scope, privacy, unit, and search evidence. The number 100 improves auditability; it does not remove sampling error or bias.
Define the decision, population, and review window
Method
State what the analysis will decide: create, improve, merge, archive, re-index, translate, or restrict knowledge. Define eligible support channels, products, languages, customer segments, ticket states, and a fixed received/resolved window before looking at examples.
Evidence to retain
decision question; population definition; included/excluded channels; products and versions; languages; ticket states; start/end and time zone; analysis owner; selection rule; known blind spots.
Acceptance gate
The scope can be reproduced from source systems. Excluded tickets and unavailable channels remain visible as limitations; the team does not generalize from 100 selected records to all customers without a defensible sampling basis.
Select 100 tickets without cherry-picking
Method
Use a full census when only 100 tickets meet the scope; otherwise draw a documented representative or stratified sample. Preserve selection order and inclusion probability. Do not choose only escalations, long tickets, recent failures, easy examples, or records the analyst already remembers.
Evidence to retain
eligible population count; sampling frame export/hash; census or sample method; random seed or deterministic order; strata and allocation; replacements; duplicates; inclusion/exclusion reason; selected ticket IDs in a restricted crosswalk.
Acceptance gate
Exactly 100 distinct eligible tickets are accounted for, or the page reports why fewer were available. Compare the sample with the population on known dimensions and disclose material imbalance; weighting is documented rather than invented after results are seen.
Minimize, redact, and separate sensitive ticket data
Method
Create an analysis view containing only fields needed for the knowledge question. Remove or tokenize names, contact details, credentials, payment data, secrets, health or employment details, security artifacts, and free-text fragments that are not necessary. Keep re-identification keys in a separately authorized system.
Evidence to retain
field inventory and purpose; data owner; lawful/contractual basis where required; redaction/tokenization rules; access role; source-to-analysis crosswalk; retention/deletion date; quality checks; security/privacy escalation route.
Acceptance gate
Analysts and models receive the minimum necessary view, redaction is tested on a sample, source records remain unchanged, and restricted cases can be excluded or reviewed by specialists without leaking their narratives into clusters or articles.
Normalize issues while preserving requester language
Method
Split multi-issue tickets into answerable issue units. Preserve the customer’s original symptom words separately from the analyst’s normalized concept; record product, version, environment, task, expected/observed result, resolution, and whether the issue was substantiated. Do not merge merely similar wording.
Evidence to retain
ticket and issue-unit IDs; original phrases; normalized intent/entity; product/version/environment; expected/observed; resolution/workaround; root cause if verified; tags; analyst/model version; split/merge rationale; confidence and counterexample.
Acceptance gate
Every unit can be traced back to its ticket, customer wording is not overwritten, separate issues remain separate, and normalization uncertainty is explicit. A human reviews low-confidence, multilingual, specialist, or high-impact units before clustering.
Replay the knowledge search for each issue
Method
Search the same knowledge surface the intended user or agent could access at the relevant time. Record the exact query, filters, language, role, product context, index version where available, ranked results, opened article, and whether the answer was findable without prohibited access. Test customer phrases as well as internal terminology.
Evidence to retain
search actor and permission; surface; query and language; filters/context; search time; result IDs/ranks; article version/state/audience; click/open evidence; linked article used in the ticket; search failure/error; analyst judgment.
Acceptance gate
Each coverage judgment has reproducible search evidence. Analysts do not mark an article missing because one query failed, nor mark it covered because an internal-only article exists for a customer audience. Search availability and answer adequacy are evaluated separately.
Classify one of five coverage outcomes
Method
Assign the issue to covered-and-found, covered-but-not-found, partial-or-outdated, missing-article, or not-suitable-for-self-service. Base the decision on intended audience, findability, task completion, accuracy, freshness, permissions, and risk—not article-title similarity. Preserve secondary findings when more than one action is needed.
Evidence to retain
coverage outcome and definition version; candidate article/version; audience/access; query evidence; answer steps tested; accuracy/freshness check; missing element; risk/specialist restriction; reviewer; rationale; confidence; next action.
Acceptance gate
The five categories are mutually exclusive for the primary outcome, yet related improvement actions can coexist. “Not suitable” requires a reason such as identity-specific, dangerous, regulated, live-state, or specialist work; it is not a bin for inconvenient cases.
Cluster evidence and test counterexamples
Method
Group issue units by the same customer task and reusable resolution, not merely keywords, sentiment, team, or product area. Compare candidate clusters with counterexamples that look similar but need different answers, permissions, versions, or owners. Preserve cluster membership and rejected merges.
Evidence to retain
cluster ID/version; inclusion rule; representative customer phrases; reusable task/resolution; member issue IDs; similarity signals; counterexamples; split/merge decisions; language/product/version boundaries; human reviewer; unresolved items.
Acceptance gate
Every cluster has coherent actionability and a documented boundary. One ticket can contribute multiple issue units, but the denominator remains tickets when reporting ticket coverage. AI suggestions stay proposals until a knowledge-domain reviewer confirms, refines, splits, or rejects them.
Validate gaps and prioritize an evidence-backed backlog
Method
A knowledge-domain reviewer checks source tickets, search evidence, candidate articles, counterexamples, and specialist restrictions. Score priority using documented reach, customer/task impact, recurrence, risk, strategic importance, confidence, effort, dependency, and content owner capacity. Keep each input separate instead of hiding judgment in one AI score.
Evidence to retain
validated cluster/outcome; distinct tickets and eligible-population denominator; affected task; impact/risk; recurrence window; confidence; effort/dependencies; existing article action; owner/reviewer; acceptance criteria; priority rationale; review date.
Acceptance gate
Backlog items specify create, improve, merge, re-index, translate, archive, product fix, or keep agent-assisted. High volume alone does not win; severe low-frequency gaps and easy high-frequency cosmetic edits remain distinguishable. Conflicts receive human adjudication.
Ship, measure use and effectiveness, and repeat
Method
Publish or update through the normal content standard, technical review, accessibility check, permissions, translation, versioning, and rollback process. Link the article to the contributing issue cluster, monitor search and use, sample whether the content actually helps complete the task, capture flags and corrections, and run the analysis again on a comparable window.
Evidence to retain
article/action ID and version; approvals; accessibility and specialist checks; publish/audience/index state; cluster links; search impressions/queries where available; use/reuse; task-success review method; failed or abandoned use; corrections; next analysis window.
Acceptance gate
A backlog item closes only when the intended action is delivered and verified, not when a draft exists. Search, click, reuse, deflection, resolution time, and ticket change are interpreted with denominators and confounders; no causal improvement is claimed without a suitable design.
Illustrative case: “login help” is two different gaps
This hypothetical example demonstrates the method; the counts are not OpenMax results. Twelve of a selected 100-ticket sample mention login or SSO. A clustering model proposes one “authentication article missing” gap. Human review rejects that merge.
- Replay search. Eight issue units use phrases such as “new phone,” “lost codes,” or “cannot pass verification.” A current recovery article exists but ranks only for the internal phrase “MFA reset.” These are covered-but-not-found, not missing.
- Check counterexamples. Four units concern SCIM-provisioned users receiving a specific post-deployment error. The recovery article cannot resolve it, and access requires tenant-specific investigation. Three share a verified configuration defect; one has a different identity-provider mapping.
- Split actions. Backlog action A improves recovery article titles, customer phrases, links, and search synonyms. Action B creates a restricted agent runbook for the verified defect and safe customer-facing routing. The mapping case updates an existing integration article.
- Preserve denominators and uncertainty. The report says 12 of 100 selected tickets, not “12% of all customers.” It records selection scope, issue-unit count, search evidence, confidence, and the next comparable review window.
How to operate and measure the learning loop
Roles and independence
Assign a sample owner, privacy/security reviewer, issue coder, search evaluator, knowledge-domain reviewer, content owner, accessibility/localization reviewer, and measurement owner. Do not let the model that clusters issues be the only evaluator of its clusters.
Metrics with denominators
Report selected tickets, issue units, distinct clusters, outcome counts, reviewed disagreements, backlog actions, delivered actions, article use, task-success samples, corrections, and repeat-window results. Keep ticket, issue-unit, search, user, and article denominators separate.
Failure and recovery tests
Test biased samples, duplicate tickets, redaction leaks, multilingual splits, wrong merges, inaccessible or internal-only articles, stale versions, search outages, reviewer disagreement, owner absence, failed publication, index delay, and rollback.
Minimum auditable analysis record
analysis_id · decision_question · population · window · sampling_frame · selection_method · ticket_crosswalk · redaction_version · issue_unit_id · customer_phrases · normalized_issue · search_actor · query · result_ranks · article_version · coverage_outcome · cluster_id · counterexamples · reviewer · priority_inputs · backlog_action · owner · acceptance · publish_version · effectiveness_method · next_window
How OpenMax can coordinate knowledge-gap analysis
OpenMax can freeze a documented sampling frame, create a minimized analysis view, split and normalize issue units while preserving customer phrases, replay permitted searches, propose coverage outcomes and clusters, surface counterexamples, request domain review, create owned backlog actions, and monitor delivery and repeat-window evidence. Humans retain privacy, specialist, cluster, priority, and publication decisions.
Sampling, privacy, and causal-interpretation boundaries
- Do not claim that 100 tickets represent all customers, channels, languages, products, or time periods unless the sampling design supports it.
- Do not expose customer identities, credentials, payment details, sensitive narratives, security artifacts, restricted investigations, or unnecessary raw text to models, analysts, or articles.
- Do not let similarity scores merge different permissions, versions, root causes, remedies, audiences, or affected people; preserve counterexamples and human review.
- Not suitable for self-service is a safety and service-design decision, not evidence that the customer is difficult or the issue lacks value.
- Search, clicks, reuse, deflection, resolution time, ticket volume, and satisfaction are different measures. Do not claim causal improvement without an appropriate comparison and confounder analysis.
Frequently asked questions
Is 100 tickets statistically representative?
Not automatically. Representativeness depends on the eligible population, selection method, strata, missing channels, imbalance, and intended inference. Treat 100 as a transparent review unit.
Does no search result mean an article is missing?
No. Test alternative customer phrases, permissions, language, filters, index health, navigation, and candidate articles before assigning a missing outcome.
Can one ticket produce several issue units?
Yes. Keep every unit linked to the source ticket, but use the correct denominator when reporting issue versus ticket coverage.
Should every frequent issue become self-service content?
No. Some require identity-specific, live, dangerous, regulated, or specialist handling. Others are better solved through product or process changes.
How should gaps be prioritized?
Keep reach, task impact, recurrence, risk, strategic importance, confidence, effort, dependencies, and owner capacity visible. Do not collapse judgment into volume or one opaque score.
What can OpenMax automate?
It can coordinate sampling, redaction, issue units, search evidence, proposals, review, backlog ownership, publishing handoffs, monitoring, and repeat analysis while people retain consequential judgments.
Sources, editorial method, and limitations
OpenMax editors reviewed the Consortium for Service Innovation KCS v6 Practices Guide, including reuse, improvement, article structure, and knowledge-domain analysis; the NIST AI RMF Core for documented selection, representativeness, measurement, monitoring, and independent review; and W3C WCAG 2.2 for accessible content and interaction. We synthesized the original nine-step workflow, five-outcome model, and illustrative login case. Sources were rechecked September 3, 2026.
- Consortium for Service Innovation — Knowledge Domain Analysis
- Consortium for Service Innovation — Reuse is Review
- Consortium for Service Innovation — KCS Article Structure
- NIST — AI RMF Core
- W3C — WCAG 2.2