Solutions
Order management when the orders repeat themselves
Order management systems assume an order is created, fulfilled and closed. A meal-plan order is created once and fulfils itself over and over, which breaks most of the assumptions underneath the category.
Two different objects called “an order”
| A one-off food order | A recurring meal-plan obligation |
|---|---|
| Created by a customer action. | Generated by a standing commitment, without anyone acting. |
| Complete when delivered. | Never complete until the term ends or someone stops it. |
| Changes mean cancelling and reordering. | Changes amend future instances while leaving delivered ones untouched. |
| Revenue recognised per order. | Revenue recognised across a term, against deliveries that may be paused or skipped. |
| History is a list of transactions. | History is a schedule, part of which has already happened. |
Generated forward, but only so far
Recurring obligations have to be materialised into concrete dated instances, or the kitchen cannot see next week. But materialising them too far ahead creates a second problem: days that exist beyond the paid term, or beyond the point where the customer can still change their mind.
The practical boundary is the paid term on one side and the cut-off on the other. Inside that window, days are real and editable. Outside it, they either do not exist yet or are frozen.
Delivered history is immutable
The one rule that prevents most data disasters in this model: once a day has been delivered or failed, it is a record of something that physically happened and must never be rewritten by a later change.
Cancel a subscription and future scheduled days disappear; delivered days, their proof of delivery and their invoices stay exactly as they were. Systems that rewrite history to make the current state tidy destroy the evidence needed to settle a dispute.
Common questions
- Should each delivery be a separate order record?
- Each delivery needs its own dated instance so it can be scheduled, packed, driven and settled independently. What it should not be is independently created — it is derived from the subscription rather than placed by the customer.
- What happens to future instances when a customer cancels?
- Future scheduled days should be skipped and removed from production and manifests, while delivered and failed days, their proof of delivery and any invoices remain untouched as historical record.
- How does this interact with a cut-off?
- The cut-off is what makes a generated instance real. Before it, the instance is still editable by the customer; after it, purchasing and production have committed to it and changes move to the next open week.
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
- SolutionsMeal subscription software and the lifecycle it has to modelSubscription 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.
- 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.
- 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 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.