Answer first
Design the trigger, retained context, branches, waits, exits, and handoff before writing messages.
Reusable nurture sequence map
| Stage | Question | Control | Exit |
|---|---|---|---|
| Entry | What specific event creates eligibility? | Consent, source, deduplication | Invalid, duplicate, or suppressed |
| Context | Which facts should change the next step? | Fields, answers, score, outcome, event | Required context missing |
| First action | What is immediately useful? | Relevant email, route, booking, resource | Goal completed |
| Wait | How long should the lead have? | Fixed, local time, conditional wait | New high-intent event |
| Branch | What evidence changes the route? | Click, score, page, product event, answer | Disqualified or sales accepted |
| Handoff | Who owns the next action? | Owner, task, alert, deal, booking | Sales state updated |
High, medium, and low readiness
High readiness should reduce delay. Send the most relevant confirmation, expose the booking or purchase path, and alert the right owner. Medium readiness needs education and a clear engagement branch. Low readiness should still receive value but at a slower frequency with a strong suppression rule.
Design exits before messages
Write the success, suppression, disqualification, duplicate, purchase, booking, and sales-accepted exits first. Then write messages for the contacts who remain. This prevents the common failure where leads keep receiving education after the meeting is booked. Use the seven-message sequence template to turn this compact map into a message-by-message path with branches, waits, exits, and acceptance tests.
How to use this guide
- Name the business outcome and the event that starts the path.
- Mark the system that owns each piece of context.
- Write the conditions that change timing, message, route, or next step.
- Define every exit before building messages.
- Test the two handoffs most likely to lose context.
- Record the plan, date, source, expected result, and actual result.
Evidence boundary
This guide uses current public product documentation and the publication’s evaluation model. It does not claim a hands-on product test unless a dated record is labeled Workflow tested.