Onboarding emails: follow product milestones, not a calendar

For our hypothetical app, account creation is not activation. A team gets initial value when it creates a project, assigns real work, and sees a teammate complete a task. That is a proposed definition to validate with product evidence, not a truth about every collaboration tool. Choose an outcome close enough to real value that improving it matters, but observable enough that you can evaluate the journey.

Map the prerequisite steps and the likely obstacles. A person who has not created a project may need a small example. A person who has a project but no teammates may need help inviting the right collaborator. Someone who completed the whole path does not need an invitation reminder. This map tells you what the message should do before a copywriter or agent writes a sentence.

A signup event can start a candidate journey, but it cannot tell you whether the person finished onboarding ten minutes later. CloudEvents gives a useful vocabulary for event identity and context; it does not define your product’s activation or send eligibility. Keep those decisions in your workflow. Use stable event identifiers for deduplication and verify relevant current state before dispatch.

Separate occurrence time from processing time. A delayed ‘project created’ event should not enroll an already active team in an obsolete reminder. If the event pipeline is unhealthy, pause state-dependent messages rather than converting missing evidence into ‘user did nothing.’ Define how long a reminder remains useful. After the intended help window expires, discard it or create a new reviewed message based on current conditions; do not release a backlog as if it were timely.

Reference: CloudEvents specification 1.0.2

Our first welcome delivers the getting-started resource the person requested. A later candidate message helps create a first project only if that step remains incomplete. Another offers a concise invitation example only when collaboration is the missing piece. These are branches, not a fixed string of increasingly urgent reminders. Keep the resource and next action specific to the identified obstacle.

Write copy that acknowledges what is known without inventing a psychological explanation. ‘Your workspace does not have a project yet’ may be supportable; ‘You are struggling to get organized’ is an inference. Offer a small action and an optional help path. Avoid turning every onboarding email into an upgrade pitch. Commercial messaging can have a place, but it should not obscure the promised help or be mislabeled as a necessary service notice.

Begin with one milestone and one candidate reminder, not twelve messages. The following specification is deliberately incomplete until your team chooses approved destinations, timing, and eligibility policy. It is a planning artifact for a reviewer, not authorization for an agent to send.

At each exit, record why work stopped: completed milestone, changed preference, expired usefulness, missing state, or manual pause. These outcomes are not all failures. A subscriber who succeeds without receiving another reminder may be the best result. Keep suppression and cross-flow frequency rules outside the copy generator so a well-written draft cannot override them.

Journey: first useful project
Entry: verified signup event for an eligible user
Goal: a real project reaches its first completed task
Candidate help: one approved project-start guide
Before dispatch: refresh progress, preferences, suppression, and frequency budget
Exit: goal complete, ineligible, expired, or state unavailable
Missing facts: hold and request evidence; do not infer inactivity
Authority: draft and review before any authorized dispatch

Record activation within a predeclared observation window, time to that outcome, and the fraction needing support. Include complaints, unsubscribes, and total message burden as guardrails. A higher click rate can coexist with worse onboarding if people click because the email is confusing. Opens are not a reliable stand-in for understanding or product use.

Where practical, compare the proposed help against a suitable randomized holdout or an alternative reviewed message. Do not withhold security or genuinely necessary service mail for a marketing experiment. Preserve assignment and evaluate all eligible assigned users, not only those who clicked. Inspect whether small groups or missing telemetry make the result uncertain. The journal’s holdout guide gives a more detailed design; a dashboard’s attribution label alone does not establish the journey caused activation.

Provide the observed step, the approved help resource, the audience rule, and the desired reader action. Ask for a draft that retains the resource link, neutral personalization fallbacks, and required footer. Keep statements about the user grounded in verified state. If the product event is missing or contradictory, have the agent return a short question instead of manufacturing a helpful-sounding diagnosis.

Start with a Moosewave welcome or onboarding template and review it against the actual step it serves. Test completion just before dispatch, repeated signup events, a changed language preference, and overlapping promotional work. Include a synthetic user who finishes without any email. A successful onboarding system should recognize that success and become quieter; it should not keep sending because the calendar has more slots.

• The milestone represents useful product progress.
• Each reminder checks current state before sending.
• Completed and expired journeys have defined exits.
• The message has one approved next action.
• Outcome and message-burden measures are reviewed together.

• CloudEvents specification 1.0.2. Event identity and context. Activation definitions, current-state checks, and the example journey are our applied design recommendations.

Sources checked 11 October 2026. Product behavior and documentation can change, so the linked primary source takes precedence if it differs from this article.