Most documentation teams can answer how many topics they produce. Very few can answer what each topic costs.
Not the team salary. Not the tool license. The actual cost of producing one usable documentation topic — from first draft to published output.
We recently asked Improvementsoft users a simple question:
"How likely are you to recommend Improvementsoft to a peer?"
The result: Net Promoter Score: 94
For context, an NPS above 70 is considered world-class. A score of 94 means that nearly every customer who responded would actively recommend Improvementsoft tools to their peers.
But numbers are only part of the story. The most interesting part of the survey was how customers described the impact on their work.
Everyone says documentation should be "AI-ready." Few can explain what that means in practice. It is not a marketing label. It is a set of measurable structural properties that determine whether AI tools can use your content or will hallucinate around it.
Your RAG pipeline is only as good as the content it retrieves. Teams spend months tuning embeddings, chunking strategies, and prompt templates — then feed the system documentation that was never designed for machine consumption. The result is confident, well-formatted answers built on garbage retrieval. The content layer is where most RAG implementations silently fail.
Nobody ships a documentation project with the intention of letting quality degrade. It happens anyway. Not in a single event, but through hundreds of small decisions — a shortcut here, an exception there, a new writer who follows the patterns they see instead of the patterns you intended. This is quality drift, and by the time it becomes visible, the cost of fixing it has multiplied.
Documentation teams buy tools to solve problems. But most documentation problems are not tool problems — they are structural problems, process problems, or architecture problems that follow you from one tool to the next. Buying a new tool before diagnosing the actual bottleneck is the most expensive mistake in technical documentation.
AI can cut your drafting time in half. It can also silently destroy the structural integrity of your Flare project in a single paste operation. The difference is not whether you use AI — it is how. Most technical writers are using AI in a way that creates more cleanup work than it saves.
Moving from DITA to MadCap Flare is not a simple file conversion. It is an architecture change — from a topic-based XML standard with maps and specializations to a topic-based XML editor with its own structural model. Getting the files across is the easy part. Getting the architecture right is what determines whether the migration succeeds or creates a new set of problems.
Enterprise AI projects are failing at a remarkable rate, and the usual suspects — model selection, prompt engineering, integration complexity — get all the attention. But there is a quieter, more fundamental problem that undermines AI initiatives before they produce a single useful answer: the documentation that AI is supposed to learn from is not structured well enough for AI to use.
Your reviewers are doing their best. The problem is not effort. The problem is that manual QA fundamentally cannot scale with content volume.