The AI use case that was really a documentation gap
A support lead at a developer-tools company wanted an AI assistant to answer the questions that flooded her queue. The questions had one thing in common. The docs had never covered them.
The AI use case that was really a documentation gap
A support lead at a developer-tools company told me about the assistant she was sure would save her team. Support volume kept climbing, the same questions came in over and over, and the plan was obvious. Build an AI assistant on top of the product docs so customers could get instant answers and the queue would shrink. She had budget, she had buy-in, and she was ready to build.
Before she did, she pulled the last few months of tickets and sorted them by what customers were actually asking. That sort changed the project. The questions clustering at the top of her queue were not answered badly in the docs. They were not in the docs at all.
An AI cannot retrieve what was never written
The pattern was consistent. Customers were asking about a handful of things the documentation simply never covered. How the product behaved in a specific deployment setup. What a particular error meant in practice. How two features interacted at the edges. The answers existed, but they lived in the heads of three senior engineers and in scattered Slack threads, not in anything a system could read.
That is the fact that reframed the whole plan. An AI assistant built on the docs would confidently fail on exactly the questions driving her ticket volume, because those answers were not in the docs for it to find. Retrieval can only surface what has been written down. If the knowledge is not in the source, the model either says it does not know or, worse, invents something that sounds right. She would have shipped an assistant that was useless for the top of her queue and made things worse for the parts it guessed at.
The real problem was not the absence of an AI. It was the absence of documentation. The queue was full of the same questions because the answers had never been captured anywhere a customer, or a machine, could reach them. Every repeat ticket was a documentation gap billing itself as a support problem.
So she flipped the order. Take the top recurring questions, get the three senior engineers to write the answers down properly, and publish them. The moment she did, two things happened. Customers started finding answers on their own, which pulled volume out of the queue directly. And she now had a real source of truth, one that an AI assistant could sit on top of later and actually work.
A friend who runs internal IT at a manufacturing firm described the same sequence. His team wanted an AI helpdesk bot. The recurring internal tickets turned out to be undocumented tribal knowledge about their own systems. Writing it down cut the tickets before any bot existed, and gave the eventual bot something true to stand on.
Write it down first, then decide about AI
The useful reframe is that documentation is not the thing you skip on the way to an AI assistant. It is the thing the AI assistant needs to exist, and it delivers value on its own before any model is involved. If the knowledge is not written down, the honest first project is to write it down.
Questions worth asking before you build a docs assistant:
- What are people actually asking, and is the answer written down anywhere a system can read?
- How much of this knowledge lives only in a few people’s heads?
- If we published the answers to the top questions, how much volume would that remove on its own?
- Would an AI on top of the current docs fail on exactly the questions that matter most?
If the answers do not exist in a readable form, an AI assistant is premature. The documentation is the project, and it feeds whatever you build next.
How we approach it at Density Labs
Checking whether the knowledge even exists is part of the AI Opportunity Assessment, our fixed two-week engagement at $2,500. Before we scope a retrieval system, we look at what people are really asking and whether the answers live anywhere a machine can reach them. Often the finding is that the first, cheapest win is writing down what a few experts know, which helps customers immediately and gives any future assistant a real foundation. That sequencing saves clients from launching an assistant that is confidently empty where it matters most.
An AI assistant is only as good as what it can read. If the answers were never written down, the use case is a documentation gap, and the documentation comes first.