Need help?Jamie

AI Automation

Keep Your Business Knowledge Base Accurate for Staff and AI

Your website lists one service area, and the AI assistant you just connected quotes the one you dropped last year. Trojan Digital Marketing sets up AI agents and document assistants, and we start with a facts record that shows each fact's current wording, source and owner. Before you connect another tool to your files, call us: the first strategy call is free, and during business hours we aim to reply within five minutes.

Illustrative workspace for planning connected business systems.

See how I'd approach this

Choose a question
to look at with me.

A plan moving from scope to delivery and review01Define the scope02Build the work03Review the result
  1. Define the scope
  2. Build the work
  3. Review the result
A plan moving from scope to delivery and review

PUT THIS PAGE TO WORK

Trace one changed fact through every dependent answer

Here's the drill we'd run first, on a made-up case. A service company stops taking one type of project in some of its towns. That fact may sit in its service page, inquiry instructions, staff scripts and AI replies. Fixing one knowledge base entry helps only when every copy of the old fact can be found and checked.

We give the fact a lasting ID and one owner. Its record holds the approved wording, the date it takes effect, who approved it and who may use it. The old wording can stay as history, but it's clearly marked retired. Nobody reading a retrieved passage should have to guess which version is current.

Next we list what depends on the fact, at a level the team can keep up with. Here that's the public service page, the form branch for that project type and the reply template that quotes coverage. Each one gets checked against the new fact. Anything generated later should point to the approved record, because a copied sentence goes stale without anyone noticing.

Then we test with two requests, one inside the new scope and one outside it. Both answers should keep that line clear and give the right next step. If the current fact can't be found, the workflow should ask staff to confirm instead of pulling up a retired statement. We log those checks with the change, so the next reviewer can see what was actually updated.

Illustrative working brief, adapt to the actual business
DecisionWorking exampleUsable output
Approved fact
Current project coverage
Owner, effective date and current version
Dependencies
Page, form branch, response template
Named review list
Verification
Inside scope and outside scope requests
Correct distinction in both answers

Pair this record with the business facts playbook and the human review workflow.

We keep our own company facts this way. When we write for our own site, business facts come from a dated list that Jeff Clerisier, our founder, has confirmed. Anything still marked pending stays out of new copy. This playbook sets up the same kind of system for your writers, sales staff, support team and AI workflows. It covers record structure, approvals, access limits and a review routine. It also backs the AI SEO services buying guide by keeping your business evidence current.

Define the knowledge base's purpose

Choose the decisions the system should support. It may help staff answer service questions, prepare accurate content, route inquiries, or find current procedures. We won't point a public drafting tool at every internal file just because the files are there.

Write a scope statement covering audiences, approved uses, excluded information, and responsible owners. Identify which outputs remain drafts and which workflows can take action. The knowledge base supplies evidence; it should not silently expand the authority of a tool that reads it.

Read the knowledge base governance article for a concise overview. This playbook adds the records and operating steps needed to make the system useful over time.

Inventory sources before importing them

List service policies, procedures, contracts or approved summaries, public pages, product documentation, FAQs, and other relevant sources. Record the owner, purpose, sensitivity, current status, and whether the source is authoritative for the proposed use.

A sales slide may summarize a service but not define its contractual scope. An old public page may contain a retired commitment. A customer message may describe a request rather than an approved business fact. Importing these materials without labels can make a search or AI workflow treat them as equally authoritative.

We'd start with a small set of valuable sources the business can verify and keep current. A bigger pile isn't more useful when it brings more contradictions, stale facts and review work.

Create records with provenance

Give each knowledge record a stable identifier, title, approved content, source reference, owner, effective date, status, and review trigger. Where the content summarizes a longer source, preserve the relationship so a reviewer can inspect the original context.

Keep facts separate when they have different owners or change at different times. Service coverage, pricing conditions, contact routes, and preparation requirements may belong in related records rather than one long document that is difficult to update safely.

