AI for customer onboarding content: write for activation, then check whether it moved

What is onboarding content, and why does it rot?

It is every word a new user reads before they get value once: empty states, first-run tooltips, the welcome email sequence, the setup checklist, the first few help articles, the in-product nudges that fire in week one. Nobody owns all of it. A designer wrote the empty states, a marketer wrote the emails, an engineer wrote the error strings, and support wrote the articles after the fact.

That split ownership is why onboarding copy drifts out of sync with the product faster than anything else you publish. A release renames a button, and eleven strings across four systems still use the old name. No single person sees all eleven, so the inconsistency is discovered by a new user, which is precisely the worst audience for it.

AI is genuinely good at this problem and genuinely dangerous applied to it, for the same reason: it removes the cost of producing more.

What should you decide before writing a single line?

The activation event. One sentence, testable in your data: the moment a new user has got value once. Not signup, not "completed setup," not profile photo uploaded. The thing that, once it happens, makes the rest of the relationship plausible.

Every piece of onboarding content then has one job, which is to shorten the path to that event or remove a reason someone stops before it. Content that does neither is decoration, and generating decoration is exactly what a model will do very well if you do not give it this constraint. Amplitude's North Star material makes the same argument at the product level: pick the one measure that represents value delivered, then judge work against it.

Write the event down and sanity-check it against activation rate. If you cannot query it today, stop and fix that first. A rewrite shipped into a system that cannot see the change will be evaluated on opinion, and opinion will favour whoever wrote the copy.

Where does AI earn its place here?

Three jobs, in order of value.

The audit comes first and almost nobody does it. Export every onboarding string you have, paste the lot into a model, and ask which ones assume knowledge a first-day user does not have, which ones name things that no longer exist in the product, and which two say contradictory things about the same step. That inventory is unpleasant to assemble by hand and it is where the real defects are. Expect the model to over-flag; over-flagging is the right direction for an audit.

Second is variation at volume. One approved voice, twenty empty states. One welcome sequence, rewritten for three segments with different first jobs. The same instruction at two reading levels for a product used by both specialists and occasional users. This is the asset creation workflow that Product Marketing with AI teaches as a step in the loop: generate the assets, then edit for accuracy and tone, rather than accepting the first draft as finished.

Third is the boring rewrite pass: strip the marketing adjectives from in-product copy, cut every sentence that explains why the feature matters rather than what to do next, and replace abstractions with the exact label the user is looking at. Models do this reliably when you ask for it explicitly, and it improves onboarding copy more than any amount of new material.

What is the trap?

Writing content for a step that should not exist.

A model asked to explain a confusing control will write a clear, patient, well-structured explanation of the confusing control. It will never say "delete this step." That is the correct behaviour for a drafting tool and the wrong outcome for onboarding, because the tooltip you just generated is now a permanent tax on every future user, and it makes the underlying flow harder to change because something depends on it.

Nielsen Norman Group's work on onboarding tutorials lands in the same place: instructional overlays are weaker than an interface that does not need instruction, and teams reach for the overlay because it is cheaper to ship than a flow change. Generation makes that asymmetry worse. Before writing any first-run hint, ask whether the step earns its place at all, and give the model that question rather than the writing task.

One more thing that gets skipped because onboarding copy often ships outside the design review: the accessibility of the pattern, not just the words. Overlays, low-contrast hint text and dismiss affordances all have specific requirements in WCAG 2.2, and a generated string dropped into a non-compliant component inherits the problem.

How do you tell whether any of it worked?

By cohort, and by a metric chosen before the work started.

Compare users who signed up after the change against users who signed up before, week by week, rather than reading an aggregate number that mixes six months of existing users into the same bucket. Cohort analysis is the mechanic, and it is the same one Growth for Product Managers teaches when it covers building cohorts and reading retention curves rather than trusting a single headline number.

Be honest about what this design can and cannot tell you. A pre and post comparison across signup cohorts is confounded by everything else that shipped that month, by seasonality, and by whatever marketing changed about who was arriving. It is still worth running, because the alternative is no evidence at all, and a large move in the activation cohort is a real signal even when you cannot fully attribute it. A small move is not, and should not be reported as one. If the change is important enough to defend, run it as a controlled experiment rather than a rewrite.

Three measures are worth having on the same screen, and no more: the share of new users reaching the activation event, the median time from signup to that event, and the step where the largest share stop. The third one tells you where to write next; the first two tell you whether writing helped.

Who should own this after the first pass?

Whoever owns activation, which in a product-led growth setup is usually a growth product manager rather than a writer. That is the ownership model the Growth Specialist Track is built around: loops, experimentation, measurement and monetisation held by one person rather than split across marketing and product.

The practical version is a standing review. Every release that changes a label, a step or a default triggers a re-run of the string audit, which takes minutes with a model and hours without one. That cadence, not the initial rewrite, is what keeps onboarding content true.

The line nobody writes, and should

Add one sentence to your onboarding that says what the product will not do for this user. The setup checklist that promises everything produces a second-week user who feels misled, and the fastest way to lose a new account is to have been unclear on day one about the thing they were actually hoping for. A model will not write that sentence unless you ask for it, because nothing in its training suggests that onboarding copy is where expectations get lowered on purpose.

See the Product Marketing with AI bootcamp

For the prompting patterns behind the audit and the rewrites, ChatGPT for product managers covers the assistant side in more detail.