Upsell & Expansion with Iterable

Why Most Upsell Campaigns Fail Before They Launch

Most teams send upgrade offers on a calendar schedule — a 30-day email, a 60-day email, a "you're missing out" push notification at 90 days. The timing is arbitrary, the targeting is broad, and the conversion rate reflects both.

The problem isn't the offer. It's that you're guessing when someone is ready to upgrade instead of watching for the signals that tell you.

Iterable gives you the infrastructure to fix this. Workflow Studio, its visual automation builder, lets you build behavior-triggered expansion sequences that respond to what users actually do — not what you assumed they'd do when you built the campaign six weeks ago.

This guide walks you through a practical implementation for identifying upgrade-ready users and delivering the right offer across email, SMS, and push — using Iterable's native channels and data tooling.

---

How to Think About Expansion Signals

Before touching Workflow Studio, you need a clear model of what "upgrade-ready" looks like for your product.

Usage-based signals are the most reliable. These typically include:

• Hitting a feature limit (storage cap, seat count, API call threshold)
• Repeatedly accessing a paywalled feature without converting
• Reaching 80%+ of a usage quota in the current billing period
• Logging in more than X times per week for the past 30 days

Behavioral signals add a second layer:

• Sharing content or inviting collaborators (indicating growing team use)
• Exporting data or using integrations that suggest deeper workflow dependency
• Completing onboarding for all core features (they've extracted base value)

Map these signals to specific events and user properties before you build anything in Iterable. Every trigger in your workflow needs a corresponding data point hitting Iterable's Events API or updating a User Profile field.

---

Setting Up Your Data Layer in Iterable

Iterable stores user-level data in User Profiles, which can hold custom fields — strings, numbers, booleans, dates. Your engineering team needs to push the right attributes here.

For an upsell workflow, you'll want fields like:

• `current_plan` (string: "free", "starter", "pro")
• `storage_used_pct` (number: 0–100)
• `seats_used` (number)
• `seats_limit` (number)
• `last_upgrade_prompt_seen` (date)
• `paywalled_feature_attempts` (number)

On the event side, configure your product to fire named events to Iterable when key actions occur:

• `feature_limit_reached`
• `paywall_encountered`
• `collaborator_invited`
• `usage_threshold_hit`

These events become the entry triggers and branching conditions in Workflow Studio. Without clean event data, your automation is guessing. With it, every message has a reason to exist.

---

Building the Expansion Workflow in Workflow Studio

Workflow Studio is Iterable's drag-and-drop automation canvas. You'll build a multi-channel sequence here that branches based on user behavior and plan state.

Step 1: Configure the Entry Trigger

Set your workflow entry to trigger on the `feature_limit_reached` or `usage_threshold_hit` event. You can also use a List-based entry if you prefer to batch-qualify users daily through a segmentation query — this is useful if your event data isn't fully reliable yet.

Add an entry filter: `current_plan != "enterprise"` so you're not targeting users who are already on your highest tier.

Step 2: Add a User Property Check

Immediately after entry, add a Filter node to branch users based on their plan and usage profile.

• Branch A: Users on free plan with `paywalled_feature_attempts >= 3`
• Branch B: Users on starter plan with `storage_used_pct >= 80`
• Branch C: Users on starter plan with `seats_used >= seats_limit`

Each branch gets a tailored message. A free-to-starter offer looks different from a starter-to-pro offer. Don't send the same creative across all three paths.

Step 3: Send the First-Touch Message

For each branch, configure the channel priority. Iterable's native multi-channel send lets you specify email, SMS, and push within the same workflow without switching tools.

A practical first-touch sequence:

1. Push notification (Day 0) — short, contextual. "You've hit your storage limit. See your options."
2. Email (Day 1 if no push engagement) — detailed breakdown of what they're missing, specific plan comparison, CTA to upgrade page
3. SMS (Day 5 if no email click) — only if user has opted in; direct link to billing page

Use Hold Until nodes to space these out and Conditional Splits to check whether the user has already upgraded (via an updated `current_plan` field) before sending the next message.

Step 4: Build the Exit and Suppression Logic

This is where most teams underinvest. Add a workflow exit condition that fires when `current_plan` changes — so a user who upgrades mid-sequence doesn't receive the remaining messages.

Also suppress users who've received an upgrade prompt in the last 14 days using the `last_upgrade_prompt_seen` field. This prevents the same user from entering multiple upsell workflows simultaneously if they're triggering multiple signals.

Step 5: Tag and Track Conversions

Iterable doesn't have a native revenue attribution model, so you'll track conversions through events. Fire a `plan_upgraded` event from your billing system back to Iterable. This lets you measure how many users who entered the workflow converted, and within how many days.

---

Catalog and Templates

Use Iterable's Template Editor to build modular email templates with dynamic content blocks. If you're running multiple expansion tracks (free-to-paid, starter-to-pro, team-to-enterprise), a shared template structure with swappable content blocks cuts your production time significantly.

Handlebars templating in Iterable lets you inject user-specific data — `{{current_plan}}`, `{{storage_used_pct}}`, `{{seats_limit}}` — directly into message copy. Use this to make each message feel specific rather than generic.

---

Limitations to Know

Iterable is strong on execution, but there are gaps worth understanding before you commit to this architecture.

• No native product analytics. Iterable doesn't ingest behavioral data automatically — you're dependent on your engineering team to push events and user properties consistently. If the data pipeline breaks, your targeting breaks with it.
• Limited predictive scoring. Unlike some platforms, Iterable doesn't offer built-in propensity modeling or upgrade-likelihood scores. You're building rule-based logic, not ML-driven recommendations. This is workable, but it requires you to define thresholds manually.
• Reporting is basic. Workflow-level analytics show sends, opens, and clicks, but there's no built-in funnel view connecting campaign entry to revenue outcome. You'll need a BI tool or external analytics layer to close that loop.
• SMS compliance overhead. Iterable handles opt-in management, but compliance configuration for SMS (short codes, keywords, opt-out flows) requires setup time that teams often underestimate.

---

Frequently Asked Questions

How granular can I get with entry triggers in Workflow Studio?

Very granular, provided your event data is clean. Workflow Studio supports event-based triggers with property filters — so you can enter users only when `feature_limit_reached` fires AND `current_plan == "starter"` AND `seats_used >= 5`. The constraint is always data quality, not the tool's logic capability.

Can Iterable handle upsell workflows for B2B accounts with multiple users?

Partially. Iterable is built around individual user profiles, not account-level objects. If you need to trigger an upsell sequence when any user on a given account hits a limit, you'll need to handle that aggregation logic externally and push the result to a single decision-maker's profile. It works, but it adds engineering overhead.

What's the right number of touchpoints in an expansion sequence?

Three to five is the practical range for most SaaS products. Beyond that, you're adding noise without meaningfully increasing conversion. The more important variable is timing — a well-timed single message on the day a user hits their limit outperforms a five-message sequence that starts a week later.

How do I prevent users from re-entering the workflow repeatedly?

Use the `last_upgrade_prompt_seen` user property as an entry filter. Set it to update every time a user enters the workflow, and suppress re-entry for 14–30 days. Pair this with workflow-level re-entry settings in Workflow Studio, which let you control whether a user can enter the same workflow multiple times and under what conditions.