Our AI Answer Kit can help organize a business facts pack for public content. We use it as input to an approval process, and on its own it isn't a full knowledge management system or any platform's seal of approval.

Use an explicit lifecycle

StatusMeaningAllowed use
Proposed
Information has been submitted but not approved
Review and clarification
Approved
An accountable owner confirms the current record
Defined operational or editorial uses
Under review
A material question or change is being assessed
Use according to the documented temporary rule
Superseded
A newer record replaces the prior version
Historical explanation where needed
Retired
The record no longer supports current work
Restricted historical reference if appropriate

Define what happens during review. Some records can remain in use while a minor update is prepared. A disputed service promise may need to be withheld from new drafts until the owner resolves it. The status should lead to a clear behavior rather than serving as a decorative label.

Assign approval to the person who knows the fact

Operations should confirm service scope and delivery commitments. The responsible business owner should confirm asset and agreement summaries. Editors can improve clarity and source presentation. Technical owners can verify integrations and public outputs. One person may hold several roles, but the responsibilities should remain explicit.

Require a reason for material changes. A revised service boundary, corrected contact route, or retired offer should have an effective date and a short explanation. Preserve the previous approved version when the business needs it to understand past content or actions.

The business entity consistency playbook connects those approved facts to public destinations. A knowledge change is not complete when dependent pages still present an incompatible version.

Keep access aligned with intended use

Separate public ready facts, internal procedures, and confidential records according to the business's needs. Grant access to people and workflows based on their purpose. A content drafting workflow may need service facts and approved examples without needing customer account details.

Do not treat a retrieved document as an instruction to change the workflow's authority. A source can contain quoted requests, examples, or malicious text. The system's permission rules should come from the approved application design, while retrieved material is treated as information to evaluate.

The NIST AI Risk Management Framework offers voluntary guidance for managing AI risks. The practical controls here should be adapted to the actual business workflow rather than described as a certification.

Handle contradictions deliberately

When two sources disagree, record the conflict and identify the owner who can resolve it. Do not automatically choose the newest file, the longest document, or the statement that sounds most confident. Recency can be relevant, but it does not establish authority by itself.

For a hypothetical service, an old proposal may include a feature that is no longer part of the standard scope. The correct record may need to distinguish current standard work from historical or custom agreements. A broad replacement could erase a legitimate exception, while leaving both statements unqualified could mislead a drafting workflow.

Keep the resolution with the affected records. This helps future reviewers understand why the wording is qualified and prevents an editor from reintroducing the conflict while trying to simplify the content.

Connect knowledge changes to dependent outputs

Map records to public pages, response templates, forms, automation rules, and internal procedures that use them. When a fact changes, the dependency map becomes the update list. Prioritize outputs that affect customer expectations or consequential actions.

Use the content freshness system for public page maintenance. For automation, use the human review playbook to determine whether the change requires new approval rules or evaluation cases.

Verify the actual output after the update. A corrected source record does not prove that a cached page, exported document, or connected workflow is using the new version. The technical and editorial owners should know which dependent systems need a refresh or release.

Evaluate retrieval and answer quality

Create a small set of realistic questions with expected source records and acceptable limits. Include routine questions, missing facts, legitimate exceptions, and conflicts that should trigger review. Use anonymized or synthetic examples and label them clearly.

Check whether the workflow retrieves relevant current evidence, preserves important conditions, and admits when the answer is unavailable. A fluent response that cites an obsolete record is a failure of the intended process even if the prose sounds convincing.

Read the AI readable business facts article for preparing clear source material. Good structure helps, but it does not remove the need for authority, versioning, and evaluation.

Work through a hypothetical policy update

Keep useful information dependableObserveReviewUpdateRecheck
Observe → review
Check the page and its evidence.
Update → recheck
Publish the change and check the result.
Keep useful information dependableReview the evidence, update what changed and check the published result. A new date alone adds no value.

