One Trial, Three Stories: Company-Size Segmentation for SEO SaaS Email

Your “day 1 trial” email is probably talking to a solo consultant, a 10‑person agency, and a 500‑seat in‑house team as if they’re the same buyer. They’re not.

The solo consultant needs plug‑and‑play templates. The mid‑size agency wants to see client workflow examples. The enterprise team is scanning for security, SSO, and roll‑out risk. One-size onboarding ignores all of that — and it shows up in weak trial-to-paid numbers.

The sequence at the top of this page is the whole journey, end to end. It keeps the lifecycle moment the same (new trial), but forks the experience into three different stories based on company size: SMB, mid‑market, and enterprise. You build it once; every trial gets the path that fits them.

We’ll walk through that journey node by node, using a fictional SEO SaaS called RankPulse (35k MRR, rank tracking + alerts) as our example. By the end, you’ll have a concrete pattern you can drop into your own account and adapt in an afternoon.

Why “one onboarding flow” quietly kills SEO SaaS trials

RankPulse sees the same thing most SEO SaaS teams do:

• Lots of trials, driven by content and word-of-mouth.

• Strong activation for small teams.

• Muddy results from agencies and mid‑market in‑house teams.

• Almost no traction with larger enterprise prospects despite decent traffic.

When they look closer, the problem is obvious: everyone gets the same onboarding sequence. The initial email highlights quick wins with the UI, a generic “connect Search Console” step, and a case study from a small agency.

For a freelance SEO, that lands fine.

For a 40‑person content team inside a VC‑backed SaaS, it doesn’t even scratch the surface of their buying questions. They want to know:

• How does this fit across 10–20 domains?

• Can we automate reporting for 30 stakeholders?

• What does migration from our current tool look like?

You can’t speak to any of that if “company size” is a vague idea in your head instead of a concrete attribute on the contact.

This pattern fixes that: capture company size once, route each trial into the right branch, and send emails that read like they were written for their specific situation.

That’s the first Spreeflo belief in action: capture detail on every customer so you can speak to each uniquely.

The high-level journey: one trigger, three narratives

At a high level, the journey you see in the visual sequence does three things:

1. Uses a lifecycle trigger to catch every new trial contact.

2. Splits contacts into SMB / mid‑market / enterprise using a Multi-way Split node based on a company-size attribute.

3. Runs a short, size-specific email sequence in each branch, then merges everyone back into a shared “convert or expire” decision.

All inside a single always-on journey, built with Spreeflo’s campaigns and journeys editor.

You’re not copying and pasting three separate automations. You’re building one skeleton, then tuning the copy and proof on each branch. That’s exactly how founder-led businesses win on leverage, not headcount: design the system once, let it adjust itself for each contact.

Let’s break down the nodes.

Step 1: Capture company size as a real attribute

Before the journey can branch intelligently, you need company size on the contact — not buried in CRM notes or Stripe metadata.

For RankPulse, that starts at trial signup:

• Their trial signup page is a Spreeflo form embedded inline on their marketing site.

• They add a required “Team size” question (Number or Dropdown).

• In the form editor, they map that answer to a custom contact attribute, say employee_count.

• _Map to contacts_ is on, with Email required, so every submission creates/updates a contact automatically.

If you’re not already doing this, Spreeflo’s docs on how to create and embed forms walk through the setup. The key is: company size lands as a structured attribute on every new trial contact.

For trials created outside your own forms (e.g., in-app signups or billing events):

• When a user starts a trial in your app, your backend POSTs to the Spreeflo events API with a started_trial event and the email.

• At the same time, your backend either includes employee_count as a contact attribute in that API call or upserts the contact separately.

The Spreeflo API is your bridge here. The implementation detail is up to you; the design requirement is fixed: “company size” must be a filterable contact attribute.

Once that attribute is in place, the rest of the journey becomes easy.

Step 2: Use a lifecycle trigger, not a one-off import

The first node in the sequence is a Join Segment trigger called “New trials.”

Under the hood, that segment uses Spreeflo’s segment builder with criteria something like:

• Contact attribute lifecycle_stage is trial

• Email Subscription Status is Subscribed

• Contact Added Date is within the last 1 day

You could also express this as a Criteria Match trigger with the same conditions embedded. RankPulse uses a saved segment so they can reuse “New trials” in other automations later.

Configuration for the trigger:

• Type: Join Segment

• Segment: New trials

