The “Almost There” Rescue: Extending Trials For Users Who Just Need A Little More Time

Three days before her trial ends, Emma is in your app every morning.

She’s connected her Shopify store, set up two automations, invited a teammate, and opened every onboarding email you’ve sent. Your dashboard calls this “highly engaged.” Your billing system calls it “still $0 MRR.”

Then the “Your trial ends soon” email hits. She has a packed day, misses it, and by Monday she’s locked out. No card on file. No upgrade. Just another quiet churn in your analytics.

You didn’t lose a bad fit. You lost someone who was already behaving like a customer.

That’s the gap this pattern closes.

The sequence at the top of this page is the whole journey, end to end. It’s built for e‑commerce apps and Shopify integrations that run free trials: detect engaged-but-not-converted users near the end of their trial, automatically extend access, and turn “almost” into revenue.

We’ll walk through that journey node by node, using a fictional but typical Shopify app as a concrete example, then show you how to adapt it to your own stack.

Meet UpsellLane, a Shopify app with a leaky “almost”

UpsellLane is a 5‑person team with a $90k MRR upsell and cross‑sell app on the Shopify App Store. They charge $49–$149/month, run a 14‑day free trial, and send emails with a mishmash of the Shopify native onboarding plus a Mailchimp welcome series.

Their numbers look familiar:

• Trial‑to‑paid: 17%

• Churn in first 60 days: 8–10%

• Big drop‑off between “installed and clicked around” vs “actually upgraded”

When they dig into product analytics, they notice something crucial: trial users who create at least one live upsell funnel and get 20+ impressions are 3–4x more likely to convert.

But a non‑trivial set hit that activation milestone and still don’t upgrade before time runs out. Life gets in the way. They’re not saying “no”; they just haven’t said “yes” yet.

UpsellLane’s goal: catch those users automatically, offer an extension while they’re still warm, and then nurture them to a decision.

That’s exactly what the journey you see in the sequence at the top of this page does.

Let’s break it down.

Why this is a Criteria Match journey, not just “day 10 of trial”

The start of the flow is a Criteria Match trigger.

UpsellLane defines a clear “engaged but not converted and almost out of time” profile using the segment builder:

• Custom attribute trial_ends_at is within the next 3 days

• Custom event upsell_funnel_published triggered at least 1 time

• Custom event upsell_impression triggered at least 20 times in the last 7 days

• Email subscription status is Subscribed

• Marketing status is Marketing

• No custom event subscription_upgraded over all time

In the journey builder, the Criteria Match trigger embeds that same logic inline. Whenever a contact first meets all of those conditions, they enter the journey at that node.

Why use Criteria Match instead of a simple “Contact Added Date is 11 days ago” rule?

Because this pattern is about intent, not just time:

• You want people who have touched core features, not window‑shoppers.

• You want people who are close to trial end, not folks who activated hard on day 2 and already converted on day 5.

• You want to exclude anyone who has already upgraded or explicitly opted out.

Criteria Match gives you the precision of the segment builder without having to maintain a separate saved segment.

If you later realise “20 impressions” is too strict, you adjust that condition in one place and the entire rescue engine updates.

First move: tag and orient internally before you email

Right after the trigger, the sequence applies an Add Tag action.

Tag names are up to you, but something like trial_extension_candidate works well. This serves three purposes:

1. It’s a quick visual filter when you’re looking at a contact’s profile.

2. You can reuse the tag across other sequences or audiences.

3. It’s a safety net if you want to pause or A/B test this journey later. You can easily build a segment “has tag trial_extension_candidate but has not received extension email” for follow‑up analysis.

In the flow you see, the next step is a Send Internal Email node. UpsellLane uses this to notify their #customer‑success Slack channel via a forwarding address:

Subject: “High‑intent trial needs more time: {{contact.email}}”

Body: brief context (plan, store URL, key usage events), pulled from contact attributes and custom‑event counts.

Why bother if the whole point is automation?

Because this is where small teams win on leverage, not headcount. The automation does the heavy lifting 24/7, and the internal email flags the 5–10% of contacts who might deserve a manual loom video or a personal reply if they engage with the extension offer.

You don’t need a “success team” for this. Even a founder‑led shop can reply to a couple of those emails per week and make a measurable dent in MRR.

The extension email: specific, time‑bound, and conditional

Next comes the hero step: Send Email with the extension offer.

