Lifecycle email: start, branch, and stop each sequence
Lifecycle email starts from a contact change or product event, such as signup, activation, or payment failure. Check current customer state as the sequence runs so people stop receiving reminders they no longer need.
How lifecycle email differs from campaigns
A campaign is a one-time email sent to a selected audience, either immediately or on a schedule. A lifecycle email starts from a contact change or product event, so each contact can enter at a different time.
Which lifecycle emails should you build first?
Begin with welcome and onboarding. Add trial, product education, and re-engagement emails as you identify the customer actions that should trigger them.
Send a welcome email on signup or Contact added. Explain what the contact can do next and link to the first setup task.
Follow welcome with onboarding emails for the required setup steps. Use one message per step, then stop when the activation property changes.
Trial conversion. Explain what remains incomplete, what changes at expiry, and stop later reminders after the contact converts.
Product education. After activation, send the next feature or use case based on role, plan, or completed actions.
Retention and churn risk. Trigger from a product event or contact-property change your app defines, then leave the path when activity returns.
Re-engagement and win-back. Define a dormant state, send a short sequence, and set a clear exit if the contact returns or stays inactive.
Start with the Welcome template, then adapt Onboarding Drip for incomplete setup and Upgrade After Trial for trial conversion. The SaaS template library has layouts for each stage.
Which events should start, branch, and stop a sequence?
Choose a trigger, the properties that determine each branch, and the condition that ends the sequence.
Choose a trigger that marks entry into the stage: contact created, trial started, plan updated, or invoice paid. Loops supports four workflow triggers: Contact added, Contact updated, Contact added to list, and Event received.
Choose branches from current contact properties such as role, plan, activated, or canceled. Your app can update those properties from product events. Event properties can personalize the next email.
Define the state that should end the sequence: activated, converted, canceled, or returned. Apply an audience filter to All following nodes. After the state changes, the contact leaves when the filter is checked at a following node.
For exact behavior, see Triggering workflows and Branching workflows.
How lifecycle email changes by customer stage
The contact’s current stage determines the next email. Store that stage in contact properties your app updates.
During a trial, help the contact complete a setup task and explain what changes at expiry. Update plan status after conversion so the audience filter can stop later trial emails.
Paying customers can skip setup they already completed. Choose a feature or account task that matches their role and use case.
Define churn risk from your product data, such as a usage drop or a missing key event. Send an event or update a contact property when the threshold is crossed and when activity returns.
After cancellation, end trial, expansion, and retention nudges. Send only required account or billing messages and marketing the contact remains subscribed to.
See how product activity changes the sequence in these onboarding email examples.
How to stop onboarding and trial emails after conversion
Check current activation and plan state before sending another onboarding or trial email. A contact may have converted since they entered the workflow.
1. Store activation and plan state as contact properties, such as activated = false and plan = trial.
2. Start the workflow with Contact added, or send a signup or trial-started event to an Event received trigger.
3. After the first Timer, add an audience filter for the state that should still receive the remaining emails. Set the filter to All following nodes.
4. When your app updates the property after activation or conversion, the contact stops matching. The filter removes them when they reach a following node.
Dunning emails: recover failed Stripe payments
Dunning is the sequence of reminders sent after a payment fails. Start with invoice.payment_failed, keep each reminder tied to that invoice, and stop when the invoice is paid or its recovery case is closed.
Loops’ Stripe - Payment Failed workflow template uses Event received → Stripe → invoice.payment_failed. Enable that event in the Stripe integration settings. This starts an email workflow for your subscribed audience. The integration syncs contact email and optional names. Your app must maintain any custom recovery state.
For essential billing notices that must work independently of marketing subscriptions, use a published Loops transactional template. Your backend decides when to send and supplies the billing recipient, invoice details, and billing link as data variables. Keep these messages limited to the payment issue.
Choose a dunning reminder schedule
Choose which service sends each reminder. Stripe can email after payment failures, so check its customer email settings before enabling the equivalent Loops message. Stripe’s payment retries and your email schedule are separate settings.
After the first failure, explain which payment failed and link to the billing page.
Three days later, remind the billing contact if that invoice is still unpaid and eligible for recovery.
Before your actual grace-period deadline, explain the access change that will happen if payment remains unresolved.
This is an example schedule. Adjust it to your retry settings and access policy. Include the invoice amount and currency, a working billing link, and only dates you can confirm. Updating a payment method does not prove that the invoice has been paid.
Stop stale or duplicate payment reminders
Store recovery state in your app by invoice ID, with the billing contact, reminder stage, next send time, and send result. One contact property such as subscriptionStatus = Failed cannot distinguish two unpaid invoices or a new failure while an older reminder is waiting.
Deduplicate incoming Stripe events by event ID, then retrieve the current invoice before changing recovery state. Stripe can deliver events out of order. A delayed failure event must not restart reminders for a paid invoice. Repeated failures for the same invoice must not create another copy of the sequence.
Before each scheduled send, check the current invoice again and claim a unique record for its invoice ID and reminder stage so two workers cannot both send it. Stop remaining jobs when payment succeeds, the invoice is voided, or your team closes the recovery case. Subscription cancellation alone does not prove that an outstanding invoice was paid.
Keep the send record across retries. If a Loops request times out, retry the same request with the same Idempotency-Key within its 24-hour window. After that window, reconcile the uncertain send before issuing another request. A timeout does not prove that no email was sent.
For a workflow that sends only to marketing subscribers, your app can update a recovery property. Set an Audience Filter to All following nodes so contacts leave when they no longer match at a later node. If recovery cases can overlap for one contact, schedule reminders by invoice ID in your app.
Test payment recovery before enabling it
Replay the same event and send another failure for the same invoice. Expect one recovery sequence and no duplicate reminder stage.
Pay during a delay, then deliver an older failure event. Expect no later reminder and no new enrollment for that paid invoice.
Give one billing contact two invoices, then pay one. Reminders must still refer to the correct unpaid invoice.
Block a send with a missing billing link. After an API timeout, retry with the same idempotency key. Confirm that a marketing opt-out still permits the essential transactional notice, and check that Stripe does not send a duplicate reminder.
Measure recovery from invoice outcomes in Stripe. A successful email API response means the send was accepted. It does not mean payment succeeded or that the email caused the recovery.
How to run churn-risk and re-engagement paths
Loops does not calculate churn risk for you. Your app defines the threshold, then sends an event or updates a contact property when a contact crosses it.
Link the churn-risk email to a task the customer has stopped doing, such as returning to an unfinished project. When activity resumes, update the contact property so the audience filter excludes them from later reminders.
Define inactivity from how often customers normally use the product. A weekly-use product and an annual-use product need different windows. For dormant contacts, send a product update followed by a relevant use case. End the sequence if they return or remain inactive after its final message.
Use the email churn rate guide to choose the metric and monitor it.
Compare the win-back email examples for ways to invite inactive users back. Check current activity and subscription state before sending.
Campaign or workflow for product updates and digests?
Use a campaign when the content is the same for a defined audience and the send happens on a schedule. For a product update, have your app store activity in a contact property. Filter to active users and send once.
Use a workflow when product behavior decides whether the message sends or what it contains. Trigger from Event received or Contact updated, then filter on the current state before the email.
For a personalized weekly digest, schedule a job in your app and send one event per active contact. Put the digest data in event properties, then use those properties in the workflow email. If everyone gets the same content, use a campaign.
See marketing email in Loops for campaigns, and the event properties documentation for personalized workflow email.
How to build lifecycle email in Loops
Your app sends events and updates contact properties as customers use the product. Marketers can use that data to build Workflows with emails, timers, audience filters, branches, and experiments.
Start with Contact added, Contact updated, Contact added to list, or Event received.
Build the path on the canvas with Email, Timer, Audience Filter, Branch, and Experiment nodes.
Personalize email with contact and event properties. Add fallbacks for optional values.
Review workflow email metrics, then use product or billing events to measure activation and paid upgrades.
See the campaign and workflow options in product and lifecycle email in Loops.
Frequently asked questions
What is lifecycle email?
How can marketers build behavior-triggered email without waiting on engineering?
What triggers a lifecycle email?
Which lifecycle email should I build first?
How do I stop dunning emails after a Stripe payment succeeds?