• Re-enrollment: off

Re-enrollment stays off because they want each contact to experience this “new trial” journey only once. If someone cancels and comes back six months later on a new plan, they handle that in a separate “win-back” journey.

Why a lifecycle trigger instead of tying it to a single event like started_trial?

• If your definition of “trial” changes (say you add a credit-card-required path), you update the segment criteria, not every journey.

• You can test tweaks to trial logic — like extending trial length for some plans — without touching email automation.

The trigger’s bodyText in the canvas might read: “When a contact joins the New trials segment, start size-based onboarding.”

From this node, every new trial flows into the next step.

Step 3: Tag and immediately fork by company size

Right after the trigger, the journey applies an Add Tag action:

• Tag: stage:trial_onboarding

• Force tag trigger: off

This tag is there for two reasons:

• It gives you an easy way to pull this cohort into reports or one-off campaigns later.

• It marks contacts so you can identify “trial users currently in onboarding” inside your audience.

The next node is where the pattern really starts: a Multi-way Split based on company size.

RankPulse defines three branches plus a catch-all:

• Branch smb: employee_count less than 20

• Branch mid_market: employee_count between 20 and 99

• Branch enterprise: employee_count 100 or more

• Else branch unknown_size: employee_count is blank

In Spreeflo, each branch condition uses the segment builder:

• For SMB: Contact attribute employee_count “less than” 20

• For mid-market: a sub-group with employee_count “greater than or equal” 20 AND “less than” 100

• For enterprise: employee_count “greater than or equal” 100

• Else branch needs no condition; it catches everything that didn’t match earlier branches.

Order matters: you put SMB, then mid‑market, then enterprise, then else.

Why use a Multi-way Split here instead of three separate journeys?

• Maintenance: you update timing or shared logic once.

• Consistency: everyone still passes through the same conversion gates later in the flow.

• Reporting: you can look at “this journey” and see performance at a glance, with differences driven only by branch content.

From here, the journey effectively becomes three parallel mini-flows — one per size band — that all rejoin later.

Step 4: Design size-specific email sequences (with proper pacing)

Each size branch gets its own short email sequence. The mechanics (nodes) are identical; the copy and proof differ.

Let’s walk one branch, then call out what changes for the others.

SMB branch: fast wins and templates

Inside the smb branch:

1. Send Email — “Welcome to RankPulse, here’s your first quick win”
   - Template: trial_smb_day0
   - Send only once: on
   - Content focus:
   - Connect Search Console & Analytics in under 5 minutes.
   - Run your first rank tracking project with a prebuilt template.
   - Show a solo consultant / tiny agency case study.

2. Time Delay
   - 1 day
   - This respects pacing and gives them time to click around.

3. Send Email — “Copy these 3 report templates for your clients”
   - Template: trial_smb_day1
   - Send only once: on
   - Content focus:
   - Template library for client reports.
   - How to set up weekly alerts to catch ranking drops.
   - CTA: “Turn on alerts for your top 10 keywords.”

There’s no Check Email Activity here yet; simplicity wins for a first pass. Every SMB trial gets two high-signal emails tuned to how small teams work.

Mid-market branch: workflow and client volume

The mid_market branch uses the same node pattern:

1. Send Email — “How mid‑size agencies run 50+ sites through RankPulse”
   - Template: trial_mid_day0
   - Emphasis: multi-client project structure, permissions, tagging.

2. Time Delay — 1 day.

3. Send Email — “Automate reporting across your client portfolio”
   - Template: trial_mid_day1
   - Emphasis: scheduled exports, client-ready PDFs, alert routing.

Mechanically identical, content completely different.

Enterprise branch: risk, rollout, and scale

The enterprise branch again mirrors the node pattern:

1. Send Email — “Rolling RankPulse out across a large SEO team”
   - Template: trial_ent_day0
   - Emphasis: SSO, permissions, audit logs, onboarding timeline.

2. Time Delay — 1 day.

3. Send Email — “See how [X] scaled rank tracking across 25 properties”
   - Template: trial_ent_day1
   - Emphasis: enterprise case study, change management, executive dashboards.

You can build these emails with Spreeflo’s drag-and-drop email builder, and if you’re on Professional, you can personalize with AI variables so subject lines and snippets reference the contact’s role or company name.

Unknown-size branch: safe defaults

For the unknown_size else branch, RankPulse:

1. Sends a single “generic but still useful” trial kick-off email.