In Spreeflo, UpsellLane builds this using the email builder, then ties it to the node. They keep “Send only once” on, so a user can’t receive multiple extension offers from overlapping logic.

The email itself has three key ingredients:

1. Personalisation that reflects real behaviour “You’ve already launched 2 upsell funnels that drove 37 impressions in the last week. Nice work.” Those numbers come straight from custom events and attributes. This reinforces: we’re paying attention, you’re not just a row in a CSV.

2. A clear, specific benefit “We’ve added 14 extra days to your trial so you can finish testing during your next promo. Your updated end date is August 29.”

3. A soft but direct path to upgrade “If you’re ready to keep your funnels live without interruption, you can upgrade in one click here.”

Notice what’s missing: there’s no “click here to request an extension.” The whole point of this pattern is to act on their behalf. The extension is already applied. The email is confirmation and context.

Under the hood, how you “extend the trial” is outside Spreeflo itself. Most Shopify and e‑commerce SaaS apps implement that in their billing or app‑backend logic:

• When the Criteria Match trigger fires, the user enters this journey.

• Downstream, a Webhook node calls an internal API endpoint like /api/trials/extend, passing contact identifiers.

• Your backend validates the user, pushes trial_ends_at out by N days, and updates the contact attribute via the Spreeflo API or SDK.

We’ll come back to that node in a second. First, we use a short pause.

Time Delay vs Wait Condition: why we do both

Right after the extension email, the sequence uses a Time Delay of 24 hours.

Why a fixed delay instead of immediately checking behaviour?

Because you’re optimising two different things:

• Immediate confirms: Did they see and accept the extension?

• Deeper behaviour: Did they take actions that make post‑extension conversion more likely?

The first is email‑channel behaviour. The second is app usage.

A 24‑hour Time Delay gives people a fair chance to open the email, click back to the app, or hit reply before you branch on what happened.

After that delay, the sequence hits a Check Email Activity process node keyed to the extension email. UpsellLane sets three branches:

• Branch A: opened

• Branch B: clicked (upgrade or CTA link)

• Branch C (else): unopened / everything else

This lets them tailor follow‑ups:

• Clicked: they’ve shown clear intent. Tag as trial_extension_clicked and send a more direct “Finish upgrading” email after another Time Delay.

• Opened but didn’t click: they saw the offer but didn’t act. Maybe they’re unsure of value. They route these contacts into a mini case‑study email or offer a 10‑minute setup call.

• Unopened: email might not be the right channel right now, or the subject didn’t land. If you’re on the Professional plan, you could add a Send Web Push node here to deliver an on‑device reminder during the extended trial window.

This is where you stop treating “all trial users” as one blob. You’re responding to actual engagement: capture detail on every customer so you can speak to each uniquely.

Extending the trial in your system: Webhook as the bridge

Now, back to the mechanics of the extension itself.

Somewhere between the first Send Email and the follow‑up logic, the journey calls out to your app with a Webhook action. In UpsellLane’s case:

• Method: POST

• URL: a private endpoint on their backend visible only to Spreeflo

• Payload: all contact attributes, or a subset (like shopify_store_domain, user_id, and trial_ends_at)

Their backend:

1. Locates the right account based on those identifiers.

2. Checks eligibility (e.g., “hasn’t been extended before”).

3. Extends trial_ends_at by 14 days.

4. Writes that updated date back into Spreeflo using the Spreeflo API or via Spreeflo.identify in the app.

Why keep that outside the email tool?

Because billing and entitlement logic belongs in your product stack. Spreeflo is the orchestration layer: it detects the pattern of behaviour, decides who qualifies, and triggers the change. Your backend owns the source of truth.

If you don’t want to hit the API directly, an alternative is to use the Webhook to fire a Zapier or n8n workflow that talks to your billing provider. The pattern is the same.

Using Wait Condition to measure “did the extension actually work?”

Once the extension is granted, the journey uses a Wait Condition node.

Condition: custom event subscription_upgraded triggered at least 1 time in the next X days (often the length of the extension). Timeout: that same number of days.

This step answers the key lifecycle question: given the extra time, did they convert?

Two branches flow out of that Wait Condition:

• Condition met before timeout: they upgraded during the extension.

• Timeout hit with condition unmet: they completed the extension window without upgrading.

For the first branch, the next node is usually:

• Add Tag: trial_saved_by_extension

