How to Build an AI Knowledge Base Workflow

An AI knowledge base workflow turns approved source material into answers people can find and check. Build it around six controls: a question backlog, authoritative sources, evidence-linked drafts, named reviewers, audience restrictions, and an update process that reaches both the published article and the AI answering layer.

Start with one recurring topic, such as account setup or report exports. The first deliverable is a reviewed answer with a working source link and tested access rules. Connecting every company folder before establishing those controls can make old notes and private exceptions available alongside current guidance.

1. Identify the question and its authoritative source

Review repeated questions in your support queue or internal help channel. Group questions by the decision a reader needs to make, rather than by identical wording. “Where is my export?” and “Why did the download not arrive?” may belong to the same troubleshooting article, while “Who can export?” needs a permissions answer.

For each group, ask the process owner which document or product behavior governs the answer. A previous support reply can reveal the wording customers use, but it may contain an exception or an outdated workaround. Do not promote it to company policy without confirmation.

Question type	Evidence to collect	Reviewer
How to perform a product action	Current product documentation and a checked sequence in the applicable interface	Product or support owner
Who may perform an action	Current role and permission rules	Product or access administrator
Which plan includes a feature	Current plan specification and applicable commercial terms	Billing or commercial owner
What happens when a step fails	Approved troubleshooting steps and escalation conditions	Support owner

Remove customer identifiers from working examples unless they are necessary and authorized for the selected system. Keep the original approved source intact; create a reviewed working copy instead of overwriting evidence while cleaning it.

2. Record approval, audience, and version separately

Give each answer a stable identifier, topic, source URL or file reference, source revision, owner, intended audience, approval state, and next review date. Record when the source was checked and when the answer was approved. A recent edit date alone does not tell the reader whether anyone confirmed the substance.

Use separate states for drafting, approved, and withdrawn. A draft should remain outside the live answering system until its reviewer approves it. A withdrawn answer needs an operational action—remove or disable it in the retrieval source—not merely a red label inside the text.

Keep public instructions apart from internal troubleshooting notes. For example, the public article can tell a user how to request help; an internal runbook may contain diagnostic details or exception handling. Both can address the same issue without giving a customer access to the internal version.

3. Ask AI to transform evidence into a reviewable draft

Provide only the approved source set for the topic and specify the audience. Ask for a short answer, ordered steps, documented exceptions, and an escalation condition. Require a source reference for every substantive claim, including eligibility, limits, waiting periods, and promises about outcomes.

Draft a customer-facing report-export help article using only the supplied approved documents. Explain the documented steps and permissions. After each factual statement, identify the source and relevant section. List unresolved questions separately. If the sources disagree or do not support an answer, flag the issue for the product owner; do not supply a likely rule.

This is a drafting instruction, not a claim about a particular product’s export rules. Replace the task with your real topic and provide the actual approved documents. A request for citations does not guarantee that the cited passage supports the sentence, so the reviewer must open the evidence.

Check numbers and negations carefully. “Only admins can export” is materially different from “Admins can export.” Likewise, “not available on this plan” should not disappear when an assistant shortens the paragraph.

4. Review the answer against the current process

The reviewer should follow the steps, confirm the applicable account role, and compare the draft with the source revision. Check prerequisites, exact menu labels, expected results, failure conditions, and the destination of any downloaded or shared data. Capture an actual screenshot only when it clarifies a step; review it for private information before publication.

When two sources conflict, resolve the conflict before approving the article. Do not let AI blend an old plan limit with a new interface, or turn a one-customer exception into the standard process. Record the deciding source and retire the conflicting guidance from the live source set.

For internal documentation, Notion wikis and verified pages offer ownership and time-limited verification. Owners receive notifications when verification expires. Verification outside a wiki is available on Business and Enterprise. These features can support review reminders; a badge is still an owner’s verification action, rather than an independent fact check or an automatic ban on using expired content.

5. Publish the article and configure AI access deliberately

Publishing a help article and making it available to an AI agent are separate steps. In Intercom’s Fin content setup, a public article must be published and enabled for Fin; a draft or disabled article is unavailable. An article need not appear in the Help Center to be usable by Fin.

Intercom also permits internal articles to supply Fin or Copilot. “Internal article” therefore does not by itself mean “employees alone can use this knowledge.” Configure the intended availability and audience before enabling it.

The Fin audience rules make untargeted material available to Everyone by default. Multiple selected audiences use OR logic, and audience rule changes apply to new conversations; an existing conversation retains its starting rules. Check an eligible and an ineligible user in fresh conversations after changing access.

Choose between importing and syncing intentionally. Intercom’s content documentation describes a Notion import as moving management into Intercom, whereas synced content is view-only there and edited at its source. Establish which system owns revisions so that a correction is not lost or made in the wrong copy.

6. Test retrieval, unsupported questions, and restricted answers

Use a small set of actual questions drawn from the backlog. Include the standard wording, a paraphrase, an ambiguous request, a question the sources do not answer, and a request from someone outside the intended audience.

Test	Acceptance condition
Documented question	The answer matches the current source and preserves important conditions
Missing information	The assistant asks for clarification or uses the approved handoff instead of inventing a rule
Old terminology	The correct current article is found without reviving retired instructions
Restricted question	An ineligible user receives no internal-only details
Changed source	The revised answer is used after the source update and successful retrieval refresh

Intercom’s preview documentation supports testing as a specific audience and inspecting both Customer view and Event log. It also describes testing unlisted content with an internal audience before widening availability. Preview conversations appear in the inbox but are excluded from reporting. Keep a separate test record rather than treating those conversations as measured customer outcomes.

Inspect the content used as well as the final wording. A correct-looking answer based on an obsolete source is not a reliable pass. For the customer service handoff itself, see the AI customer support workflow.

7. Maintain the published answer and the retrieval copy

A source change should open a review task for every affected answer. Use the stable article identifier and source references to find those dependencies. Product releases, permission changes, revised plan limits, and repeated unresolved questions are useful triggers; a calendar reminder supplements those triggers.

Check synchronization explicitly. Intercom says website content syncs weekly and is unavailable until the sync completes successfully. A corrected public page may therefore not be the version Fin is using yet. Re-sync when necessary, check errors, and repeat the affected question after the updated content is available.

If an answer is materially wrong, disable its use while the owner corrects it. Confirm the withdrawal in the answering layer, then verify the replacement and its audience before enabling it again. Retain a revision record so that later reviewers can explain why the guidance changed.

Measure reviewed answer quality, failed retrieval, inappropriate disclosure, handoff usefulness, and repeat questions within the same topic. Use customer feedback analysis to identify recurring gaps, but review individual cases before concluding that an article caused a change in ticket volume. Expand the knowledge base only when the first topic has a dependable source, owner, access rule, and update path.