Most SaaS product documentation is written for completeness. Every feature is covered. Every setting is documented. Support volume stays high because completeness is not what customers need.
Product documentation organized by feature is product team documentation in disguise. The product team knows what each feature is and wants customers to understand it. Customers arrive with a task in mind. They need to know how to complete the task, and they will leave if the documentation makes them learn the product’s structure first.
The Three-Layer Customer Documentation Framework produces documentation organized by customer task, written in customer language, and updated by support ticket patterns. This article is for the team where the documentation is complete and the support volume is unaffected.
Why Complete Documentation Produces High Support Volume
The obvious failure mode: the documentation covers every feature but customers don’t find answers when they search. They search for “how do I share this with my team” and find a page about “Collaboration Settings.” The vocabulary gap means the documentation might as well not exist.
The less visible failure is structure. Customers don’t browse documentation. They search for a specific task they’re stuck on.
Documentation organized by product feature requires the customer to already know which feature they need. If they knew that, they wouldn’t be in the documentation.
The deepest failure is a feedback loop that doesn’t close. Support tickets contain the exact vocabulary customers use when they’re stuck. That vocabulary is the signal that should update the documentation.
Most documentation processes never use it. The same support tickets get filed, answered individually, and discarded rather than converted to documentation improvements.
The Three-Layer Customer Documentation Framework
Layer 1 uses customer language from the VoC Library
The Voice of Customer Library from Article 10 is the source for customer-facing documentation language. When customers describe their tasks, they use specific words. Those words are in the VoC Library.
Documentation written in product vocabulary and documentation written in customer vocabulary serve different readers. The first serves the product team. The second serves the customer.
Layer 1 requires a vocabulary review before each documentation update. For each section, ask: how do customers describe this task in interviews, sales calls, and support tickets? Use those words, not internal product vocabulary.
Layer 2 organizes content by customer task
The organizing principle for customer-facing documentation is “what is the customer trying to do,” not “what has the product built?”
A documentation site organized by task looks like:
- “Setting up your workspace for the first time”
- “Sharing content with a team member”
- “Finding content you saved last week”
A documentation site organized by feature looks like:
- “Organization settings”
- “Collaboration and permissions”
- “Library search and retrieval”
The task-organized version requires no prior knowledge of the product. The customer recognizes their own task. The feature-organized version requires the customer to map their task to a product concept before they can find the answer.
Layer 3 updates documentation from support ticket patterns
Layer 3 is the maintenance discipline that keeps documentation from aging. Every two weeks, review the top support ticket themes. Any theme that has generated five or more tickets in the period represents a documentation gap.
The review asks two questions:
- Is this task documented somewhere?
- If yes, why aren’t customers finding it?
The first question identifies missing documentation. The second identifies vocabulary gaps and navigation problems. Both drive documentation updates.
Support ticket patterns are the highest-signal input available for documentation maintenance. They represent customers who tried to find an answer in the documentation and failed.
How the Living Library Updates Customer-Facing Documentation
A customer just submitted a ticket for a workflow the documentation should have covered. The Library already knew this was coming. The support ticket pattern for this workflow has been building for three weeks. Five tickets, all phrased slightly differently, all asking the same underlying question.
Kiluma’s Living Library holds both the VoC Library entries (source documents for customer language) and the support ticket patterns. Those patterns are gap signals that show where documentation is failing. Customer-facing documentation maintained from both sources stays current without requiring a dedicated documentation sprint each quarter.
When a documentation update is needed, the Conductor, Kiluma’s context-aware AI, retrieves the relevant VoC language for the specific topic. The update also pulls the support ticket patterns that show how customers describe their confusion. The update uses the customers’ own words.
Rewrite One Documentation Page in Customer Task Language Before Publishing the Next Feature
Before publishing documentation for the next feature, pick one existing documentation page that generates consistent support tickets. Rewrite it using Layer 1 and Layer 2: customer vocabulary from the VoC Library, organized around the task the customer is trying to complete.
Measure support ticket volume for that task in the following month. If volume drops, the documentation update is working. If volume holds, the problem is navigation rather than content.
The Product Knowledge Layer Chapter 04 Built
Chapter 04 built the product knowledge layer that makes the product understandable to the people who need to understand it:
- The Three-Gap Product Knowledge Audit identified the specific documentation gaps that prevent teams from accessing their own product context
- The Four-Layer Product Knowledge Base organized that context for retrieval by current engineers, new hires, and the sales team
- The Sprint Decision Record captured the reasoning behind technical choices at the moment those choices were made
- The Feature Decision Log preserved the customer and business evidence that motivated each significant product decision
- Customer-Facing Product Documentation completed the layer by making product knowledge accessible to customers in their own language
Each layer serves a different audience: internal engineers, new hires, the sales team, and customers. Together, they form a product knowledge system that compounds as the product evolves.
The Playbook’s next Chapters build on this foundation. Try Kiluma free for 14 days at kiluma.ai.