• Optional Send Internal Email: “Extension‑saved upgrade from {{contact.email}}” so you can attribute revenue later.

• An onboarding or “new customer success” journey triggered by that upgrade, which you may already have modeled elsewhere using a Custom Event or Added Tag trigger.

For the second branch (no upgrade after extension), you have options:

• Move them into a structured win‑back series.

• Ask explicitly why they didn’t continue (short survey, 1–2 questions).

• Suppress them from further extension offers with a trial_extension_completed tag.

The important thing is that the Wait Condition draws a clean line in your funnel:

“Extensions offered” → “Extensions accepted” → “Upgrades after extension.”

Those are the exact metrics this pattern is built around: extension acceptance rate, post‑extension conversion, and save rate.

Where segmentation and tags earn your MRR, not clutter it

By the time a contact exits this journey, they’ve accumulated useful labels:

• trial_extension_candidate

• trial_extension_clicked or similar engagement tags

• trial_saved_by_extension (if they upgrade in time)

• Maybe a “didn’t upgrade after extension” tag if they don’t

This isn’t vanity tagging. These become building blocks for:

• A “high‑intent but price‑sensitive” segment (opened extension email, clicked, didn’t upgrade).

• Future experiments on how long or how often to extend.

• Distinct onboarding for customers who needed extra reassurance vs those who upgraded quickly.

Spreeflo’s audiences and segments are designed for this sort of lifecycle view: the same contact moves between segments as their behaviour changes, and each transition can trigger a different journey.

Most apps never do this. They spam a weekly “what’s new” email to every trial and customer alike. That’s where lifetime value quietly leaks away.

How to adapt this pattern to your own Shopify or e‑commerce app

The exact criteria and timing will vary, but the skeleton stays the same.

Here’s how to think about each decision point:

1. Define “engaged but not converted” in real product terms For a cart‑recovery app like CartWizard, that might be: cart_recovery_flow_published at least once, recovery_email_sent at least 10 times, and no subscription_upgraded event. For an analytics tool like ShopMetrics: dashboard_viewed on at least 3 distinct days, report_exported at least once, and no billing info on file.

2. Set your “near trial end” window 3 days works well for 14‑day trials. For 30‑day trials, 5–7 days might be better. Use a Contact Attribute on trial_ends_at so you can express “is within X days” clearly instead of hacking around dates.

3. Choose a reasonable extension length Long enough to cover a real usage cycle (e.g., another weekly promotion), short enough to feel like a favour, not an indefinite free ride. 7–14 extra days is typical.

4. Use Random Split if you want hard evidence Drop a Random Split node early in the flow to divert, say, 20% of eligible users into a “no extension” control branch. Keep everything else identical. Then compare conversion rates between paths.

5. Keep the emails tight and behaviour‑based Use the AI personalisation tools to reference specific features they’ve used, recent events, or store type. “You’ve recovered 3 carts worth $287 so far” lands harder than “Looks like you’re trying our app.”

6. Start simple, then iterate V1 of this flow can be: Criteria Match → Add Tag → Webhook (extend) → Send Email → Wait Condition (upgrade) → Tag. You can always add Check Email Activity, Random Split, or Web Push later as you see what works.

If you’re new to the visual editor, the campaign and journey automation overview walks through how triggers, processes, and actions link together as you build a journey.

Why this pattern earns its keep on your roadmap

Extending a trial is not about being “nice.”

It’s about recognising that your best users are still people with crowded calendars, and that a blunt 14‑day timer is often the only thing standing between “activated trial” and “paying customer.”

This journey shifts that timer from a fixed wall to a smart filter:

• It only fires for users who’ve actually engaged.

• It speaks to them with evidence from their own usage.

• It gives them breathing room while keeping the next step (upgrade) visible.

• It feeds you clean data on when and for whom extensions actually save revenue.

Most e‑commerce apps already track all the signals needed to run this. They just leave them sitting in product analytics instead of wiring them into their marketing stack.

When you connect those dots once in Spreeflo, the system runs quietly in the background. Every week, a handful of “almost” users get the nudge they needed. Some reply with questions. Some click and upgrade immediately. Some simply stick around long enough for your product to finish the job it already started.

That’s how founder‑led teams win on leverage: one well‑designed journey that plugs a very specific leak, then runs on its own.

If you recognise Emma in your own trial stats, this is the pattern to build next.