Trial Conversion Email Sequences for SaaS

A trial conversion sequence is a short run of emails that starts when someone begins a free trial and changes course depending on what they do inside your product. Its job is narrow: get each trial user to the action that shows the product working for them, then make the paid step easy before the trial clock runs out. Below you get a 14-day sequence with a trigger, a skip rule and an exit condition for every email, the Stripe and Paddle events to wire in, a plan for failed cards, and the tools that can run it with their list prices at real list sizes.

If you also need the flow that starts after someone pays, read our guide to onboarding email sequences. For the billing side in more depth, see email tools with Stripe integration.

Define the activation event before you write a single email

Every message in the sequence points at one product action, so choose that action first. The honest way to pick it is to look at your own paying customers and ask what the accounts that stayed did in their first sessions that the abandoned trials did not. It is almost never a login. It is something that produces a result the user can see.

• Project tool: created a project and invited one teammate.
• Analytics product: connected a data source and opened the first report.
• Invoicing app: sent a real invoice, not a draft.
• Email product: sent a first message to a real list.
• API product: made a first successful call from a production key.

The event must be something your app can emit under a fixed name, such as project_created or first_invoice_sent, because the email tool will branch on it. Use a single event for the first version rather than a score. If almost nobody reaches the step inside the trial window, every user will look non-activated and your branches will be useless; if it happens at signup, it tells you nothing.

Later, compare trial-to-paid for activated and non-activated users, but read the gap as a hint about where to spend effort. People who were already keen both activate and buy, so the gap alone does not show that your emails caused anything. If you have the volume, hold out a group that receives no sequence and compare against it.

Match the sequence to the trial length

Anchor the closing messages to the end date rather than to day numbers. According to Stripe's trial documentation, the customer.subscription.trial_will_end event is sent according to a Dashboard setting that defaults to three days before the trial ends, and straight away if the trial is shorter than that interval. A 14-day trial therefore gets its reminder trigger on day 11 without a timer of your own. The same page says Stripe-hosted reminder emails go out seven days before the end, so decide whether Stripe or you sends the reminder, and avoid sending both.

A 14-day trial sequence, email by email

There are eight messages here, but nobody receives all of them. Skip rules remove emails that no longer apply, and an exit removes the contact from the whole sequence. Subject lines are starting points to adapt to your voice, not tested winners.

Email 1, day 0: your workspace is ready

• Trigger: the trial started, meaning your own trial_started event or a Stripe subscription created in trialing status. Send immediately.
• Content: one button that opens the first task inside the app, not a feature tour.
• Skip when: never. Exit when: the account pays.
• Subject ideas: "Your workspace is ready: start with [first task]"; "[Product]: the one thing to set up first".

Email 2, day 1: the one task

• Trigger: day 1 after trial start.
• Content: the shortest path to the activation event, with a deep link to the right screen and a short clip or screenshot if you have one.
• Skip when: the activation event has already fired. Exit when: the account pays.
• Subject ideas: "Still to do: [first action]"; "Stuck on [step]? Reply and tell us".

Email 3a, day 3: a plain note from a named person (not activated)

• Trigger: day 3 and the activation event is absent.
• Content: plain text, a few lines, asking what got in the way and offering a call or the right doc. Replies must land in a real inbox.
• Exit when: the person replies (move them into a human conversation and stop automated sends), activates, or pays.
• Subject ideas: "Need a hand with [setup step]?"; "A quick question about your trial".

Email 3b, day 3: the next step (activated)

• Trigger: day 3, or the moment of activation if that comes later, with the event present.
• Content: one capability that builds on what they just did, and a teammate invite if the product is multi-user.
• Exit when: the account pays.
• Subject ideas: "You've [done X]. Here's what to try next"; "After [first result]: [second feature]".

Email 4, day 6: a use case that matches them

• Trigger: day 6, for everyone who has not paid.
• Content: a worked example for the role or use case they named at signup. Use a customer story only if a real customer approved it; otherwise walk through how your own team uses the feature.
• Subject ideas: "How [role] teams use [feature]"; "A [role] workflow you can copy today".

