The Onboarding Checklist That Quietly Prints MRR for Your Shopify App

Picture this.

A merchant installs your Shopify app at 10:14 a.m.

By 10:16, they’ve clicked around your UI, found the “Getting started” checklist, and… stopped after step one.

They meant to finish. Then a Slack ping, a supplier fire, a customer refund, and your app gets buried under six other tabs. Three days later, the Shopify “uninstall” email lands in your inbox.

You lost them after 6 minutes of “trying it later”.

For most e‑commerce apps, this is the real churn story. It doesn’t happen in billing. It happens in onboarding, long before the first charge hits Stripe.

The sequence at the top of this page is built to stop that.

It’s an onboarding journey where every checklist step is backed by an email nudge: each time a user completes one item, they get a short, specific email that celebrates that step and gently points to the next. It keeps progress visible, it pulls users back when they get distracted, and it quietly pulls your activation and MRR numbers up.

To make it concrete, let’s anchor on a fictional but typical app.

Meet FulfillFox, a Shopify app that automates order batching and shipping labels. They’re doing $65k MRR, built on a small remote team. Stack-wise, they’re using Stripe for billing, a homegrown onboarding checklist inside the app, Shopify’s APIs for install/uninstall, and a generic email tool they’ve outgrown.

They move this flow into Spreeflo so they can build a journey around it, connect directly to their app events, and speak differently to each merchant depending on how far through the checklist they’ve gone.

Let’s walk through the journey node by node, and why each decision matters.

Why a checklist-based journey matters for Shopify apps

Before the nodes, the strategy.

Most Shopify apps live or die on one metric: how many installs hit “first value” before the 7, 14, or 30‑day trial ends.

For FulfillFox, that “aha” looks like:

1. Install the app

2. Connect the Shopify store and carriers

3. Configure at least one shipping rule

4. Process a batch of orders through the app

5. Turn on auto-batching for the week

Their internal data says:

• Users who complete all 5 steps in the first 3 days churn at 2–3% monthly.

• Users who stop after step 2 churn at 20%+ and rarely convert from trial.

So the goal of this journey is not “send a welcome series”. It’s “increase checklist completion rate and pull more people into the 5‑step‑completer group”.

That’s why the pattern is built on behavioural triggers, not dates. Every email is tied to feature_used or step_completed events sent from their app via the Spreeflo API. Every action is tailored to where that merchant is in the journey.

Spreeflo’s first brand belief shows up hard here: capture detail on every customer so you can speak to each uniquely. If you only know “installed app on Tuesday”, you can’t do this. If you know “installed + configured rules but never processed a batch”, your copy writes itself.

Entry point: a single Custom Event trigger

On the canvas, this journey starts with one trigger: a Custom Event for app_installed.

You could theoretically trigger each arm from a different event, but that runs straight into the multi-trigger trap. Spreeflo’s re-enrollment model is journey‑scoped: if you had multiple triggers all set with re‑enrollment off, only the first one that ever fires per contact lifetime would do anything.

So FulfillFox keeps it simple:

• Trigger: Custom Event

• Event name: app_installed

• Re-enrollment: false

Why false? Because once a merchant has fully run through this onboarding journey once, you generally don’t want them going through the same step-by-step emails again if they reinstall six months later. That’s a different journey.

From here, every email about step 2, 3, 4 and 5 is driven by internal logic, not new triggers. It’s cleaner, and it matches how Spreeflo expects journeys to work.

First touch: Send Email → Add Tag

Immediately after app_installed, FulfillFox sends a welcome email:

• Node: Send Email

• Template: “Welcome to FulfillFox – let’s ship your first batch”

• Send only once: on

“Send only once” matters if you ever adapt this journey later with re‑entry. You do not want a merchant receiving multiple identical welcomes because they hit the trigger twice via staging or multiple test installs.

The copy is short and task‑oriented:

• 10–20 word welcome line

• Screenshot of the checklist in‑app

