Design a welcome sequence that fulfils the signup promise

Give the first message one job

A welcome message should make the subscription recognisable and fulfil the promise that brought the reader there. It may introduce the edition, provide a resource or explain how to choose useful preferences. Those jobs can be completed without packing every product, article and commercial offer into one email.

Begin with a short note about what the reader expected at signup. Then choose the one next action that helps them use the publication. The creator newsletter guide and the publisher guide show why that action can differ between audiences. For downloadable material, the e-book delivery guide is the related page.

Write entry, re-entry and stopping conditions in plain language

Email platforms offer automations triggered by subscriber activity, but availability and behaviour depend on the service and the setup. Mailchimp’s documentation on classic automation types is one example of a specific product describing its own automations. Read it as documentation of that product’s features, not as a promise that the same automation exists on every account, on every plan or on another service.

Treat the trigger as a real system condition, not a marketing label. Three questions need written answers: when does a person enter, can they enter again, and what happens if they unsubscribe or become ineligible before a later step? Put the answers in plain language beside the sequence, where both the editor and the operator will find them.

If a confirmation step is required by your chosen setup, do not count a form request as the same event. Mailchimp’s double opt-in documentation is one product’s account of such a step. The subscriber-lifecycle guide helps keep pending, active and stopped journeys distinct, and the signup confirmation guide is about writing confirmation text that matches the actual state.

Worked example: a small specialist publication

Imagine a publication that promises a practical reference sheet and a regular digest. Its first eligible welcome message gives access to the sheet and explains what the digest contains. A later message, if useful, shows how to apply the sheet to a realistic task. Another message might invite the reader to select a relevant topic.

Each step has a reason to exist. If the material can be explained in one message, adding more messages solely to fill a template makes the experience harder to maintain. The example does not imply a universal delay or number of emails; timing belongs to the reader’s task and the publication’s actual product.

Sequence sheet, part one: identity, entry and re-entry

The next three sections work through one planning sheet for the example above; the timing still has to be chosen for the actual publication. It is a suggested workflow, not a record of a real campaign. The publication, here called Small Archive Notes, is invented, and each decision marked ‘proposed’ is that invented editor’s choice, not a rule for your service.

• Name and promise: ‘Welcome to the digest’. The form promised a one-page cataloguing reference sheet and the regular digest.
• Entry event: the confirmation action is recorded and the contact becomes active for the digest. This invented setup requires a confirmation step, so a form request alone does not start the sequence; a pending contact receives only the confirmation message.
• Entry check: immediately before the first step, the contact is not in a stopped state for this publication.
• Re-entry while active: someone who submits the form again while active or part-way through does not start a second copy. Proposed: the public response acknowledges the request without disclosing whether that address is already subscribed. Any account-specific help follows the configured verified route.
• Re-entry after completing: a person who finished the sequence and submits the form again is not sent every step again. Proposed: at most one message re-sending the sheet link, and only if the service can express that rule; otherwise nothing.
• Re-entry after stopping: a person who unsubscribed, then makes a fresh request and confirms, is treated as a new relationship and may enter at the first step. Proposed, pending a test of how the chosen service identifies that contact.
• Not an entry: contacts brought in by a migration are not new signups and do not enter by default. Welcoming them is a separate decision that starts by checking the original promise and any current stops.

Sequence sheet, part two: steps, timing and stops

The number of steps below belongs to this invented publication’s content and is not a recommendation.

• Step one: delivers the sheet link, says in a few sentences what the digest contains and names one next action, opening the sheet. It carries no commercial offer.
• Step two: kept only if the editor can name a reader task. It shows how the sheet applies to one realistic cataloguing task. If step one already covers that task, step two is deleted rather than kept for symmetry.
• Step three: optional. It invites the reader to choose a topic and links to the preference page. It is skipped for anyone who has already chosen.
• Timing: left blank on purpose. The editor sets each gap from how long a reader plausibly needs to open and try the sheet, and records the reason. These optional steps are choices for the example, not a standard sequence or a prescribed delay.
• Standalone wording: every step says who the sender is and what the publication is, in case the reader never opened the previous message.
• Stop conditions: the reader unsubscribes from the digest; the contact becomes ineligible in the service; the sheet link is withdrawn; the editor retires the sequence.
• End states written on the sheet: complete, stopped by reader, ineligible, paused by editor.

Stopping a step that is already scheduled

The row that is easiest to leave empty is the one about steps already queued. In the invented example, a reader receives step one and the service has step two scheduled. Before step two is due, the reader unsubscribes. The sheet should say plainly that the stop condition is checked when each step is due, not only when the contact entered, and that a stopped contact does not receive the step.

Whether a particular service checks at that moment, removes the contact from its queue or needs a manual action depends on the service and setup. The sheet’s rule is therefore a requirement to verify by test, not a statement about how any provider works. The unsubscribe and preferences guide covers the reader-facing side of the stop.

• Case A, the reader unsubscribes between steps: step two does not send, the record shows ‘stopped by reader’, and the unsubscribe is not answered with another promotional message.
• Case B, the sheet link is withdrawn while contacts are mid-sequence: the editor pauses the affected step, replaces the link, then decides whether people who received the old link get a correction. The decision and its date go on the sheet.
• Case C, the contact becomes ineligible after step one: remaining steps do not send, and the operator sees the problem as a lifecycle matter instead of it being counted as a completed journey.

Maintain the content behind the automation

Automations can keep distributing old links long after a homepage has changed. Give each sequence an owner and a review record containing the resource links, contact route, stated promise and conditions that stop the sequence. When a guide is replaced, check the welcome message that points to it.

Read the sequence as a new subscriber would. Does the second message assume they read the first? Does a resource link still explain what it provides? Can someone understand the relationship between the sender and the publication without remembering the exact signup page?

Sequence sheet, part three: owners, resources and review

The last rows tie the sequence to the people and links that keep it truthful.

• Owners: the editor owns the wording and the promise; the operator owns the automation settings and the stop rule. Each is a named role, not ‘the team’.
• Resources: the sheet link, the preference page and the page explaining the publication, each with the person who keeps it live.
• Support route: the address or page where a reader reports a missing sheet, and who reads it.
• Review: a date for reading the sequence as a new subscriber, plus an extra review whenever a linked resource is replaced.
• Test record: which controlled accounts were used and when, kept apart from production records.

Measure the journey with the right questions

Look for evidence that the promised material was reachable and useful, not merely that messages were attempted. A reply about a broken link is an operational signal even when click metrics look healthy. A stopped sequence can be correct behaviour for someone who withdrew from the publication.

Test with controlled accounts before using a live audience, and distinguish that test from production results in your records. Use click analysis for the reporting limits and the form-review checklist for the complete path into the welcome journey.

A controlled-account test for the filled sheet

A pass shows only that the setup behaved this way for those test accounts on that day; it is not a measured result about real readers.

• Use one controlled account to confirm that entry happens only after the confirmation action and that the first message arrives with a working sheet link.
• Submit the form again from an active account and check that no second copy of the sequence starts.
• With a second account, unsubscribe after step one and before step two is due. Check that step two does not arrive and that the record shows the end state.
• Open every link in every step and compare what it promises with what it delivers. Record expected and observed results in separate columns, labelled as test data.