Practice KCS: turn support work into trusted, reusable knowledge

Knowledge-Centered Service (KCS) makes knowledge part of resolving an issue. Search before starting from scratch, capture what you learn, improve what already exists, and have the right people review it. Supportbench connects this work with cases, articles, and supported AI-answer review so the next agent can start with evidence instead of repeating the investigation.

Your learning path  ·  Set up responsibilities and access  ·  Search before creating  ·  Capture a useful article while the evidence is fresh  ·  Review the answer, not just the wording  ·  Publish and verify  ·  Use Knowledge Quality to improve AI answers  ·  Make improvement part of daily work  ·  Follow one resolved issue through the KCS loop  ·  Share responsibility without making knowledge somebody else’s problem  ·  Common problems

Your learning path

KCS is an operating practice, not a promise that every article or AI answer is automatically correct. Decide who may draft, review, and publish, and make those responsibilities part of onboarding.

Set up responsibilities and access

Article creation, editing, review, publication, and Knowledge Quality permissions are separate capabilities. Your role, division, account policies, enabled features, and review-group configuration determine the actions available. An agent who can assess an AI answer may still need an author or administrator to change the article or bot settings.

• Use an article template that prompts for the problem, environment, verified resolution, and confirmation steps.
• Agree who owns technical review and who checks customer suitability. A specialist may validate a workaround while a knowledge reviewer checks clarity and visibility.
• Configure review groups and review dates for information likely to change. Assign ownership to someone who can actually maintain the content.
• Keep internal procedures internal. Publishing a useful solution does not justify exposing customer names, case messages, credentials, internal URLs, or private attachments.

Search before creating

1. Search the knowledge base using the customer’s symptom, product term, and distinctive error wording. Try the terms another agent or customer would use.
2. Read the whole candidate article, not only the search preview. Check the relevant version, environment, prerequisites, and limitations.
3. Apply the procedure only when it fits the case. Verify the result and record any important difference.
4. If the answer is useful but incomplete, improve or flag the existing article rather than creating a competing answer. If it solves a distinct task or environment, create a separate article and link the relationship.

Capture a useful article while the evidence is fresh

1. Use Create Article in the knowledge base, or an available create-article action from the work you are handling. Check for an existing article before generating or copying a draft.
2. Write a title describing the task or symptom. Add a concise Summary explaining what the reader will learn.
3. State who the procedure is for, when it applies, required access, and what the reader should have ready. Use numbered steps with current control labels.
4. Include the expected result and a way to verify it. Separate a confirmed cause from a hypothesis, and a temporary workaround from a permanent resolution.
5. Choose the appropriate Division, Visibility, Topics, and Tags. If the field is available to your role, add article-specific Search keywords for useful alternate phrasing. Topics organize content; they do not override audience restrictions.
6. Review files, screenshots, and links for accuracy and private information. A screenshot should support the written procedure, which must still make sense without it.
7. Choose Save as a Draft while the work is incomplete. Use the review or publication action available to your role when the draft is ready. Do not assume saving a draft publishes it or emails a manager.

Review the answer, not just the wording

Use the article’s review workflow and configured review groups. Available actions can include assigning work back to the submitter and finalizing publication. Follow the displayed role-dependent action; do not work around review by copying a draft into a new article.

Publish and verify

1. Confirm the article is complete and choose the permitted publication action, such as Finalize & Publish. Review Version summary and Publish on, including the displayed timezone. A blank publication date means immediate publication where the action permits it.
2. Choose subscriber notification deliberately. Notify subscribers is an opt-in for article/topic notifications; routine corrections may be better published quietly.
3. Open the saved article in the agent reader. Check formatting, links, media, and the final content.
4. For an external article, test it as the intended customer audience. Published workflow state, External visibility, active public topics, portal inclusion, and customer restrictions are separate considerations.
5. Search for the article using realistic symptom wording and its title. Make sure the current answer can be found before retiring an older replacement.

Use Knowledge Quality to improve AI answers

Where enabled for your account and role, Knowledge Quality provides Review, Improvements, and Insights for supported answer surfaces. This is distinct from an article’s ordinary review and publication workflow.

