Platform
What we buildHelp centreSecurityComplianceReliabilityScalabilityEfficiency Platform overviewSolutions
Startup foundersEstablished businessesOperations teamsIntegrations
Payments, billing & taxAccounting & ERPIdentity, access & auditEmail deliverySMS & voiceElectronic signature All integrationsHelp centre
You ship a feature and nobody uses it, because nobody knew it existed. The documentation, the announcement and the answer to the support question all come from one place — generated from the application itself.
Because we built the application, we know what it does. The help site is generated from that — so it does not drift, because nobody is maintaining it by hand.
There is a quiet failure that happens to every product: features get built, shipped, and then used by almost nobody, because the only people who knew they existed were the ones who built them. The usual fix is documentation, written separately, by someone with other priorities, and stale within two releases. We take a different route. The help centre is produced from the application itself and published on your domain, the changelog writes itself from what actually shipped, your customers get told, and your support chatbot answers from the same content without anyone being involved.
Not a separate document that has to be kept in step. The same source of truth as the thing it describes.
We hold the application, so the help centre covers what it actually does rather than what someone remembered to write down. New screens and new rules arrive in the documentation with the release that introduced them.
A real site at help.yourcompany.com, with your branding, fast and responsive — not a link into a third-party knowledge base that looks nothing like your product.
Instant full-text search across every article. Most people arrive with a specific question and abandon a help site that cannot answer it in one query.
Clean markup, sitemaps and structured data, so search engines and AI assistants can find and cite it. Increasingly, that is how your customers actually reach an answer.
Open to everyone for discovery and SEO, or behind sign-in where what you document is commercially sensitive. Sections can differ.
Where your customers are not all in one market, articles can be maintained in parallel rather than translated once and forgotten.
Roadmap · next
A changelog is the cheapest possible proof that a product is alive and being invested in.
What changed, dated, permanent and linkable. Generated from what actually shipped rather than assembled from memory at the end of a quarter.
Not commit messages. "You can now export a month of jobs to a spreadsheet" — what changed for the person using it, not what changed in the code.
New, improved, fixed. Most readers only want one of the three, and a wall of undifferentiated bullets gets closed.
A panel in the application itself showing what has changed since that user last looked — where they are already working, at the moment they might use it.
Customers who want every release can have it. The ones who do not are not forced to care.
Publishing a change is not the same as anyone hearing about it. This is the step almost everyone skips.
Sent automatically from the release notes, through the email provider already wired into your application. You do not write it, and you do not schedule it.
Each customer gets what changed since their last digest rather than a repeat of the same list, which is the fastest way to train people to ignore an email.
Administrators hear about administrator features; field users hear about the mobile screens. Relevance is what keeps an announcement email being opened after month three.
One click lands on the actual screen with the thing switched on. Every extra step between reading and trying loses most of the audience.
Opens and clicks, and then the number that matters: did the people who were told go on to use the feature. That tells you whether the problem was awareness or the feature itself.
The same content, doing a second job — without your team in the loop.
The assistant in your product answers from your own documentation, citing the article it used, so the customer can check the answer rather than trust it. No separate training exercise and no second copy to maintain.
The documented eighty per cent get resolved at the moment they are asked. Your team sees the remainder, which is the part that actually needs a person.
What customers search for and do not find, and what the assistant could not answer, is reported back. That list is the most useful documentation backlog you will ever have.
When it hands over, the conversation, the account and the articles already tried go with it. Nobody starts again from "can I take your account details?"
Ten times the customers should not mean ten times the support load. Deflection is the only mechanism that makes that true.
The specifics
Switched on when you have customers to tell. Like everything else, it is a toggle.
| Item | What you get |
|---|---|
| Help site | Public site on your own subdomain, with TLS and your branding |
| Content source | Generated from the application; you review before anything publishes |
| Search | Instant full-text search across every article |
| Discoverability | Sitemaps and structured data, so search engines and AI assistants can cite it |
| Release notes | Per release, categorised as new / improved / fixed, permanently linkable |
| In-app | A what's-new panel showing changes since that user last looked |
| Email digest | Weekly or monthly, segmented, sent via your existing email provider |
| Chatbot source | The same content, answered with citations |
| Reporting | Searches, articles read, unanswered questions, and feature use after announcement |
| Access | Public, or gated behind sign-in, per section |
| Languages | Multiple — on the roadmap |
We do, from the application we built. You review it before it publishes and you can edit anything — but the default is that documentation exists without you having to find someone to write it.
Staleness is the failure mode this is designed around. The help centre is produced alongside the release rather than as a separate task competing with everything else, so a feature and its documentation ship together.
Yes — and, increasingly, in AI assistants, which is now how a large share of people look for an answer. The site is structured so both can read and cite it. This is one of the few places where being indexed is the entire point.
Then it sits behind sign-in. You can also mix: public articles for discovery, gated ones for the parts you would rather competitors did not read.
It answers from your help centre and shows the article it used, so a person can verify it. When the content does not cover the question it says so and hands over to a human rather than guessing — and that question goes on the list of gaps to document.
Yes. Frequency, segments and whether it sends at all are yours. It is a toggle, like everything else here.
Start here
A 30-minute call is enough for us to tell you whether we can build it, what it will cost to run, and when it goes live.
