Answer the questions that stall a new signup

Most churn in the first week is not a verdict on your product. It is one unanswered question at nine in the evening.

Start free Read the install guide

No credit card. Two lines of script.

Step 3 of 5

Verify your sending domain

CNAME record…

Waiting for DNS to propagate.

where do I find the CNAME?

In your DNS provider, under records. Add it as a CNAME with the host shown above.

Domain setup

Help where they are: In the app, on the step that stalled them.
Any hour: Most self-serve signups happen outside your working day.
Honest about gaps: It will not promise a feature you have not built.
Blockers, ranked: The questions new users ask that nothing answers.

A half-open laptop, a setup checklist with the first three items ticked and the rest untouched, and a coffee gone cold beside it.

The drop-off happens between steps, not at them

Onboarding analytics show where users stop, never why. The reason is usually a small, specific, undocumented-in-the-right-place question — and the cost of asking support is high enough that most people simply close the tab instead.

Activation stalls at the same step and nobody knows what the blocker is
New users ask setup questions that the docs answer in a different section
Support tickets in week one are almost all 'how do I' rather than 'it is broken'
The people who churn quietly never filed a ticket at all

What actually unblocks a new user

What unblocks a new user is rarely a feature. It is the one small thing nobody wrote down in the place they went looking for it.

In-product, not in a new tab

Two lines of script put it on the page where the user got stuck, so they never leave to go looking.

Your real documentation

The same material your help centre serves, searchable in plain language rather than by article title.

Evenings and weekends

When most trials are actually started, and when nobody is online to answer.

No invented features

Asked for something you do not do, it says so — instead of a confident yes that costs you the account later.

Real bugs reach people

A defect escalates with the transcript rather than being answered around.

Product feedback, grouped

Ranked unanswered questions from trial users, in their words, before they churn silently.

Help where the user already is

The widget sits in the product, so a stuck user does not have to leave, search a separate docs site, and come back. The answer arrives in context and cites the page, so the curious can keep reading.

Answered without leaving: No new tab, no separate docs site to search, no losing their place in setup.
Answers from your real docs: Whatever you publish or upload, reachable by describing the problem rather than naming it.
Available at any hour: Nobody has to wait for your working day to start before they can carry on.
Escalates when it should: A real defect reaches a person rather than a paraphrase of your docs.

The chat widget open over a web page, greeting a visitor with suggested questions and a visible route to a person. — The same script tag that sits on a marketing page sits on an authenticated one.

Find the blocker you could not see

Because every unanswered onboarding question is logged and grouped, you can see which step people actually got stuck on, rather than only where the funnel says they stopped. It is the qualitative half that funnel analytics never gives you.

The real wording: How users describe the step, which is rarely how your UI labels it.
Grouped by demand: The most common blocker, first, rather than a pile of individual tickets.

Honest about what is not built yet

When a new user asks for something you do not do, a confident invented yes is the worst possible outcome — they will discover the truth later and it will cost you the account. Refusing plainly and capturing the request turns that moment into product feedback instead of a broken expectation.

The honest part

A confident yes is the expensive answer

The worst outcome in week one is not a question going unanswered. It is an assistant cheerfully confirming a feature you have not built, because the user finds out later, and by then it is a refund conversation rather than a support one.

It answers from your content, so it has nothing to invent a feature from
Asked for something you do not do, it says so plainly
That refusal is recorded, in the words the user used
A genuine defect escalates with the transcript rather than being talked around

Which means the gap list from trial users is partly a support backlog and partly a roadmap. Reading it as only one of those is how teams miss the interesting half.

A studio wall of kraft paper covered in sticky notes in rough columns, raking side light throwing a shadow from each one.

does this do recurring invoices?

Not in the documentation

“I don't have anything on that.” Then a route to a person.

Recorded as a gap, in their words

Putting it inside the product

The same install as a marketing site, with two differences worth getting right: what it can see, and where it is allowed to run.

The knowledge tab with the upload file source type selected, showing a file drop area alongside the other source types. — Setup guides that were never published on the web can be uploaded directly.

1
Index the setup material
Your docs, plus anything internal that explains configuration. Uploads cover what is not published publicly.
2
Put it on app pages
The widget is a script tag, so it sits on authenticated pages as easily as on your marketing site.
3
Lock it to your app domain
Domain locks decide which origins may serve it, which is what keeps an in-product assistant in-product.
4
Read the blockers weekly
The gap report from trial users is the most direct read on what is confusing about your onboarding.

Putting it inside the product

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

Can it run inside a logged-in product, not just a marketing site?

Yes. The widget is a script tag, so it can sit on application pages as well as public ones. Domain locks control which sites are allowed to serve it.

How does it know about features that are not publicly documented?

Alongside crawled pages you can upload documents, so internal setup guides and material that is not on the public site can still be part of what it answers from.

Will it tell users a feature exists when it does not?

It answers from your content and refuses outside it, so it has nothing to invent a feature from. Those refusals are recorded, which is how you find out what people expected you to have.

All solutions