01
Documentation as an operating model
The project brief set four objectives: a documentation system that is clear, accurate and trusted; priorities grounded in support data and product reality; a repeatable operating model tied to product releases; and a body of content ready to support self-service and AI.
The starting conditions
- 01Content that had outgrown its structure300+ articles and internal documents built up organically over several years, at a point of scale where a clearer structure was the natural next step.
- 02Structure that assumed product knowledgeContent was organised the way the software is built, so a reader had to know where a feature lived before they could look it up.
- 03Knowledge held in conversationDeep product understanding sat with long-serving colleagues and in day-to-day support conversations, and needed a route into the documentation.
- 04The customer voice to hearThe questions arriving at support were the clearest signal of what the help centre should answer, and nothing yet connected the two.
02
Evidence first, then priorities
The first phase was analysis. Every available source was inventoried and assessed for accuracy and duplication, from published help content and internal product documentation through to support conversations and structured interviews with the people who know the products best.
Because the products ship continuously, claims were verified against the live software. Priorities then came from the evidence: topics were ranked by support volume, business risk and how often they blocked an operator, and sequenced so the areas with the fastest return were prioritised.
Where the evidence came from
Six source types, cross-checked against each other: the existing help content; internal product documentation, release notes and API references; support tickets and customer-success conversations; training and webinar recordings; structured interviews with product managers and specialists; and a first-hand capture of the live product.
Where sources disagreed, the subject-matter expert who owned that area settled it.
How the work was sequenced
Coverage was mapped topic by topic against the current product, then scored against real support demand: how often a question comes up, and how many clients it affects.
That produced a ranked roadmap across three horizons — immediate, near-term and foundation — so the areas removing the most support load were available to the team internally first, with the structural work landing underneath them.
03
From system architecture to user intent
The previous help centre was organised around the shape of the software, so a reader had to work out which part of the system their problem belonged to before they could start looking. The rebuild is organised by product area and by task, with AI search and a route to support at the top of the page.
A reader should not need to know where a feature lives in the software before they can find out how to use it.
04
An atomic content architecture,
built for search
Dense manuals were replaced by a single atomic format: one article per job to be done, tagged consistently, with the prerequisites and steps a reader needs.
That structure is also what AI search needs. Consistent terminology and one task per document are what let it return a specific answer instead of a page to read.
Authoring and publishing
Content is written as Markdown in version control and published to GitBook. Every change can be reviewed and reversed before it reaches a customer, and specialists still contribute in the interface they already use.
The running knowledge log
Product knowledge arrives continuously as messages, recordings, release notes and support threads. A structured log became the intake point: 225 entries, each dated and traceable to its source. Changes are tracked as they land, so any claim can be traced back and re-verified later.
Standards the tooling can enforce
Checking a navigation path, confirming a claim has a source, keeping terminology steady across 230+ articles: repetitive judgement work, which an AI agent does reliably once the standard is written down. That standard became 18 automation skills covering drafting, review, release monitoring and knowledge capture, so the same checks run no matter who runs them.
05
Testing coverage against real demand
Coverage is only worth as much as the evidence behind it, so the rebuilt help centre was tested against questions people had genuinely asked. A reverse-test pipeline ran twelve months of anonymised support conversations against the new articles, graded each question with cited evidence, and had every verdict independently re-checked.
Coverage validated at 85%, with a specific improvement action recorded for each question that fell short.
- Documentation audit and coverage mapEvery legacy source assessed against the current product, with a decision per topic.
- Launch-readiness reportCategory-by-category view of what was ready to publish and what remained open.
- Search insights trackerA standing record of what customers ask and what it implies for the content.
- Release change logEach product release mapped to the articles it affects, so documentation moves with the roadmap.
- Governance modelOwnership, review cadence and publishing rules, written down and handed over.
06
What the client owns now
Figures from the project repository at handover.
A feedback loop that runs on its own
Questions asked of AI search are pulled on a schedule, checked against the published content, and confirmed gaps ranked into a backlog. The roadmap is set by what customers actually ask.
Support time spent where it is worth spending
Support answers from the same source customers read, so the answer is consistent wherever it comes from, and the team can prioritise the cases that need a person.
An operating model the team runs independently
A release ships, a monitoring workflow flags the articles it affects, drafts go to a staging space, a specialist reviews, and merging publishes. Every open item in the backlog has a named owner and a next step.
07
Expertise applied
Content architecture
- Atomic content design — one task per article, tagged and templated
- Task-first information architecture tested against real questions
- Taxonomy and terminology control across the corpus
- Audit and coverage mapping of legacy content
Evidence and analysis
- Reverse-testing coverage against real support demand
- Search-log analysis as a content signal
- Product UI capture for verifiable ground truth
- Evidence-based prioritisation
Systems and tooling
- Docs-as-code — version-controlled authoring and review
- AI search readiness — structure built for retrieval
- Agent skill design — standards encoded as workflows
- API integration for analytics and content operations
Delivery
- Cross-functional stakeholder management across product, CX and support
- Interview design and synthesis — expert conversations turned into reference
- Governance design — ownership, cadence, review
- Handover that outlives the engagement