Imagine a business changes which project types qualify for a consultation. The operations owner proposes a new eligibility record with an effective date and a reason. The editor checks clarity, the owner approves the fact, and the dependency map identifies the service page, intake form, response template, and routing rule.

The public draft is updated and reviewed before release. The workflow's evaluation set gains examples at the new boundary, including a request that should be referred to a person. The technical owner confirms that the active workflow uses the current approved record and preserves the original inquiry.

The previous record is marked superseded and retained only for the appropriate historical purpose. A later staff member can understand why an earlier inquiry received a different response without treating the old policy as current. This hypothetical example shows how governance supports both consistency and accountable change.

Maintain the system with a realistic workload

Track records without owners, overdue review triggers, unresolved conflicts, and outputs waiting for updates. Review repeated corrections from staff and automation users. Those patterns can reveal unclear records or missing distinctions that deserve a source level improvement.

Retire redundant material when it no longer serves a useful purpose. A knowledge base should become easier to use as it matures, not simply larger. Keep historical material only where the business has a reason and an appropriate access arrangement.

Plan for staff changes. The handoff should include the record model, ownership map, approval rules, source locations, and open issues. A system that depends on one person's memory is vulnerable even when the software works well.

Completion standard and first scope

Keep the first scope narrow enough that an owner can review every important record. Expansion should follow a working approval and maintenance process, with clear evidence that additional sources serve a real business decision.

Design the behavior when current knowledge is unavailable

A workflow should have an explicit response when it cannot retrieve an approved record or when the record is under review. It may return a limited draft, ask for clarification, or route the decision to a person. It should not silently substitute an obsolete document or general model knowledge for a specific business commitment.

Make that state visible to the reviewer. “No approved pricing condition available” tells a person what must be resolved. A confident paragraph assembled from unrelated sources hides the problem. The interface should distinguish missing evidence from a system failure and preserve enough context for the owner to take the next step.

Test this behavior deliberately. Temporarily unavailable sources, expired approvals, and contradictory records are realistic operating conditions. The workflow should remain useful by narrowing its answer and preserving the handoff, rather than pretending that every request can be completed automatically.

Keep source updates and software updates separate

A service fact revision changes what the system should say. A retrieval or model change can alter how it finds and uses evidence. Record both kinds of change and evaluate the relevant cases. If they happen together, acknowledge that a later difference in behavior may have more than one cause.

Version the configuration or process notes needed to understand the active workflow without exposing unnecessary technical details in customer facing pages. The business should be able to identify which approved knowledge and rules were in use for a material action. That traceability supports corrections, staff handoffs, and a more informed decision about whether to expand the automation.

The first implementation is ready when its purpose is bounded, approved records have provenance and owners, status affects use, access matches the intended workflow, and material changes reach dependent outputs. Evaluation should show that unknown or conflicting information does not become an unsupported confident answer.

Ask Trojan Digital Marketing to scope a governed business knowledge base. Bring one service or workflow and the sources your team currently relies on. A compact, maintained system is a useful foundation for both clearer content and more reliable automation.

Sources & further reading

Need our help with this on your own site?

Request a free strategy call

The first strategy call is free, and during business hours we aim to reply within five minutes.

Identify the exact answer readers could act on

When staff dispute a published answer, the first question is what readers may currently understand. We can isolate the passage at issue before proposing any temporary wording for the public page.

A disputed knowledge-base answer can remain public while two named staff members disagree about what it should say. The immediate writing task is specific: identify the words a reader could use to make a choice while the answer remains unsettled. Our brief can quote that passage and retain the question it answers. The team should say which part is disputed and which surrounding information still has an approved meaning.

Start with the smallest complete statement that carries the disagreement. A sentence may describe one condition inside a much longer answer. Removing the whole page can hide a useful contact instruction or unrelated explanation. Keeping the whole answer can leave the disputed direction readable as settled guidance. We can show the owner those affected parts together, then draft the public treatment the named approver chooses.

