Your best email is a receipt, and your trial window is silent

Welcome emails get opened at roughly 84%, against roughly 40% for everything else you send. That gap is the highest-attention moment your lifecycle system will ever get, and most products spend it on "thanks for signing up" with a login link. The second problem is bigger: the trial window usually carries no messaging at all, even though the decision gets made on the last day or two, when the charge stops being hypothetical. If you build one thing this quarter, build the trial-ends-today send.

Users who receive no push at all in their first 90 days churn at 95% (Airship). Most of that is decided in the first 24 to 48 hours, which is why day zero should get more email and push than feels comfortable, and why everything after it branches by what the person actually did.

The five things I find most often

1. Everything is a scheduled broadcast when it should be behavior-triggered

The largest untouched lever in most programs, and it needs no new creative at all. Only a trigger.

Behavior-triggered push outperforms standard sends by 4 to 9x on CTR (OneSignal 2026). Contextual push opens at 14.4% against 4.19% for generic (Batch 2025). On email, automated flows click at 5.58% against 1.69% for campaigns, and flows are 5.3% of sends producing 41% of email revenue (Klaviyo 2026).

2. Whole stages of the funnel get no communication at all

Not a quality problem. A coverage problem, and the audit's eight-component framework exists to find the empty rows.

In one program we audited, the signup drop-off series did not exist at all, which is the most direct lever there is on signup rate.

3. Everyone gets the same message

Segment on two axes: who the person is, and what they have actually done.

There is no single clean figure for the general case here, and I would rather say that than borrow an adjacent one. The nearest real number: segmenting trial users by engagement level, so that active trialists get benefit reinforcement while passive ones get re-education, produced 20% less churn over 30 days and a 6% higher upgrade rate in a Braze case study.

4. One channel is doing all the work

Each additional channel produces 4.3x more purchases per user, and a cross-channel program shows 73% more purchases, 4.2x LTV and 58% better retention against a single-channel one. Braze 2026 Consumer Engagement Review, aggregate cross-industry, so read it as a direction rather than a promise for your category.

5. Performance is judged against the wrong bar, and mostly not judged at all

Welcome emails run roughly 4x the open rate and 10x the CTR of the emails that follow them inside the same program. So a welcome email at a 30% open rate is not doing fine. It is at about a third of its own benchmark.

One program I looked at had emails that had never been tested against anything, and nothing measuring what any of them did.

The metric most of this used to be judged on stopped working this year

Before the numbers below, the caveat that now travels with all of them.

After Gmail's January 2026 Gemini overhaul, open rates rose to about 45.6%, inflated by AI auto-opens generating summaries, while CTR fell from 4.35% to 3.93%, because people read the summary instead of clicking. The first 100 to 200 characters are now inbox-critical, and front-loaded value propositions hold 23% higher CTR than buried CTAs (Folderly and Omeda, Q4 2025). The same shift is happening on push, where iOS Notification Summaries can rewrite your copy before anyone sees it.

Track clicks, not opens. Which means the open-rate comparison below is still the right way to find your highest-attention moment, and the wrong way to grade what you do with it.

The highest-attention moment you will ever get

Welcome emails get opened at roughly 84%. Everything else you send lands closer to 40%. GetResponse has it at 83.63% against 39.64% across all campaigns.

That gap is enormous, and most products spend it on a receipt.

The moment someone signs up is the single highest-attention moment your lifecycle system will ever have. They just decided to try the thing. They are, briefly, actively curious about it, and they will open essentially anything you send.

And what arrives is "thanks for signing up," with a link to log in.

You get that moment once and it decays fast. A receipt is a reasonable thing to send. It is just an expensive thing to send in the one slot where you had the reader's full attention and could have sent anything.

What belongs there instead is the fastest possible path to the thing they signed up for. One action, named specifically, with the reason it matters. Not a tour of the feature set, and not a welcome letter from the founder, both of which are about you at a moment that is briefly about them.

The trial window carries no messaging at all

This is the one I see constantly, and it costs more than the welcome email does.

