An internal assistant on your own documents: what needs to be in place first

The idea is appealing: an assistant anyone on the team can ask "what's the warranty period on this product?" or "how do I process a cancellation?", and that answers instantly, citing the right document. The technology to do this exists and works. The decision in front of you is not whether the technology is mature: it is whether your documents are. This article is about that part — the part almost nobody talks about.

What an internal assistant is — and isn't

We mean a tool for your own team that answers from the company's documentation: procedures, catalogue, policies, manuals, terms. We do not mean the chatbot that serves your customers on your website — that is a different project, with different rules and a different audience, and we cover it on its own page. Here the user is your own people, and the raw material is everything your company has in writing. That difference matters, because the project succeeds or fails on the raw material.

The part nobody talks about

The assistant knows nothing that isn't in the documents. It doesn't deduce, doesn't ask the veteran colleague, and doesn't distinguish the current procedure from a PDF from years ago unless someone has marked it. And it answers with exactly the same confidence whether it is citing the correct document or the obsolete one.

The consequence is direct: the quality of the assistant is the quality of the archive. If two people on your team would give different answers to the same question today because they work from different versions of a procedure, the assistant will inherit exactly that ambiguity — with better prose and more poise. What is a doubt between colleagues today becomes a wrong answer delivered with total confidence tomorrow.

Three conditions for the raw material

Before any conversation about technology, the documentation needs to meet three conditions.

Current content

Someone has to review which documents are still true, and retire or archive the ones that no longer are. An archive where the current and the expired live side by side is not a knowledge base: it is a trap with a search box. Every document should carry some mark of currency — a date, a version, a status — however simple.

One version per document

One source per topic. If the manual for a process exists as "manual_v4", "manual_v4_FINAL" and "manual_good" across three folders, the assistant will not choose better than you would: it will choose any of them. Consolidating duplicates is preparatory work, not a later refinement.

An owner per area

Each block of documentation needs a person who answers for it being current and who updates it when something changes. Without owners, the assistant starts well and ages badly: every correct answer of today quietly expires, and nobody notices until someone acts on a stale one.

What the project brings to light

Preparing the documents uncovers things, and it helps to know that in advance so it isn't experienced as a setback. Contradictions between departments appear: two discount policies, two return criteria, each side convinced theirs is the official one. Knowledge that isn't written anywhere appears, because it lives in someone's head; the assistant cannot answer what nobody wrote down, so those gaps become visible. And documents nobody remembered turn up.

None of this is a project failure: it is part of the value. Putting the documentation in order improves the company even if the assistant took its time to arrive. If the project did nothing but force that clean-up, it would already have paid part of its way.

Who may ask what

Not every document is for everyone: salary terms, contracts, board minutes. An internal assistant needs access rules as clear as the folders it reads — and if the permissions on those folders have been a mess for years, it inherits the mess. Deciding who may see what, and checking that the folders actually reflect it, is a decision that comes before the project, not a final tweak. It is far easier to grant access later than to withdraw an answer that has already been read.

Five questions before building an internal assistant

1. If you ask your team's most frequent question right now, does the document with the answer exist, and is it current?
2. How many versions of your most important procedure are in circulation at this moment?
3. Does each area have a documentation owner, with a name attached?
4. Which documents should not be visible to everyone — and do the actual permissions reflect that?
5. When something changes, who will update the document, and how will they find out it changed?

If several answers make you wince, the project isn't off the table: it starts earlier, with the documents. It is less glamorous work than the demo — and it is exactly the work that decides whether the assistant informs or misleads.