Stop Sending Enterprise Copy to Solo Merchants: Company-Size Personalization That Scales

CartWizard, a four-person team selling a cart recovery app on the Shopify App Store, had a familiar problem.

On Monday, a solo creator with a side-hustle candle shop installs their app. On Tuesday, a 40-person DTC brand with eight-figure GMV does the same. Both get exactly the same onboarding sequence: the same “Welcome to CartWizard” email, the same mid-week “Have you launched your first flow?” nudge, the same upgrade pitch.

Trial-to-paid conversion was flat. Enterprise trials went quiet. Small merchants churned without ever turning on a single playbook.

The CartWizard team knew the issue: the messages were wrong for at least two-thirds of their trials. They also knew the alternative—maintaining three separate onboarding journeys by hand—would bury them in complexity.

The sequence at the top of this page is the whole journey, end to end. One automation, shared structure, but with the messaging tuned to company size: SMB, mid-market, and enterprise.

This article walks through that journey node by node, and shows how to adapt it for your own Shopify app or headless e‑commerce tool.

Why company-size segmentation is worth the trouble

If you sell an app to e‑commerce merchants, “one ICP” is lying to you.

• A solo founder on Shopify Basic wants templates that “just work” and a clear, quick win. They have no marketing team. They hate configuration.

• A mid-market brand cares about workflows, approvals, and not becoming blocked on that one person who “owns” the app.

• An enterprise Shopify Plus merchant wants architecture diagrams, ROI numbers, and the sense that someone senior on your side is paying attention.

They may all be in the same lifecycle stage—“trial installed but not yet activated”—but their motivations are very different. When everyone gets the same email:

• SMBs see enterprise case studies and think “this tool is overkill.”

• Mid-market teams see shallow quick-start content and never go beyond the basics.

• Enterprise evaluators see template carousels and assume you’re a small, immature vendor.

The fix isn’t three standalone journeys. That’s brittle and painful to maintain.

The fix is to capture a company_size attribute on every install, and route each new trial down a different path inside a single journey using a Multi-way Split. You keep a shared backbone (same trigger, same activation goal, same measurement), but the copy, examples, and CTAs are tuned for each slice of your market.

This is Spreeflo’s core belief in action: capture detail on every customer so you can speak to each uniquely, and then let automation multiply the impact of a tiny team.

The high-level shape of the journey

Before we zoom in on each node, here’s what the journey is doing conceptually:

1. Trigger: A new trial starts (your app is installed).

2. Warm-up: Tag them as a trial, give them a short delay before the first email.

3. Company-size routing: A Multi-way Split sends them into one of three paths based on company size, using conditions built with the segment builder.

4. SMB path: Quick-win templates and handholding.

5. Mid-market path: Workflow stories and team rollout content.

6. Enterprise path: Architecture, ROI, and human follow-up.

7. Merge + shared follow-up: All paths rejoin, get a generic week-one check-in, and you track per-size CTR and conversion.

You build this as a journey using Spreeflo’s visual editor for campaigns and journeys, with one trigger and a single Multi-way Split at its core.

Step 1: Trigger on “app installed” for every merchant

We’ll start the journey with a Custom Event trigger:

• Event name: app_installed

• Re-enrollment: On

Whenever your backend records a new install, send that event to the Spreeflo API along with the contact’s email. Your app doesn’t need a Shopify-specific integration here—you’re just calling the Spreeflo API from the same place you already talk to Stripe or your database.

Why app_installed?

• It’s the first moment you know who they are and how to contact them.

• It plays nicely with re-installs. Turning Re-enrollment on means a store that uninstalls and comes back six months later can go through onboarding again. The journey’s mid-flow lock ensures they’re never in two copies of the flow at once.

This trigger feeds into our shared setup steps.

Step 2: Tag the trial and give them breathing room

Immediately after the trigger, add two simple actions:

1. Add Tag

2. Time Delay

• Tag: trial-user (or however you label trials)

• Force tag trigger: off

The tag makes it easy to build segments like “All current trials” later, or to trigger secondary journeys if you need them.

• Delay: 1 hour

You could email instantly, but a one-hour pause gives new users a chance to click around and reduces the sense of “spam the second I install.” It also separates transactional app notifications from your first marketing email.

This is the last shared step before we branch by company size.

Step 3: Route by company size with a Multi-way Split

The star of this pattern is a Multi-way Split process node.

Ahead of time, you create a custom contact attribute in Spreeflo—call it company_size—and populate it with values like SMB, Mid-market, and Enterprise from your backend.

In the Multi-way Split, you define three branches:

• Branch “SMB”: Condition (via the segment builder): Contact attribute company_size is SMB