• CTA: “Complete Step 1: Connect your carrier accounts”

Right after that Send Email node, an Add Tag node stamps the contact with onboarding_started.

That tag isn’t required to make this journey work. It is incredibly handy for:

• Reporting: build a segment later in the segment builder for “onboarding_started but not activated”.

• Internal alerts: other journeys can watch for this tag and behave differently for brand-new users.

It also reflects the brand’s third belief: most apps leak lifetime value by not nurturing engagement. A simple onboarding_started tag is the first line of defence against that leak.

Guardrail: Wait Condition before we nag

After the welcome email, don’t immediately start nagging about step 1.

FulfillFox inserts a Wait Condition:

• Condition: Custom Event step_completed with property step_name = "connect_carriers" triggered at least 1 time in the last 1 day

• Timeout: 1 day

In practice, this means:

• If the merchant completes step 1 within 24 hours, the wait ends early.

• If they don’t, the timeout kicks in and we move on.

Why a Wait Condition instead of a straight 24‑hour Time Delay?

Because the Wait Condition lets the merchant’s behaviour short‑circuit the delay. If they smash through all five steps within 30 minutes, you don’t want them hanging in queues waiting for “reminder” emails that are already outdated.

Once the Wait Condition exits, we use an If/Else to branch:

• If condition: same as above (has completed step 1)

• Then branch: “they did it”

• Else branch: “they didn’t”

This keeps the logic explicit and readable when you or a teammate come back two months later.

If completed step 1: celebrate and push step 2

On the “then” branch, FulfillFox does three things:

1. Send Email: “Nice – carriers connected. Next up: shipping rules.”

2. Add Tag: step1_done

3. Time Delay: 1 day

The email is narrow. It assumes only one fact: they’ve connected carriers. It:

• Confirms value (“You can now pull in live rates from X, Y, Z”)

• Shows a quick win (“Here’s how other merchants shave 20 minutes/batch”)

• Points to Step 2 only (“Set your first shipping rule in 3 clicks”)

Because this email is triggered off behaviour, it feels timely and non-generic. It acknowledges exactly what the merchant has already done, and it doesn’t repeat onboarding they’ve finished.

The Add Tag step1_done is partly for analytics (you can later see how many got here) and partly for safety. If you ever need to enrol contacts into a separate follow‑up journey “for people who configured carriers but never processed a batch”, this tag is your enrollment hook.

The 1‑day Time Delay gives breathing room before we check again for step 2. Merchant calendars are chaotic; you’re aiming for persistent, not pushy.

If not completed step 1: a single reminder, then move on

On the “else” branch of that first If/Else, FulfillFox sends a single reminder:

• Send Email: “Still need to connect your carriers?”

• Time Delay: 2 days

• If/Else: have they completed step 1 now?

The reminder email is intentionally light:

• Subject: “Quick setup check for FulfillFox”

• Body: one paragraph empathising with being busy, one screenshot, one CTA button that deep-links to the step 1 screen.

• After the 2‑day delay, another If/Else checks for the same step_completed event. If yes, they merge into the same step1_done path as above. If no, the merchant flows to a Merge node that leads to the next step anyway.

Why still move them forward even if they never did step 1?

Because in the real world, step 2 might pull them through step 1. Maybe your “shipping rules” screen prompts them again to connect carriers inline. You don’t want their whole experience blocked forever on one missed step.

The Merge node is what lets both branches feed into the same path without violating the “single incoming edge” rule. It’s there purely to keep the graph valid and the canvas readable.

Repeat the pattern for each checklist item

After that first Merge, the structure repeats for each checklist item:

1. Wait Condition for the relevant step_completed event with a 1–2 day timeout.

2. If/Else to branch on “completed this step?”.

3. On “yes”:
   - Send Email celebrating that step and nudging the next.
   - Add Tag like step2_done, step3_done.
   - Short Time Delay.

