Self-service as the second line of defence

Context

Most companies treat the Help Center as documentation: a place where the answer lives if anyone bothers to look. I treat it as the second line of defence in onboarding — when a user gets stuck inside the product flow, the Help Center is the next thing they reach for. If the answer isn’t there, they open a ticket.

Every article saves measurable support cost. Every gap creates it. And at Admirals, every article also serves a second audience: the AI support bot, which reads the same content as retrieval-augmented context. That second audience has different requirements from the human one, and the trick is to write content that works for both.

This case is about building that system.

Problem

When I took ownership of the Help Center, three structural problems were limiting it.

Articles were optimised for the writer, not the reader. Headings described the product feature (“Account verification process”), not the user’s question (“Why is my verification taking so long?”). Long preambles delayed the actual answer. Steps were buried inside paragraphs. The result: low self-serve rate, high “this article wasn’t helpful” feedback, and users falling through to tickets.

The AI bot couldn’t extract clean answers. The bot’s retrieval was pulling whole article paragraphs and synthesizing them into responses that sounded right but were often wrong on specifics — minimum deposit amounts, document requirements, processing times. The bot wasn’t broken; the source content wasn’t built for retrieval.

Localization was inconsistent. 10+ languages, four portals, no shared template, no QA dashboard. Some markets had professional translators; others had cached machine output that hadn’t been reviewed in years. Product changes hit the English version first and trickled out to other languages with weeks of lag.

Approach

1. Re-architected the Help Center IA

The information architecture was reorganised around the user’s journey, not the product’s structure. Four portals, each with a getting-started hub at the top and topical sub-sections below. The hierarchy is shallow on purpose — most users find what they need within two clicks.

Taxonomy is intent-led: a section called “Funding your account” contains everything from “minimum deposit” to “deposit declined”, because those are the questions a user actually asks. The old taxonomy was channel-led (“Wire transfers”, “Card payments”) — better for the operations team, worse for the user.

2. Rewrote the article template

I redesigned the article template so a single article serves both audiences — the human reader and the AI bot — without compromise on either.

The template:

H1 — User's question, phrased as the user would phrase it
       ("How do I make my first deposit?", not "Deposit process")

Atomic answer (first 1–2 sentences)
       The complete answer to the question, in one short paragraph,
       readable in isolation. This is what the bot's retrieval lifts
       cleanly; it's also what the user sees in search snippets.

Steps (numbered, one action per step)
       Action-led, no preamble. Each step is self-contained enough
       that the bot can quote a single step in a response.

Edge cases / what if
       Common failure modes, phrased as sub-questions.
       Each gets its own atomic answer.

Related articles
       Linked by next-question, not by product category.
       What's the next thing this user is likely to ask?

Why this template works for both audiences:

For the human reader: the answer is at the top, the steps are scannable, the edge cases are pre-empted. Helpfulness scores went up, ticket volume on the rewritten categories went down.

For the AI bot: the atomic answer is a clean retrieval target, the numbered steps extract cleanly into structured responses, and the question-led H1 matches user intents more reliably than feature-led headings. Bot answer accuracy improved by 30% on the categories I rewrote first.

3. Built a localization workflow that scales

Translation was the smallest part of the work. The harder part was building a workflow that catches product changes upstream and pushes them through 10+ languages without drift.

What I introduced:

• One source-of-truth language (EN) with mandatory review before any other language is touched.
• Translation QA dashboards tracking outdated articles per language, broken cross-links, terminology drift.
• A glossary of regulated terms that don’t translate the same way in every market (e.g. “professional client” has different meaning under EU vs UK regimes, and the article needs to reflect that, not just translate it).
• AI tooling layered on top of the human workflow to compress first-pass translation time on routine product updates — humans still QA, but the cycle from English update to multi-language live got significantly shorter.

4. Closed the loop with the AI bot

The Help Center and the AI bot share source content. That means improvements to the Help Center improve the bot — but only if the workflow connects them.

I owned the bot’s training and QA in parallel with the Help Center:

• Reviewed bot fallbacks (where the bot couldn’t answer) and used them as a queue of new articles to write.
• Prompted the bot to cite the source article so QA could trace wrong answers back to the source content and fix it once for both audiences.
• Set up a regular review cycle where bot accuracy on specific topics drove which articles got rewritten next.

Outcome

• 60%+ of incoming customer queries now handled by the AI bot across 10 languages — without an accuracy degradation.
• +30% answer accuracy on the topics rewritten with the new template, measured against a reviewed sample.
• −35% repetitive tickets in the top categories — the same categories where the Help Center IA and content were rebuilt.
• Self-serve helpfulness scores up across the rewritten sections.
• Localization turnaround on routine product updates reduced significantly through the AI-layered workflow.

What I’d do differently

Treat the bot as a first-class reader from day one. I built the new article template thinking primarily about the human reader, then realised it happened to work well for the bot too. The bot’s needs are knowable in advance — atomic answers, action-led steps, intent-led headings — and designing for both audiences from the start is faster than retrofitting.

Build the QA dashboards earlier. I spent more time than I should have hunting outdated articles manually before building the dashboards that surface them automatically. The dashboard is now the single most-used artefact of this work.

Push article structure upstream into the product release process. Right now Help Center updates follow product releases. The cleaner version is for the article to be a deliverable of the release itself — written by the product team, edited by content, with a template that makes it close to a fill-in-the-blanks form. We’re moving in that direction, but it’s not there yet.

Work led at Admirals from 2023 to present. Article template described is the template now used across all four portals.