Email 5, day 9: pricing and what happens next

• Trigger: day 9, or sooner when the user opens the pricing page.
• Content: which plan fits what the account has actually done, what each limit means, what happens to their data and access when the trial ends, and how invoices and tax details work.
• Subject ideas: "What happens when your trial ends"; "Which plan fits how you use [Product]".

Email 6, day 11: the trial is ending

• Trigger: Stripe's customer.subscription.trial_will_end. Paddle's event list has no equivalent reminder event, so schedule this one from the trial end date.
• Content: a recap of what the account did, drawn from your own data, the end date, and the exact price and date of the first charge if a card is on file.
• Skip when: the account has paid. Branch: card on file gets "you will be charged on [date]"; no card gets "add a payment method to keep your work".
• Subject ideas: "Your trial ends on [date]"; "[First name], here's what you've built so far".

Email 7, day 13: last day before the end

• Trigger: one day before the end date.
• Content: the choices, stated plainly: pick a plan, ask for more time (offer this only to users who activated but ran short), or step down to a free plan if you have one.
• Subject ideas: "Tomorrow: your [Product] trial ends"; "Need more time? Reply to this email".

Email 8, the day after the end: the trial has ended

• Trigger: the trial ended without a paid subscription: customer.subscription.deleted or customer.subscription.paused in Stripe when you set an end behavior, or your own check.
• Content: what happened to their access, how long their data is kept (state it only if you have decided), one link to reactivate, and one question: what stopped them?
• Exit: the sequence ends here. Before moving these contacts into a newsletter, check whether the consent they gave at signup covers marketing mail.
• Subject ideas: "Your trial has ended"; "One question about your trial".

Behavioral branches worth building first

The calendar gives the sequence its skeleton; these signals decide which messages a given person actually receives. Build them in roughly this order, since the first two do most of the work.

Wire the sequence to Stripe or Paddle events

Two kinds of signal feed this sequence: product events from your own app (activation, invites, pricing-page visits) and billing events from your payment provider. Your backend receives the billing webhooks and passes them to the email tool as events or contact attributes, keyed to the same user ID your app uses. Store that ID on the Stripe customer, or the Stripe customer ID on your user record, so the two never need guessing.

Two cautions come straight from Stripe's webhook documentation. Stripe does not guarantee that events arrive in the order they were generated, so read the subscription's current status instead of inferring state from event order. And an endpoint can receive the same event more than once, so log the event IDs you have processed and ignore repeats.

Stripe events that matter for a trial

Event names and behavior above are from Stripe's subscription webhooks guide and trials guide, read on 7 October 2026.

If you bill through Paddle

Paddle Billing exposes the same moments under different names. subscription.trialing marks a subscription that is in trial, which makes it your entry trigger. subscription.activated occurs when the status changes to active, which Paddle's documentation describes as meaning any trial period has elapsed and the customer has been billed successfully, so use it as the exit. subscription.past_due covers a failed automatic payment, and subscription.canceled covers the end. Paddle's event list has no reminder event comparable to Stripe's trial-will-end, so compute email 6 from the trial end date in the subscription payload.

Handle failed cards in and after the trial

A failed payment is the least glamorous part of trial conversion and often the most avoidable loss: the person decided to buy, and a declined card stopped them. How you handle it depends on whether the trial collected a card.

Trials with a card on file

The first real charge happens when the trial ends, and that is when an expired card, a spending limit or a bank authentication request can interrupt it. Stripe's guidance in its subscription webhooks guide for invoice.payment_failed is to notify the customer, collect new payment information or update the subscription's default payment method, and consider turning on Smart Retries. It also says that when a subscription moves to past_due you should tell the customer directly and ask them to update their payment details. Use that as the skeleton of three short emails:

• Immediately after the failure: a factual billing message with one button to a page where they can update the card, and a clear line about whether they still have access.
• A couple of days later, if still unpaid: the same message, shorter, with the amount and date restated. Time it to your retry schedule so it does not arrive just before an automatic retry succeeds.
• Before access stops: a final notice naming the date, sent only if the invoice is still unpaid.