2. Uses the rest of the app experience (and other journeys) to encourage users to fill in missing profile details later.

They don’t ask for company size in email; that question lives in-app as part of profile completion or a popup form journey.

Merge it all back together

All four branches end in a Merge node called post_size_onboarding.

That keeps your canvas readable and ensures every trial — regardless of size — now flows into the same conversion logic.

Up to this point, you’ve achieved the core pattern:

• Same lifecycle stage.

• Three flavors of onboarding content.

• One journey to maintain.

Step 5: Add a shared “convert or nudge” decision

After the Merge, the journey handles conversion in a single place.

RankPulse uses a mix of a Wait Condition and an If/Else:

1. Wait Condition
   - Condition: Custom Event upgraded_plan triggered at least 1 time in the last 7 days.
   - Timeout: 7 days.
   - How the data arrives:
   - When someone upgrades to a paid plan in-app, the backend calls the Spreeflo API with an upgraded_plan event containing the contact’s email and plan details.

2. If/Else
   - Condition: Contact attribute plan is paid.
   - Then branch is_paid: they converted.
   - Else branch still_trial: they didn’t.

This node pauses the journey until either:

• The contact upgrades (event condition met), or

• 7 days pass without an upgrade (timeout).

On the is_paid branch:

• Send Email — “Welcome to your paid RankPulse plan”
  - Template: welcome_paid_from_trial
  - This email is generic across sizes; they’ve already had size-specific value proof.
  - It can still reference company size dynamically in copy if you like.

On the still_trial branch:

• Send Email — “Your trial is ending — here’s what you’ll lose”
  - Template: trial_last_chance
  - This one is also shared across sizes for the first iteration; it calls back to the features you highlighted in onboarding, framed as what they’d be walking away from.

Because there’s at least a 1‑day delay in each size branch and then up to 7 days in the Wait Condition, you never end up with back-to-back sends on any path. Message pacing stays healthy.

At this point, the journey ends. Every new trial has walked:

Through a lifecycle-based trigger,

Into a size-specific story,

Back into a shared conversion decision.

Measuring per-size performance (and what to watch)

Once this is live, you care about two metrics for each size band:

• Click-through rate on the size-specific onboarding emails.

• Trial-to-paid conversion rate for contacts who went through each branch.

Some ways to get those numbers cleanly:

• Name your email templates clearly (trial_smb_day0, trial_mid_day0, etc.) so per-email analytics are easy to scan.

• Build saved segments like “Converted SMB trials” (plan is paid, tag stage:trial_onboarding present, employee_count < 20) using the segment builder. Do the same for mid‑market and enterprise.

• Track the share of each size segment that ends up in those “converted” segments over a consistent window (say, 30 days).

If, for example, SMB CTR is strong but conversion lags, you may be over-indexing on templates and under-selling ongoing value. If enterprise CTR is weak, your first email may be missing the specific risks/concerns that matter at that scale.

The beauty of this design is that improving performance doesn’t mean rebuilding automation. You can:

• Swap a case study in the enterprise branch without touching any other branch.

• Add a third mid‑market email before the Merge, as long as you insert a Time Delay between sends.

• Adjust timing globally (e.g., change the Wait Condition timeout) and have it apply to every size.

That’s leverage in the precise sense that matters: small tweaks, compounding over hundreds or thousands of trials, without needing an extra marketer to babysit campaigns.

Adapting this pattern beyond trials

This company-size split is reusable anywhere you have a clear lifecycle moment:

• Expansion campaigns: Different upsell stories for small teams vs. mid‑market agencies.

• Re-engagement: Enterprise accounts that go quiet might need a CSM-style “strategy review” offer; SMBs may just need a reminder of a key feature they stopped using.

• Feature launches: A new “bulk keyword import” tool means very different things to a solo consultant versus a 30‑seat agency.

Each time, you drop a Multi-way Split node into the journey at the point where messaging diverges, use company-size attributes in the conditions, and keep the rest of the flow shared.

The underlying principle stays the same: you capture richer profile detail once, then let your automations adapt messaging automatically. That’s how you stop talking to “a user” and start talking to the actual business on the other side of the screen.

For a small SEO SaaS team, this isn’t a nice-to-have. It’s the difference between a leaky trial pipeline and a system that quietly upgrades the right customers, every week, without demanding more hours from you.

Build the journey once. Let company size decide the story.