Read the passage from the reader's point of view. What could they do after seeing it, and which words create that expectation? Our draft can flag an implied action as well as the explicit sentence under discussion. A heading or button may still carry the old meaning after the paragraph changes. The temporary edit should address that connected wording where the owner has approved it.

  1. Quote the questioned statement Give us the exact public passage and its page address. We can keep the original question with it so staff discuss the same answer rather than different summaries.
  2. Identify the open meaning The named team states what remains disputed. Our brief can describe that unresolved part in plain words without deciding which staff view is correct.
  3. Locate the connected direction Check whether a heading, short answer or contact choice repeats the questioned meaning. We can bring those words into the proposed temporary edit.
  4. Retain approved context Staff identify the surrounding information they still accept. Our draft can preserve that material when it helps a reader understand the pending question.
What if staff disagree about the question itself?
Ask the approver to identify the reader question the page is intended to answer. We can write that question clearly before proposing a temporary response. Otherwise the disagreement may concern two different tasks that happen to share one heading.
Should a small disputed phrase close the whole page?
The owner should choose the treatment after seeing what the phrase affects. Our work can identify useful approved context and the words that carry the disputed direction. That gives the approver a concrete public edit to assess.
Can we leave the existing answer until someone decides?
Ask the named owner to consider the action a reader could take from it. We can show the disputed meaning in context, then draft the temporary wording that person approves. The open question should not acquire approval merely through continued publication.

Keep an internal suggestion from becoming released guidance

A staff note may propose an answer without approving it for readers. We can write the temporary public passage from the owner's instructions while leaving suggested meanings in the working discussion.

Texas Electrician Exam box fill calculator controls
Selected items shown apart from the tray. View the project

The selected-item area gives us a concrete reference for keeping a statement connected to its context. In a disputed answer brief, we can keep the proposed public wording next to the passage it replaces. Staff should be able to see which words readers would receive. An internal explanation of the disagreement belongs with the discussion unless the authorized owner has approved it for publication.

A temporary answer should tell the reader what the team can currently say about the question. It need not reproduce the staff debate. Our draft can retain an approved contact direction while leaving the disputed main answer open. The owner decides whether the public treatment removes a sentence, replaces it with a limited explanation or temporarily withholds that answer. Each choice should have words a reader can understand without knowing the internal conversation.

A note that says someone expects an answer tomorrow is also a proposal unless the owner approves that promise. We can keep an uncertain timing assumption out of the public passage. If the team wants to state a next contact or a date, it supplies that approved instruction. The temporary wording can remain helpful by explaining how to ask the question, even where no resolution date has been agreed.

Disputed knowledge-base answer controls
Public passageOwner instructionTemporary reader meaning
Question headingStaff identify the question the answer is intended to address. We can retain that subject in the temporary wording.The reader knows which answer remains open without seeing an unrelated page closure.
Disputed sentenceThe approver names the exact statement to remove or replace. Our draft can show its current wording and proposed treatment together.The disputed direction no longer appears as a settled instruction if the owner has chosen to withhold it.
Approved contextThe team identifies the surrounding material it still accepts. We can preserve that context near the open question.The reader can still use the information whose meaning the team has approved.
Contact directionThe owner names who can receive the unresolved question. Our passage can explain what the reader should ask that person.The page offers a real question route while the main answer remains pending.
Internal suggestionStaff retain a possible meaning in their working discussion. We can label it in the brief as a proposed answer awaiting approval.The suggestion remains outside released guidance until the authorized person approves its public meaning.
Final replacementThe named approver supplies the resolved answer and its intended context. Our edit can replace the temporary passage from that instruction.The released answer reflects the team's actual approval rather than an assumed end to the disagreement.

Name who can approve the public answer

The person reviewing a suggestion may not have authority to release it. We can ask the owner to name who decides the public meaning and who may approve a temporary question route.