1. In Review, select the relevant channel, such as Chatbot or Portal Quick Answers, and the applicable widget or portal and date range.
2. Open a question and read the exact answer and source evidence. For Chatbot, review the earlier bot conversation when captured; Portal Quick Answers instead records the question, answer, and presentation activity. Judge the answer against that evidence.
3. When you have review permission and the item has a supported answer outcome, grade it Good, Partially correct, or Poor. Other outcomes may be inspected without assessment controls. For a partial or poor answer, select a Primary reason, such as knowledge gap, outdated, retrieval, grounding, context, presentation, ambiguous, technical, or other. Add useful review notes and Save assessment.
4. After saving a Partially correct or Poor assessment, choose Start an improvement when correction is needed. Available paths include Improve article, Create article, Review bot settings, and Create case. Link an existing improvement when the work already has an owner.
5. Make the correction through its normal authoring or configuration workflow. Retest when your role and the surface support it, then record what changed and the verification result.

Make improvement part of daily work

Use review dates to revisit volatile content. The article’s Review settings can specify a next review date and a configured expiry action, such as Do nothing, Assign to expired queue, Assign to author, or Archive. Choose an action suited to the operational risk; automatic archiving can remove useful guidance if nobody owns the review.

• Track useful outcomes: successful reuse, repeated gaps, review backlog, and whether corrections pass verification. Avoid rewarding article volume alone.
• Treat customer feedback as evidence to investigate, not automatic proof that an article is wrong. Reproduce the problem in the stated environment.
• When consolidating duplicates, preserve unique useful guidance, publish the canonical answer, then archive and redirect the old material.
• Review an article whenever the relevant feature, label, default, permission, or behavior changes. A fixed review date is a backstop, not the only trigger.

Follow one resolved issue through the KCS loop

A fictional equipment customer reports recurring restarts after a configuration change. Support has now verified the cause and a supported correction. The reusable knowledge is the symptom, applicable environment, diagnostic distinction, safe correction and verification—not the customer’s name or a raw dump of its logs.

1. Search while investigating. Try the equipment family and symptom, then the exact error or configuration term once known. Compare applicability before creating anything. If an existing article solves the same task, improve that canonical article rather than making another version with a different title.
2. Capture the answer in the case. Record what was observed, what was tested, what failed, what corrected the issue and how recovery was confirmed. Separate the verified cause from earlier hypotheses.
3. Draft for the next reader. Use a task title such as “Diagnose repeated restarts after a controller configuration change.” Explain the applicable model/version and required access, then give complete steps with expected observations and recovery branches. The actual technical steps must come from verified evidence, not this illustrative example.
4. Remove private context. Leave customer-specific serial numbers, credentials, logs and contract details in the proper restricted records. Replace identifying examples with safe descriptions while preserving the technical conditions that make the answer correct.
5. Review the task. Have the reviewer follow the procedure as the intended reader. Ask them to identify any unexplained term, assumed permission or missing result. Confirm a useful no-match/does-not-apply path so readers do not force the solution onto a different problem.
6. Publish for the intended audience. Check the version, external eligibility, restrictions and topic placement separately. Publish quietly when that is the intended workflow, then verify the portal and agent reader.
7. Reuse and improve. When the next matching case arrives, use the article and record the outcome. If a different version or exception appears, capture that gap. If AI search misses the article, preserve the failing question and examine discovery as well as content.

A review should produce a decision: publish as accurate, request a specific correction, keep the guidance restricted, or reject unsupported content with a reason. “Looks good” is not sufficient if nobody tested the procedure or checked the audience.

Share responsibility without making knowledge somebody else’s problem

These are operating responsibilities; your configured permissions determine which actions each person can perform. One person may hold several responsibilities, but the checks still matter. Avoid measuring success only by article count. Look at whether readers can complete tasks, whether agents can find the correct answer and whether known gaps are resolved.

Common problems

Continue learning

• Create, review, schedule, and publish a knowledge article
• Review article feedback
• Configure review groups
• Configure tags and knowledge audiences
• Organize topics and portal access
• Capture knowledge while working a case