Solutions
Meal subscription software and the lifecycle it has to model
Subscription software for digital products only has to keep charging a card. A meal subscription also has to keep a kitchen, a packing bench and a van in step with whatever state it is in today.
The states a meal subscription moves through
Each state means something different to the kitchen, not only to the finance record.
Scheduled
Sold but not yet started. It should not appear in production, and it must start on its own without anyone remembering to activate it.
Active
Generating slots and obligations every week. This is the only state that should produce food.
Paused
Still a customer, temporarily producing nothing. A pause that does not remove stops and counts is only a note.
Expired
The paid term has run out. The commitment ends and production stops, which is different from the customer choosing to leave.
Cancelled
A decision with a reason attached. Worth distinguishing from expiry, because one is churn and the other is a term finishing as sold.
Why expiry deserves its own state
Many systems collapse expiry into cancellation, and the reporting suffers immediately. A term that ended as sold is not a customer who chose to leave, and treating them identically makes it impossible to tell a renewal problem from a satisfaction problem.
Operationally the distinction matters even more: an expired customer is the single best renewal prospect a meal business has, and they are worth a different conversation from someone who cancelled with a reason.
Pausing is the feature that decides retention
People travel. If pausing is hard, the alternative they reach for is cancelling, and a cancelled customer is far harder to win back than a paused one. Making a pause self-service is one of the few product decisions that visibly changes churn.
The requirement is that a pause is real. Future scheduled days become skipped, counts drop, stops disappear from the manifest, and delivered history is never rewritten. Anything less means the operations team is still doing the work by hand.
What each transition must touch
| Transition | What has to move with it |
|---|---|
| Activation | Slots generated, first deliveries scheduled, customer appears in production for the right days. |
| Pause | Future days skipped, production counts reduced, stops removed, ingredient forecast recomputed. |
| Resume | Slots regenerated from the resume date forward, without resurrecting days that already passed. |
| Plan change | Slot count adjusted, selections prompted or defaulted, counts and forecasts updated, billing adjusted for the cycle. |
| Expiry | Production stops at the paid term, remaining scheduled days are skipped, delivered history and invoices are left untouched. |
Common questions
- Should customers be able to pause without contacting the kitchen?
- Yes. Self-service pausing reduces the number of messages an operations team has to read and act on, and it materially reduces cancellations, because the easy alternative to a difficult pause is leaving altogether.
- What should happen to a paused subscription when its term ends?
- It should still expire. A term that has run out does not become open-ended because the customer paused before it finished, and letting paused subscriptions live forever quietly inflates active-customer reporting.
- Does a pause change the invoice?
- That depends on how the plan was sold. What matters is that the decision is explicit and consistent — whether a pause extends the term or forfeits the days — because an inconsistent rule generates disputes that cost more than the meals.
See it running against a real kitchen
The product pages show the actual admin, loaded with a demonstration kitchen — production, packing, routes and the dashboard, exactly as an operator sees them.
Related reading
- SolutionsManaging mid-cycle subscription changes without re-typing themSelling the subscription is the easy part. The work is everything that happens after, when a customer changes something and five downstream systems need to hear about it before Tuesday.
- SolutionsMeal plan software for businesses that sell plans, not mealsA plan is a contract with a shape: a number of meals, a set of delivery days, a term, and a set of rules about what the customer may change and when. Software that does not model that shape will be fought with.
- SolutionsMeal delivery software for subscription kitchensMost software sold to food businesses is built for one-off orders. A meal-plan kitchen sells a commitment that runs for weeks, and almost every operational problem it has comes from that difference.
- SolutionsThe customer record in a meal-plan business is an operational documentIn most industries a CRM is a sales tool. In a meal-plan kitchen the customer record drives what gets cooked and where it goes, which makes it the most operationally dangerous data in the business.
- SolutionsSoftware for recurring cateringCaterers moving from event work to recurring contracts discover that their existing systems model the wrong thing — and that meal-plan systems assume a fixed menu they do not have.
- SolutionsSoftware for family meal subscription businessesA family subscription looks like one customer and behaves like four. One address, one payer, one delivery slot — and four sets of portion sizes, dislikes and allergens that all have to reach the right box.