Keep these out of the promotional tone of the trial emails and out of marketing unsubscribes: they are messages about an account the person asked for. Exit them on invoice.paid. When an invoice needs authentication, invoice.payment_action_required is a different case from a plain decline: the customer has to complete a step with their bank, so the email should link directly to that step. In Paddle, subscription.past_due plays the same role.

Trials with no card

Here nothing is charged at the end, so the question is what state the subscription lands in. Stripe's trials documentation describes a missing_payment_method end behavior with three options: create an invoice (the default; if it cannot be paid the subscription goes past_due), cancel the subscription, or pause it until you resume it. Cancel and pause send customer.subscription.deleted and customer.subscription.paused respectively, and those are the natural triggers for email 8. Whichever you choose, say the same thing in the emails that your product does: if access pauses, the email must not claim it continues.

Copy and offer decisions for the closing emails

Sequence emails get most of their value from restraint. Start helpful and let urgency arrive only when there is a real date to point at; "your trial ends in 14 days" on day 0 is not urgent, and it reads like a countdown. Frame the paid step as keeping what the user already built (their projects, their team setup, their imported data) rather than as a list of extra features they have not touched.

Offer more than one way forward in the closing emails: a plan, an extension for people who were close, or a free plan if you have one. And keep a human in the loop. A reply to the day-3 note from a real person, a short call offered to accounts that invited teammates, and an actual inbox behind every sender address will do more for a hesitant buyer than another automated message.

Measure the sequence against your own baseline

Open rate is a weak measure of this sequence, because some mail clients load images automatically and register opens nobody made. Track four things instead, all from your own data: the share of trial users who reach the activation event, the time it takes them, trial-to-paid conversion for everyone who started a trial, and conversion split by signup source or plan. Report conversion against the same denominator every month (all trial starts, or only eligible ones, never switching between them), and change one thing at a time, such as a subject line, the day of email 5, or the offer in email 7, so a movement can be traced to a change.

Mistakes that quietly hurt trial sequences

• Sending the calendar to everyone. A user who activated on day 1 does not need a day-2 setup email, and one who never logged in needs a human note more than a power tip.
• Entering at signup instead of trial start. If the subscription is created later than the account, the sequence clock runs against the wrong date and the end-of-trial messages miss their target.
• Checking the exit only at entry. Re-test "has this person paid?" immediately before each send; otherwise a customer gets a trial reminder after being charged.
• Mixing billing notices into promotional mail. A failed-payment email sent through a marketing stream, with a promotional footer and an unsubscribe that stops the notice, causes confusion and lost revenue.
• Discounting everyone on the last day. It teaches future trial users to wait; keep offers for people whose objection you know.
• Letting every signup count as a billable contact. Tools that bill by contact count never-activated trial signups too, so decide how long you keep them once the sequence ends. Customer.io's billing documentation says a profile that exists at any point in the billing period counts toward that month's bill even if you delete it.
• Skipping the plain-text help note. It is the cheapest email in the sequence and the one most likely to surface a real blocker such as a missing integration.

Tools that can run a trial sequence, with list prices

Whatever you pick has to do three things: accept custom events through an API, branch on whether an event happened, and exit a contact when another system reports a payment. Prices below come from each vendor's pricing page as read on 7 October 2026; they use different billing units (profiles, users, subscribers, contacts, active people), so they are not directly comparable until you count your own list that way.

Customer.io

Customer.io is the one to look at when product events drive most of your logic. Its Essentials plan includes a visual workflow builder, and its pricing page lists it at $100 per month billed monthly for 5,000 profiles and $145 per month at 10,000 profiles; its billing documentation puts extra profiles at $0.009 each. Choose it if you already have an event stream and expect several branches. The cost to watch is that never-activated signups are profiles too. See the Customer.io alternatives page if the price or setup effort is the sticking point.

Userlist

Userlist is built for SaaS products and segments both users and companies, which suits a trial where a whole team evaluates together. Its pricing page shows Basic at $149 per month for up to 10,000 users, with each extra 1,000 users at $10 per month, and Professional at $349 per month at that size, adding A/B split testing and conversion goals. Conversion goals map neatly onto the exit condition in this sequence. Compare it directly in Userlist vs Customer.io.

