WhizzWorks

Applied AI

An AI knowledge base for your small business

Turn scattered policies, procedures, and product knowledge into answers your team can verify without treating every old file as equally true.

Staff answers traced back to approved business sources
Less dependence on one person remembering where facts live
Private material excluded according to role and source access
Missing, stale, and contradictory information surfaced for review

A growing business develops a second operating system made of memory. One employee knows how a difficult return is handled. Another remembers which supplier form is current. The owner can answer a pricing exception because the reason was discussed months ago. New staff learn by asking the same people the same questions.

Documents exist, but finding the right one is its own task. Search depends on exact words. Folders contain drafts beside final versions. A procedure says what should happen, while a message thread contains what everyone actually does.

An AI knowledge base can make that information easier to ask and verify. It cannot decide which information deserves trust. That work belongs to the business and has to come first.

Do not connect every file on day one

The fastest way to make a weak knowledge base is to index a shared drive and assume more information produces better answers. It usually produces more contradictions.

We begin with a defined question set and a small source collection. If the goal is to help staff answer product questions, the sources might be the current catalog, approved product notes, and service policies. Old marketing drafts, personal notes, and unrelated financial folders stay out.

Each source needs basic governance:

  • Authority: Is this the document that should answer the question?
  • Ownership: Who is responsible for changing it?
  • Freshness: When was it reviewed, and can it expire?
  • Scope: Which topics and teams should use it?
  • Access: Who is allowed to retrieve it?

This is the difference between a knowledge system and a search box over a file pile.

Make citation part of the answer

A staff member should never have to trust an AI answer because it sounds certain. The supporting source belongs beside the response.

When someone asks a question, the system retrieves relevant passages from the material that person can access. The model forms an answer within those passages and points back to them. The employee can open the procedure, inspect the paragraph, and judge whether it applies to the current situation.

If the sources disagree, the answer should not quietly choose one. It should show the conflict and route it to the source owner. If no source supports the answer, the system should say that the knowledge base does not know.

A useful response may be shorter than a conventional search result, but it is not a substitute for evidence. The citation is what makes the answer operationally useful.

Preserve permissions through the whole path

Internal knowledge is not all equally visible. A company handbook may be open to every employee while personnel notes, customer records, margins, contracts, and management decisions are restricted.

The knowledge base must apply access controls before retrieval, not ask the model to hide sensitive passages after it has already received them. The search layer should return only sources the current person is allowed to read. Logs and review tools need access controls too, because a question can contain private information even when the answer does not.

This is one reason public and internal assistants should remain separate. A customer chatbot should never be one prompt away from an internal source collection. Different audiences deserve different systems, credentials, and tests.

Handle time as part of truth

Business knowledge changes. A procedure is replaced. A price list expires. A service becomes unavailable. A staff memo clarifies a rule for one month.

The source process needs to carry that time information. Published dates, review dates, and expiry dates help retrieval prefer current material and stop using superseded content. Where a system already has version history, the knowledge base should preserve a link to it rather than flattening every version together.

Updates also need evaluation. A changed policy can affect several common questions. We maintain representative questions with expected source material and rerun them when content or system behavior changes. That shows whether the new answer is supported and whether an old answer still appears.

Learn from the unanswered questions

A knowledge base becomes useful when its gaps create clear work.

Staff should be able to mark an answer as wrong, incomplete, stale, or irrelevant. The feedback belongs in a review queue with the question, retrieved sources, and answer. An owner can correct the underlying document, change its status, or clarify that the question requires judgment and should not have a standard answer.

Patterns matter more than individual ratings. If several people ask the same question with no useful source, the business has undocumented knowledge. If the right source exists but retrieval misses it, the search needs work. If people ignore a correct answer because the procedure is impractical, the process itself may need attention.

The goal is not to tune a model until complaints disappear. It is to make business knowledge more accurate and easier to maintain.

Use ordinary search where ordinary search works

Not every document collection needs AI. If files are well named, the structure is clear, and people usually know the exact term, conventional search is faster and predictable. If a team asks very few repeated questions, maintaining a knowledge system may cost more than it returns.

AI retrieval earns its place when people describe the same concept in different words, answers require several passages, the source set is large enough to be difficult, and employees can verify the result. The system still benefits from filters, navigation, and direct document search. Conversation is one route into the knowledge, not the only route.

Start with one team and one source set

We choose a bounded set of representative questions, including questions with no answer and questions that only some roles can answer. Then we build a working prototype against the smallest approved source collection. Your team can test citations, permission boundaries, conflicts, and feedback before anything expands.

The result should not be a model that appears to know the company. It should be a dependable path from a staff question to current evidence, with a clear owner when the evidence is missing.

What you get
Authoritative sources, not one giant folderWe identify which documents and systems are allowed to answer each kind of question, who owns them, and how stale or conflicting material is handled.
Answers with their evidence attachedEvery response points back to the passages it used. Staff can verify the wording, open the original source, and see when the system lacks enough support.
Permissions carried into searchPeople retrieve only the material they are authorized to use. Private financial, personnel, customer, and management information stays outside answers for other roles.
A queue for gaps and correctionsWeak answers, missing sources, conflicts, and staff feedback become visible review work. The knowledge base improves through owned corrections instead of hidden prompt changes.
Questions, answered
Can it search the tools and files we already use?
Often, if those systems provide supported access and useful permission information. We begin with the smallest authoritative source set rather than connecting every folder at once. Each connection is reviewed for scope, freshness, and data sensitivity.
What happens when a policy changes?
The source owner updates the authoritative material, and the search index refreshes through a defined publishing process. Superseded content is removed or marked inactive. Evaluation questions run again so the change does not quietly break related answers.
Will everyone see the same answers?
Not when the source material has different permissions. Retrieval should respect a person's role and the access rules of the underlying system. We test for accidental cross-role disclosure before launch.
How is this different from a website chatbot?
An internal knowledge base is built for staff, often uses private operational material, and needs role-based access. A website chatbot uses public or customer-approved information and has different handoff rules. They can share a retrieval pattern, but they should not share an unrestricted source pool.