• Branch “Mid-market”: Condition: company_size is Mid-market

• Branch “Enterprise”: Condition: company_size is Enterprise

• Else branch “Unknown”: No condition; catches everyone whose size you don’t know yet.

The node evaluates these conditions top to bottom. Each new trial enters exactly one branch.

Why not three separate journeys based on different triggers?

• You’d end up duplicating every upstream change three times.

• Changing the definition of “activated” or “at-risk” would be error-prone.

• Reporting gets messy when the same lifecycle stage is spread over multiple automations.

With a single Multi-way Split, your routing logic lives in one place and is easy to audit.

Step 4: The SMB path – quick wins and templates

SMB merchants are usually time-poor and skeptical. They want to see your app make money without a lot of setup.

Inside the “SMB” branch, the sequence looks like this:

1. Send Email: “Your first recovered cart in 10 minutes”

2. Time Delay: 2 days

3. If/Else: “Have they activated?”

4. Activated branch → Time Delay: 1 day

5. Activated branch → Send Email: “Turn your starter flow into a money machine”

6. Not activated branch → Time Delay: 1 day

7. Not activated branch → Send Email: “Copy-paste onboarding for busy store owners”

• Use the Send Email action.

• Pick or build a dedicated SMB template in the email builder.

• Turn “Send only once” on so the same store doesn’t receive two copies if they ever re-enter.

This email does three things:

• Shows 1–2 template-driven examples relevant to smaller stores.

• Offers a single, clear CTA: “Turn on this starter recovery flow.”

• Reassures them there’s no dev work required.

Give them time to try the app (or ignore it).

In the If/Else node’s condition, use the Segment Builder to express:

• Custom Event recovery_flow_created

• Triggered at least 1 time in the last 7 days

If they’ve set up a flow, they go down the “activated” branch. If not, they go down “not activated.”

You’ve just checked for activation; a one-day buffer avoids back-to-back emails.

This email:

• Shares 2–3 optimization tips (A/B testing subject lines, adding SMS follow-ups if that’s part of your app, etc.).

• Might introduce a higher tier if it’s clearly tied to revenue.

Here you lean into handholding:

• Short checklist (3 steps max).

• Screenshots or GIFs of the exact buttons to click.

• Offer of help that scales, like a 10-minute loom walkthrough or a link to a troubleshooting guide.

Both activated and not-activated branches then flow into a Merge node so the journey can continue with shared steps.

Messaging is specific to SMBs, but structurally this mirrors the other paths. That keeps the system maintainable for your team.

Step 5: The mid-market path – workflow and team rollout

Mid-market merchants usually have multiple stakeholders and some internal process. They don’t want “set it and forget it” so much as “fit this into how we already work.”

The “Mid-market” branch uses the same node types with different copy:

1. Send Email: “3 recovery workflows your team can launch this week”

2. Time Delay: 2 days

3. If/Else: “Has a key feature been used?”

4. Activated branch → Time Delay: 1 day

5. Activated branch → Send Email: “How [similar brand] scaled recovery with your setup”

6. Not activated branch → Time Delay: 1 day

7. Not activated branch → Send Email: “Implementation checklist for your marketing team”

• Focus on use cases: dedicated flows for new vs returning customers, integrating with their helpdesk, etc.

• Include a simple diagram of “how CartWizard fits into your stack” if that’s helpful.

Give them time to try the app (or ignore it).

Condition might be:

• Custom Event feature_used

• Property feature_name is advanced_recovery_rules

• Triggered at least 1 time in the last 7 days

• A mid-market-flavored case study.

• Invite them to expand usage across more team members.

• Actionable steps: “Assign an owner,” “Connect email domain,” “Review default templates,” etc.

• Call out how long each step typically takes; time-boxing helps busy teams commit.

Again, both branches flow into the same Merge node as the SMB path.

The value here is storytelling. You’re still in the same lifecycle stage (trial onboarding), but you’re speaking their language: workflows, teams, rollouts.

Step 6: The enterprise path – human touch on autopilot

For enterprise-size merchants, a single automated sequence is rarely enough. But you can use automation to make your human outreach timely and relevant.

The “Enterprise” branch looks like this:

1. Send Email: “How CartWizard fits into your commerce architecture”

2. Time Delay: 1 day

3. Send Internal Email: “New enterprise trial started”

4. Time Delay: 2 days

5. If/Else: “Have they engaged seriously?”

6. Engaged branch → Time Delay: 1 day

7. Engaged branch → Send Email: “Scaling recovery across brands and regions”

8. Not engaged branch → Time Delay: 1 day

9. Not engaged branch → Send Email: “Can we share a 20-minute implementation plan?”

This is not a cute welcome email. It should:

• Acknowledge their scale: multiple storefronts, teams, systems.

• Show where your app sits in the stack (high level).

• Include a clear CTA to either start with a “standard” enterprise playbook, or book a short implementation review call.

Use the Send Internal Email action to notify a founder or success lead:

• Include the contact’s name, email, plan, and any company_size details.

• Link to their activity in your own admin dashboard.

• Keep “Send only once” on so you don’t flood your inbox if they re-enroll months later.

This blends automation with the white-glove attention big merchants expect.

Your condition might be a bit stricter here:

• Custom Event recovery_flow_created at least 1 time in the last 7 days

• OR

• Custom Event enterprise_call_booked has triggered

Wrap that logic in a subgroup in the Segment Builder so both events are considered.

• Talk about rollouts to additional stores.

• Mention annual pricing or enterprise features if you offer them.

• Treat this as a polite nudge.

• Encourage them to reply directly or book a slot.

Both branches then join the same Merge node as the SMB and mid-market paths.

What you’ve built is a pattern: every enterprise trial triggers an internal alert and a more serious tone from the very first touch, without you having to remember to check “who signed up last night.”

Step 7: Shared follow-up and measuring per-size performance

After the Merge, everyone—SMB, mid-market, enterprise, and even the “Unknown” branch—rejoins a single track.

You might add:

1. Time Delay: 3 days

2. Send Email: “Week one check-in”

3. Update Contact Attribute:

Give them more time to see results from whichever flows they’ve turned on.

• Generic enough to work for all sizes.

• Links to a short survey (“How confident do you feel about your recovery setup?”) or a feature tour.

• Invitation to reply if they’re stuck.

• Attribute: onboarding_stage

• Update type: UPDATE

• Value: activated (or onboarded, whatever makes sense in your schema)

Now you can easily build segments like “Activated trials by company size” without re-deriving it from events each time.

From here, you can send them into a broader lifecycle journey or leave them to receive your regular product updates.

Tracking per-size CTR and conversion

Because each branch uses different email templates, you get email performance broken out automatically: SMB templates, mid-market templates, enterprise templates.

To get the deeper funnel numbers:

• Instrument events like trial_converted or subscription_upgraded via the Spreeflo API.

• Create three segments with the segment builder: company_size is SMB AND trial_converted at least once in the last 30 days.

• Same for Mid-market.

• Same for Enterprise.

• Compare segment sizes to the number of trials entering each path over the same window.

Those are your per-size conversion rates. You’ll often find, for example, that SMB CTR jumps quickly from 10% to 18% with template-heavy copy, while enterprise reply rate becomes the metric to watch.

This is where the pattern earns its keep. You’re not blindly optimizing “overall CTR”; you’re tightening each slice of the funnel where it actually matters.

Design choices that keep this manageable

A few configuration decisions make this journey practical for a small team:

• One trigger, one journey. Everything starts at app_installed. You avoid duplicating logic and have a single place to adjust your definition of “activated.”

• Re-enrollment on the trigger, “send only once” on key emails. If a merchant churns and comes back, they can go through the journey again, but they won’t get the same welcome email twice. That balance respects their inbox while still letting you nudge them if they return.

• Multi-way Split instead of nested If/Else nodes. You could express company size with a stack of If/Else branches, but it would be harder to read. Multi-way Split keeps the routing clear.

• Merge before shared steps. The Merge process node lets you recombine all three paths cleanly before that week-one check-in, so you don’t end up maintaining three copies of the same generic email.

Taken together, this is founder leverage in practice. You invest a few hours designing the journey once, and it keeps every new trial on the right track without more headcount.

Zooming out: one pattern, many launches

We used onboarding as the example, but the same company-size variation pattern applies anywhere you have shared lifecycle stages:

• Feature launches: SMBs see “how to use this in 10 minutes,” enterprises see migration guides and ROI modeling.

• Renewal nudges: smaller merchants get “here’s what you earned,” larger ones get “here’s what your team accomplished.”

• Pricing updates: solo stores get clarity and reassurance; big brands get a change-log and options.

The mechanics don’t change: capture a company_size attribute, route with a Multi-way Split, send size-specific emails, and recombine paths where it makes sense.

Because Spreeflo stores unlimited non-marketing contacts and prices only on the marketing contacts you actually email, you can afford to keep those richer attributes on every lead without stressing about cost. If you’re curious how that scales, the detailed breakdown in Spreeflo’s pricing plans is worth a look.

Most e‑commerce app developers already have the traffic and installs. The leak is almost always in how generically those trials are treated once they show up.

The journey at the top of this page is one way to fix that: a single, intelligent automation that talks differently to a solo candle shop and a global DTC brand, while your team stays small and focused on the product.