A disagreement can stall when several people comment on an answer but no one is identified as its approver. Our writing task can begin with a direct question to the owner: who can authorize the words readers will see? The team supplies that authority. We can draft the temporary passage for that person without treating the person who raised the concern as the automatic owner of its resolution.

The temporary contact direction may also need a named approver. A staff member might be willing to receive questions but unable to answer the disputed point. We can write the route around the role the team approves. It should explain what the recipient can actually do, such as receive the question for the named team. The passage should not promise a main answer from a person whose authority is still unclear.

Give the approver a concrete choice of wording. A request to resolve governance may be too broad to produce a usable answer. Our draft can show the sentence proposed for publication and the reader action it describes. Staff can then approve the public meaning, ask for another version or identify the question that still needs resolution. Keep that open question explicit while the temporary passage is being decided.

  1. Name the main approver The team identifies who can decide the answer's meaning. We can address the proposed replacement to that person and preserve the exact question they must resolve.
  2. Confirm the temporary authority Ask who can authorize a limited public explanation while the answer is open. Our brief can keep that permission distinct from approval of the eventual answer.
  3. Approve the receiving role The owner states what the contact recipient can do with a pending question. We can describe that role without promising an answer it is not authorized to supply.
  4. Show the words in context Present the proposed passage with its heading and neighboring directions. Our work can make the public effect visible before the approver decides to release it.
Can a subject specialist supply the final wording?
They can supply the explanation the team asks them to prepare. The owner still needs to identify who approves its public release. We can make that approval request specific to the proposed answer and the context where it will appear.
What if authority is still unclear?
Ask the team to resolve who may approve the temporary passage. Our draft can identify the affected words while that answer is pending. We should not convert uncertainty about the approver into permission to release a staff suggestion.
Does approval of a contact route settle the disputed answer?
It approves the reader's next contact within the role the team has defined. The main answer can remain open. We can describe both meanings clearly so the public passage does not imply that the disagreement has already ended.

Preserve a useful question route while the answer is open

A pending answer can still leave the reader with a clear way to ask for help. We can write that next contact from the team's approved process and retain the question's relevant context.

A reader may arrive at the knowledge-base page because they need to act, rather than because they want background information. If the answer is temporarily withheld, explain the question that remains open and the next contact the owner approves. Our wording can keep those two elements close together. The reader should understand what to ask without reconstructing the removed paragraph from an old quotation.

The contact should request only the context the receiving team needs. An earlier reference may help staff locate the question, while the reader's present concern explains why it matters now. We can name those inputs separately. The team decides how private material reaches the team. A public explanation of the pending answer need not expose the person's earlier exchange or ask them to publish it on the page.

A receipt should preserve the open status of the question. If delivery has occurred, the message can acknowledge that contact event and identify the approved next step. It should not repeat one disputed meaning as a reassuring answer. Our suggested receipt can leave the main point with the authorized team while confirming what the reader has sent. That keeps the question useful without settling its meaning prematurely.

Hypothetical example A hypothetical team disagreeing about one published knowledge-base answer

Before

  • Two staff members propose different meanings for a sentence readers could act on.
  • An internal suggestion is copied into the page while the owner has not approved either answer.
  • The contact receipt repeats that suggestion as though it resolved the question.

After

  • The proposed temporary edit identifies the open question and retains approved surrounding context.
  • The public passage names the team's authorized route for questions while the disputed answer awaits its approver.
  • The suggested receipt acknowledges the reader's enquiry without selecting a main meaning.
Should the page explain the staff disagreement?
The owner decides what public context is appropriate. We can write a limited explanation of the open answer without naming internal participants or repeating unapproved suggestions. The reader needs to know what remains unanswered and how to ask the relevant team.
Can the contact direct people to an earlier answer?
Only if the owner approves that answer for the question currently being asked. Our draft can identify what the older passage covers. It should not restore the disputed direction through a link merely because the sentence has been removed here.
What if a reader cannot provide a reference?
The receiving team should choose a permitted starting route for that situation. We can explain it beside the field help. A pending answer should not leave someone unable to ask simply because they lack a detail staff could clarify later.