4. On “no”:
   - One gentle reminder email.
   - Time Delay.
   - Second If/Else.
   - Merge into main path either way.

This creates a ladder of micro-journeys:

• Step 2: configure at least one shipping rule.

• Step 3: process your first batch.

• Step 4: turn on auto-batching.

Each email is hyper-specific:

• After rule configuration, show examples of profitable rules other merchants use.

• After first batch, show stats (“You just processed 23 orders 4x faster than default Shopify workflows”) and pitch auto-batching as the logical next step.

This is where AI-powered personalization in Spreeflo earns its keep. You already have custom event properties like orders_in_first_batch or avg_shipping_savings. Let AI write a paragraph that weaves those numbers into the email so it reads like the app is talking directly about their store, not a template.

Because all of this runs from one journey, FulfillFox can change timing and copy in a single place. No hunting across four autopilot tools to figure out where the “step 3 reminder” lives.

Protecting against over-communication

A very real concern for founder‑marketers: “This looks like a lot of emails. Am I spamming my users?”

Three guardrails in this pattern keep things sane:

1. Behaviour-first. Most emails only send when the relevant step is completed or overdue. Many merchants will blitz through and skip the reminders entirely.

2. “Send only once” toggles on all Send Email nodes. If you refactor the journey or allow some re‑entry later, you won’t double‑send content.

3. Natural pauses. Time Delays and Wait Conditions build in 24–48 hour gaps. You’re not firing three emails on the same day unless the merchant is actively blazing through the checklist.

If you want an extra layer, you can insert a Multi-way Split early in the journey based on Email Activity, sending “already highly engaged newsletter readers” down a slightly denser path and everyone else down a lighter-touch version. That’s optional sophistication; the base pattern works fine without it.

Measuring what matters: completion, activation, time-to-value

This journey exists to move three metrics:

1. Checklist completion rate
   - You already track the step_completed events in your app. Tag contacts on each completion and build a segment for “step4_done AND step5_done” as your “fully onboarded” group.

2. Activation rate
   - Define activation however it makes sense: “processed at least one batch” or “used feature X at least N times in Y days”. Use a Custom Event rule in the segment builder to track it, and compare install → activation rates before vs. after this journey.

3. Time-to-value
   - Measure the time between app_installed and the event that best correlates with long-term retention. The journey’s impact should show up as a shorter median time here.

The beauty of building this inside Spreeflo’s campaigns and journeys instead of hard‑coding it in your app is you can change the sequence without a deploy. Want to add a web push nudge for merchants who haven’t logged in for 7 days? Add a Send Web Push node and a Wait Condition, no engineering sprint required.

Adapting this pattern to your own Shopify app

Every e‑commerce app’s checklist looks a little different. The skeleton of the journey stays the same:

• Start from a single behavioural trigger (app_installed).

• For each critical setup step, define:
  - A Custom Event (step_completed, feature_used, goal_reached).
  - One celebratory email that points to the next step.
  - One reminder if they stall.

• Use tags (stepX_done, onboarding_started, activated) to make reporting and future journeys simpler.

• Let Wait Conditions collapse delays when users move fast, so your emails never feel behind.

If you’re still sending one generic “here’s how to get started” broadcast through a traditional ESP, this will feel more complex. It is, a bit. But you build it once and it works on every install, at any scale, without adding headcount.

That’s the second brand belief in action: founder‑led businesses win on leverage, not headcount. A well‑designed onboarding journey is the highest‑leverage artifact most Shopify apps can create. It onboards merchants while you’re asleep, on holiday, or deep in product work.

If you want a place to start, map your own checklist on paper, then translate each bullet into an event + email pair in Spreeflo. The quick-start guide walks through connecting your app, and from there, the sequence at the top of this page is your model.

The apps that win on the Shopify App Store aren’t always the ones with the cleverest features. They’re the ones that reliably walk every new install to that first undeniable win. This checklist‑driven journey is how you do that, on autopilot, for every merchant who gives you a shot.