Iterable for Meal Kit Subscriptions

Meal kit subscriptions run on timing, habit, and perceived value. Miss any one of those three and a customer cancels. Iterable gives you the infrastructure to manage all three across email, SMS, push, and in-app — but only if you set it up around the actual behavior patterns of meal kit buyers, not generic e-commerce logic.

This guide covers exactly how to do that.

---

Why Meal Kit Subscriptions Need a Different Approach

Most subscription businesses worry about churn. Meal kit businesses worry about *weekly* churn. Your customer doesn't cancel once — they skip, pause, reduce box size, swap delivery days, and gradually disengage before they ever click "cancel."

That sliding scale of disengagement is what Iterable needs to be configured to detect and respond to. Generic re-engagement campaigns built for SaaS or retail won't cut it here.

---

Events to Track in Iterable

Your event schema is the foundation. Get this wrong and every segment and automation built on top of it is unreliable.

Core Subscription Events

These are non-negotiable. Every event below should fire into Iterable via API or your data warehouse sync:

• `subscription_started` — with plan type, box size, meals per week, and acquisition source
• `box_skipped` — with reason (user-initiated vs. auto-skip), how far in advance, and how many consecutive skips
• `box_delivered` — with delivery date, number of meals in box
• `meal_rated` — star rating, recipe ID, cuisine type, difficulty level
• `subscription_paused` — pause reason, expected return date
• `subscription_cancelled` — cancellation reason category, tenure in days, lifetime value
• `plan_changed` — old plan vs. new plan (upsell and downsell both matter)
• `payment_failed` — attempt number, payment method type
• `menu_viewed` — which week's menu, time spent, meals clicked
• `meal_customized` — swaps made, proteins changed, dietary filters applied

Behavioral Signals Worth Capturing

Beyond transactional events, track engagement patterns that predict churn before it shows up in the subscription data:

• App session frequency relative to delivery cadence
• Email open rate on weekly menu emails (dropping open rate on this specific email type is a leading churn indicator)
• Support ticket submission — tag the category (delivery issue, recipe quality, billing)
• Referral link generated vs. referral link used

---

Segments to Build

Iterable's segmentation becomes powerful when you combine subscription status with behavioral data, not just demographic fields.

Lifecycle Stage Segments

Structure your customer base into these stages:

1. Onboarding — subscribed within the last 21 days, fewer than 3 boxes delivered
2. Established — subscribed more than 21 days, no skips in the last 4 weeks, at least one meal rated
3. At-Risk — two or more consecutive skips, or zero email opens on the last 3 menu emails, or support ticket in the last 14 days
4. Paused — subscription status = paused, segmented further by days since pause began
5. Win-Back — cancelled within the last 90 days, LTV above $150

Preference-Based Segments

These drive personalization, not just targeting:

• Dietary profile — built from meal customization events and stated preferences at signup (vegetarian, gluten-free, high-protein)
• Cooking confidence — derived from recipe difficulty ratings and meal ratings. Customers who consistently rate easy recipes highly and skip complex ones need different content than customers who rate chef-level recipes well.
• Family vs. solo — box size and number of servings is a proxy here
• Convenience-oriented vs. experience-oriented — time spent on menu pages and meal variety choices signal this

---

Automations to Build in Iterable Workflows

Onboarding Journey (Days 1–21)

The first three boxes determine 60-day retention. Build a workflow triggered by `subscription_started` that:

• Sends a welcome email within 30 minutes focused on what to expect for box one, not a generic brand story
• Triggers an SMS on estimated delivery day for box one with a prep tip for the most popular meal in their first box
• Fires a day-3 email asking for a meal rating — make it one tap or one click, not a full survey
• Checks at day 14: if no `meal_rated` event has fired, route into a "help getting started" branch with recipe support content

Skip Prevention Campaign

When `box_skipped` fires for the first time, don't send a win-back message — the customer is still subscribed. Send a menu highlight email for the *next* delivery week within 2 hours of the skip. Show them three meals personalized to their dietary segment.

