SaaS

Support a self-serve product without a round-the-clock team

Self-serve means people sign up at 2am from a timezone you do not staff, get stuck on step three, and never come back.

Start free See it in-product

No credit card. Two lines of script.

“How do I connect my domain?”

“What's the difference between the plans?”

“Is there an API for this?”

“Can you look at my account, it's not syncing?”

What a software product actually gets asked

Both columns matter. The right-hand one is what a reader is really checking for, so it is on the page rather than in a footnote.

Answered from your own pages

The reply is the answer, with a link to the page it came from.

“How do I connect my domain?”
“What's the difference between the plans?”
“Is there an API for this?”
“Can I invite my team on the free tier?”
“Where do I find my API key?”

Handed to a person

Declined plainly, then routed with the whole conversation attached.

“Can you look at my account, it's not syncing?”
“Will you build SSO for us?”

Each of these arrives with the whole conversation attached, so whoever picks it up starts from what the customer already said rather than from a one-line message.

A laptop closed mid-task beside a notebook with a half-written list, hard morning light striping the lid.

The support load arrives before the revenue does

Free trials generate the most questions and the least revenue. Staffing for that volume is not viable early, but leaving it unanswered kills activation — which is the number the whole business depends on.

Trial users ask setup questions the docs already answer
Activation drops off at a step nobody can identify from the funnel
Support load scales with signups while headcount scales with funding
Plan and limit questions reach sales instead of resolving themselves

You have already written most of it

Point the crawler at these four and the assistant has what it needs. There is nothing to re-author, and nothing to keep in sync afterwards.

01
Product documentation
The setup material you already maintain for support.
02
Pricing and plan limits
What each tier includes, quoted rather than estimated.
03
Changelog and release notes
So the answer moves when the product does.
04
Internal setup guides
Uploaded, for the material that was never published.

Your docs, answerable in plain language

SaaS documentation is usually thorough and usually organised around your architecture rather than around the user's question. Semantic matching bridges that: a user asking about 'an extra login' reaches the page about seats without knowing your vocabulary.

Setup and configuration: The how-do-I questions that dominate week one, answered in context.
Plans and limits: What each tier includes, quoted from your pricing page rather than estimated.
In the product, not beside it: A script tag puts it on application pages, so a stuck user does not have to leave.
Bugs reach humans: A genuine defect escalates instead of being answered around.

The gap report is a product signal

Ranked unanswered questions from trial users is one of the more direct pieces of product feedback you can get. It tells you which part of the setup flow is confusing, in the users' own words, before they churn quietly and tell you nothing.

Honest about the roadmap

When an evaluator asks whether you support something you do not, a confident invented yes costs you the account later. Refusing plainly and recording the request turns a lost deal into a prioritised feature request.

In the product, not a new tab

Two lines of script put it on the page where the user stalled.

At the hour they signed up

Self-serve trials start in the evening, in a timezone you do not staff.

No invented roadmap

Asked for something you have not built, it says so instead of promising.

Blockers, in their words

The ranked gap list from trial users is the qualitative half of your funnel.

Where the line is

It answers about the product, not about the account

The assistant reads your documentation, not your database. It can explain how a feature works, what a plan includes and where a setting lives, but it cannot look inside one customer's workspace to see why their sync failed.

Documentation and pricing questions: answered, with the page
Account-specific debugging: escalated with the transcript
A feature you have not shipped gets a plain no, not a maybe
Every refusal is recorded as a gap, in the user's own wording

The refusals are the interesting output here. A trial user asking for something you do not do is product research you did not have to run — and it arrives before they churn quietly.

Two colleagues at one desk reviewing something on a single monitor, one pointing mid-sentence.

“Do you support SAML SSO?”

Not in the documentation

A plain no, not a “coming soon”.

Content gaps · this week

Single sign-onasked again

What product teams ask first

Short answers. If yours is not here, the assistant on this page will try it — and tell you honestly if it cannot.

Can it answer questions about a specific account's usage or billing?

No — it answers from your published content, not from your database. It can explain how billing works and what a plan includes; anything about a particular account escalates to a person with the conversation attached.

Can it sit inside the authenticated product?

Yes. The widget is a script tag and can be placed on application pages as well as marketing ones, with domain locks controlling which sites may serve it.

How do we keep it current as the product ships?

It re-crawls on a schedule and re-indexes only what changed, so a shipped docs update reaches the bot without anyone remembering to refresh anything.

All solutions