Keep field names aligned with the pending question

The contact form should request the context its recipient can use. We can label the reference and the unresolved question clearly so the form does not make the reader adopt a proposed answer.

Jev scanner website input and scan action
The scanner input shares its action's subject. View the project

The scanner's named starting task gives us a layout reference for a pending-answer contact. We can place the reader's reference near the action that sends the question to the approved recipient. The action should name that contact purpose. It should not be called resolve my answer unless the team actually approves the promise those words make. A field and its button need to describe the same task.

A disputed topic should not force a reader to choose one staff meaning before asking for help. Our proposed form can offer space to describe the question in the reader's own words. The receiving team supplies the references it accepts and what those fields mean. If the team needs to know which page the reader saw, label that detail clearly rather than asking the person to diagnose the disagreement.

W3C's form tutorials discuss descriptive labels and clear notification of submission outcomes. We can use those principles for the proposed contact path. The field names describe the requested context, while the receipt describes the sending event that actually occurred. The team supplies the answer process. Those shorter interface messages should preserve the same open main question as the temporary passage above them.

  • Our proposed page reference can identify where the reader encountered the answer. The receiving team should approve whether that detail is required or may be supplied later.
  • The question field should let the reader explain the uncertainty that brought them to the page. We can keep it free of a forced choice between staff suggestions.
  • A clearly named send action can describe the approved recipient or contact task. It should retain the open answer status rather than promise that sending resolves it.
  • Staff should read the receipt alongside the temporary passage. Our draft can remove any phrase that completes an answer the team has chosen to leave pending.
  • The team decides how additional private material reaches the team. We can name that permitted route if needed, without making private context part of the public explanation.

Replace the temporary passage from an approved answer

Closing the dispute requires the team's actual public answer. We can replace the temporary wording from that approval and check the related question route for any message that still carries the earlier meaning.

When the approver supplies the resolved answer, compare it with the exact question the temporary passage identified. Our edit can show which words are now approved and which context they apply to. The closing instruction should not rely on an assumption that the disagreement has ended because staff stopped discussing it. A named public answer gives the website a clear replacement for the pending passage.

Look at related short quotations that may still carry the old direction. A question list or an earlier contact instruction can reproduce the same meaning in fewer words. We can identify those copies and propose the specific replacement each needs. The approver should decide whether the resolved answer applies to them. A changed main paragraph alone does not answer that context question.

The contact path may remain useful after resolution, but its wording may need another purpose. A receipt that says the published answer is pending can become inaccurate once the approved explanation appears. Our handoff can identify that message alongside the final passage. The team decides what question the route should receive next. We can maintain the public wording from that instruction rather than carrying the temporary status forward indefinitely.

  1. Read the approved answer against the question We can present the replacement beside the question readers were told remained open. Staff should confirm that it answers the intended point within its stated context.
  2. Locate related public quotations Identify short answers and directions that carry the earlier meaning. Our proposed changes can preserve their own context while applying the approver's resolved wording.
  3. Update the contact status The owner decides what the question route now receives. We can revise its heading and receipt so they no longer describe an answer as pending after release.
  4. Confirm the replacement in place Ask the approver to read the final page as a reader would. Our handoff can name any remaining question that still needs a separate public answer.
Should the temporary explanation remain as background?
Only where the owner approves a continuing reader purpose for it. We can rewrite that context so it does not imply the main answer remains disputed. The released page should describe the team's present approved meaning.
What completes the temporary-publication task?
The authorized answer has replaced the pending passage in its approved context, and the associated question route has a clear current purpose. Our handoff can identify those changed words while leaving any separate unresolved question with its approver.
What if the final answer raises another disagreement?
Identify the new passage and the reader action it could affect. We can prepare another specific temporary edit for the owner to approve. Do not treat the earlier resolution as approval for a different question that staff have not settled.

Sources