A seven-day trial is a seven-day decision. That decision gets made on day six or seven, when the charge stops being hypothetical and turns into a thing that is about to happen. Plenty of products have nothing scheduled for that day. Not a weak email. Nothing at all.

If you build one thing this quarter, build that one. A single "your trial ends today" send, on a timer, no series required. It is closer to your conversion metric than anything else you could ship this year, and it is roughly an afternoon of work.

The content is not complicated. What they will lose access to, when the charge lands, and how to keep going. The people who were going to cancel still cancel, and they cancel without feeling ambushed, which is worth something too.

QA the event before you build on it

One thing I would hold you to, before any of this gets built.

Every send branches on an event. Signed up, activated, completed the first session, started a trial. If the event is wrong, everything downstream of it is wrong in ways that are hard to see, because a lifecycle system does not throw errors. It just quietly sends the wrong thing to the wrong people, or nothing to anyone.

I have watched a lifecycle build get designed around an activation event that was broken in production. It broke five touchpoints and the definition of every segment that used it, and none of that surfaced as a failure. The sends went out. They went to the wrong population.

Checking the events is an afternoon of work and it is the cheapest insurance in this whole exercise. Fire each one manually, watch it land, confirm the properties are populated, and confirm the timestamp is what you think it is.

You do not need an ESP with history

The common objection is that there is not enough data yet to do lifecycle properly.

If you have sent nothing so far, that is a structural build rather than a blocker. You are not optimizing an existing program, you are installing the sends that any program would need: the welcome, the trial-end, the win-back. None of those require historical open rates to design, because their timing is determined by the user's lifecycle rather than by what your list has responded to before.

Optimization comes later and it needs history. Existence does not.

What a lifecycle audit actually hands you

One pack, not a set of files, and this is the shape of it rather than a pitch.

The body: a two-to-three sentence read carrying the evidence-basis clause, which is what data the read is actually built on, "do these now" grouped by surface, and the numbers that matter.

The appendix carries the evidence basis in full, the eight-component framework audit (welcome, onboarding and activation, trial conversion, engagement nudges, streak and habit, winback and re-engagement, upgrade and expansion, retention risk) with each marked observation, quick win or longer-term, plus the segmentation flag and the top three gaps. Then the series architecture: the catalog, the 14-day welcome and trial-conversion series with behavioral variants, the segmentation model, and the push-permission tradeoff. Then production-ready email copy, push and short-form copy, a benchmark table with provenance, and the methodology.

Degraded input is visible, not hidden. No ESP data downgrades the current-state audit to a structural audit, and the document says so in your language rather than ours. No existing templates means the template review is a visible "skipped" with its reason next to it. Every branch uses only events your intake lists as actually firing, because a branch on an event that does not fire is worse than no branch.

The takeaway

The first 24 to 48 hours decide whether someone stays, so day zero gets more email and push than feels necessary, and everything after that branches by engagement level.

Then two changes, both small.

Take the welcome slot and put the fastest path to value in it instead of a login link, because that is the only send you can count on people opening. Then schedule one message for the day the trial ends, which is the day the decision actually gets made.

Before you ship either, fire the events by hand and confirm they do what the documentation says.

Common questions

What should a welcome email actually say?

The fastest path to the thing the user signed up for, named as one specific action, with the reason it matters. Welcome emails are opened at roughly 84% against roughly 40% for everything else, so this is the one send you can count on being read, and spending it on a login link or a feature tour trades your highest-attention moment for information the user did not need at that moment.

When should you email during a free trial?

At minimum, on the final day. A seven-day trial is a seven-day decision and that decision gets made when the charge stops being hypothetical, which is day six or seven. A single scheduled "your trial ends today" message covering what they lose, when the charge lands, and how to continue is the highest-return lifecycle send most products can build, and it does not require a series around it.

Can you build a lifecycle program with no email history?

Yes. Without history you cannot optimize, but you can install the sends the program structurally needs: the welcome, the trial-end message, and the win-back. Their timing comes from the user's lifecycle rather than from past engagement data. Verify the underlying events fire correctly before building on them, since every branch in the system depends on them and a broken event fails silently.