When a second consecutive skip occurs, trigger an SMS or push message (based on channel preference) with a reduced-commitment option: "Switch to every-other-week delivery?"

After three consecutive skips, flag the customer as At-Risk and route into your churn prevention workflow.

Payment Recovery Workflow

Payment failure is recoverable if you act within 48 hours. When `payment_failed` fires:

• Hour 1: In-app notification (if they have the app) with a direct link to update payment
• Hour 4: Email with a clear subject line naming the problem and a single CTA
• Hour 24: SMS if the payment is still unresolved — keep it factual, not guilt-based
• Hour 48: Final email before the box is held

Do not send all four if the payment resolves — use Iterable's exit conditions to halt the workflow on `payment_succeeded`.

Win-Back Campaign (Post-Cancellation)

Wait 7 days before first contact. The customer just made a deliberate decision — hitting them immediately produces unsubscribes, not reactivations.

Build a 3-message sequence over 30 days:

1. Day 7: "We updated the menu" — show 3 new meals relevant to their dietary history
2. Day 21: Offer a discounted return box (only for customers with LTV above your threshold — don't discount for customers who cancelled after one box)
3. Day 30: Final message focused on what has changed based on their cancellation reason category

Personalize message 1 and 3 using the `cancellation_reason` field. A customer who cancelled for "too expensive" needs different messaging than one who cancelled for "recipes too complicated."

---

Industry-Specific Challenges in Iterable

Menu personalization at scale is the hardest problem. Iterable's catalog feature can store your weekly menu as a dynamic data set, but you need to build the logic that maps dietary segments to meal recommendations. This requires either a recommendation feed passed in via API or a catalog filter setup using Iterable's catalog query language — plan for this before launch.

Weekly send volume spikes are real. Every customer gets a menu email on the same day. If you have 50,000 active subscribers, that's 50,000 sends in a narrow window. Warm your sending IP properly and use Iterable's send time optimization carefully — for menu emails, you may want a defined window rather than full AI optimization to avoid delivery clustering near cutoff deadlines.

Suppression logic requires discipline. A customer in a payment recovery workflow should not simultaneously receive a skip prevention email or a promotional upsell. Build suppression lists for each active workflow and audit them monthly.

---

Frequently Asked Questions

How should we handle customers who have both the app and email opted in?

Build a channel preference model using engagement data, not assumptions. Look at which channel each customer has opened or clicked in the last 30 days. Iterable's send-time optimization works at the channel level — use it, but override it for time-sensitive messages like delivery day notifications where SMS or push almost always outperforms email.

Can Iterable handle the weekly menu personalization without a separate recommendation engine?

Iterable's catalog and Handlebars templating can get you partway there — you can filter catalog items by tag and surface meals matching a customer's dietary segment. For true one-to-one personalization based on past ratings and behavior patterns, you need a recommendation layer (built internally or via a tool like Recombee or Constructor) that pre-computes recommendations and passes them into Iterable as custom user fields or catalog entries.

What's the right cadence for lifecycle emails without fatiguing subscribers?

Meal kit customers already receive a high-frequency transactional email cadence — menu reveal, order confirmation, shipping notification, delivery confirmation. Add lifecycle touches on top of that only when behavior triggers them. A customer in onboarding might receive 8–10 emails in their first 3 weeks across transactional and lifecycle. An established customer should receive nothing beyond the weekly menu email and transactional updates unless a behavioral signal triggers a campaign.

How do we measure whether our Iterable setup is actually working?

Track these three metrics at the segment level, not just the campaign level: skip rate by lifecycle stage, 30-day retention by acquisition source, and reactivation rate within 90 days of cancellation. If your At-Risk segment's skip rate is declining quarter-over-quarter, your automations are working. If reactivation rate stays flat despite win-back campaigns, the problem is either the offer, the timing, or the targeting logic — Iterable's A/B testing on workflow branches can isolate which.