Loops

Loops suits a small SaaS that wants event-triggered emails without much setup. Per its pricing page, it is free up to 1,000 contacts (up to 4,000 sends in any rolling 30 days), and paid plans scale by subscribers: $99 per month at about 10,000 and $249 per month at about 50,000, per its dated slider readout. That makes it the cheapest route on this page for a first trial sequence. Check how it handles your billing events before relying on it for complex branching; Customer.io vs Loops covers the trade-off.

ActiveCampaign

ActiveCampaign is the pick when trials get sales follow-up, because the CRM sits in the same account. The detail that matters here: its Starter plan limits each automation to five actions, so an eight-email branching sequence belongs on Plus. Its pricing page lists Starter from $15 per month and Plus from $49 per month at 1,000 contacts, both billed annually; at 5,000 contacts Plus reads $145 per month and at 10,000 contacts $189. See ActiveCampaign alternatives for the other side of that decision.

HubSpot

HubSpot makes sense when your CRM and sales team already live there and trial users should become deals. Its Marketing Hub pricing page prices per seat: Starter from $7 per month, Professional from $800 per month and Enterprise from $3,600 per month. The same page's email-automation row lists one automated action on the free tools, up to ten on Starter and unlimited on Professional, so a branching trial sequence is a Professional-tier purchase. For the head-to-head, see HubSpot vs ActiveCampaign.

Drip

Drip charges by active people: its pricing page shows $39 per month for up to 2,500 people, $89 at 5,000 and $154 at 10,000, with a 14-day free trial and no card needed. It is designed around online stores, so check how you would send app events to it before choosing it for a SaaS trial. It is the sensible option if the same company also sells products and wants one tool for both flows; see Loops vs Drip.

At a glance: 10,000 contacts

For a small team starting from nothing, Loops or Customer.io Essentials covers the whole sequence above. Add ActiveCampaign Plus or HubSpot when a sales rep needs to see the same trial data, and look at Userlist when the buyer is a team rather than a person. More on the wider decision is in email tools for free-trial products and churn prevention.

Frequently asked questions

How long should a free trial be?

Long enough for your slowest typical customer to reach the activation event, plus a few days to decide. Check how many days your paying accounts took to hit that event: if most did it inside the first week, fourteen days leaves a full second week for pricing questions and a longer trial mostly adds delay. Products that need a data import or a team rollout can justify thirty days, and the sequence then leans on activation-triggered messages instead of a fixed calendar. There is no universal best length, so test lengths against one fixed activation definition.

Should the trial ask for a credit card up front?

It changes what the emails say more than it changes the mechanics. With a card on file the subscription renews by itself, so the closing emails become "here is what you will be charged on this date and how to cancel", and you need a plan for a failed first charge. Without a card, the sequence has to ask for payment details, and in Stripe you decide what happens when the trial ends with no payment method: create an invoice, cancel, or pause. Pick based on who signs up and how much sales help they get, and test it on your own traffic rather than trusting a generic claim.

What should happen to the sequence when someone pays before the trial ends?

They should leave it at once and enter your new-customer onboarding flow. Drive the exit from the billing event, such as invoice.paid in Stripe or subscription.activated in Paddle, and re-check it before every send rather than only when the contact enters, because someone can pay between two emails. A trial reminder arriving after the card was charged is the quickest way to make a new customer doubt your system.

Should the last email offer a discount?

Only when you already know price is the objection, for example because replies or an exit question say so. A blanket discount on day 13 teaches every trial user to wait for it, and it lands mostly on people who never activated, whose problem is fit rather than price. A safer version is an extension or an annual-plan option offered to users who did activate but ran out of time.

Do I need a lifecycle tool, or will a newsletter tool do?

It depends on whether the tool can branch on product events. A tool that only manages lists and tags can run the date-based emails, but it cannot say "send this only if the activation event has not fired" or "stop when Stripe reports a paid invoice". Before choosing, confirm that it accepts custom events through an API, can branch on whether an event happened, and can remove a contact when an outside system sends an event.