Guides

How to manage meal-plan pauses and skips

Pausing is the most common request a meal-plan business receives and the one most often handled badly — usually because it is treated as a note rather than as a state change with consequences.

A pause and a skip are not the same thing

A skip removes one delivery. A pause removes every delivery until a stated date or until the customer resumes. Collapsing them into one action forces customers into the heavier option, which costs you more production and more revenue than the request required.

Keeping them distinct also improves your data. A customer who skips occasionally is behaving normally; a customer who pauses repeatedly for long stretches is telling you something about fit, and you cannot see the difference if both look the same in the record.

What a pause has to do

If any of these steps is manual, the pause is only partly real.

  1. Change the state

    Record the pause on the subscription itself with a start, an optional end, and who made the change.

  2. Skip the future days

    Every scheduled delivery inside the paused window becomes skipped — not deleted, so the history stays legible.

  3. Reduce production

    Aggregate counts for those days drop, because they are derived from the same selections.

  4. Recompute purchasing

    Ingredient requirements fall with the counts, or you buy food for meals nobody ordered.

  5. Clear the stops

    The delivery manifest for those days no longer contains the customer, so no driver carries a box to an empty flat.

The cut-off decides whether a pause is free

Before the cut-off, a pause costs nothing but a recalculation. After it, the food is bought and often cooked, and honouring the request means absorbing the loss.

The workable answer is to publish the rule and enforce it in software rather than case by case. Customers accept a clear boundary; what they object to is a boundary that appears to move depending on who answers the message.

Why making pausing hard backfires

Some operators deliberately make pausing awkward, reasoning that friction protects revenue. In practice the customer’s alternative is not to continue paying — it is to cancel, because cancelling is always available.

A paused customer keeps their plan, their preferences and their history, and resumes with no acquisition cost. That is a materially better outcome than a cancellation, and it is worth designing for.

Common questions

Should a pause extend the subscription term?
Either rule works commercially, as long as it is stated up front and applied identically every time. Inconsistency here generates disputes that cost more in time and goodwill than the meals themselves were worth.
How far in advance should a customer be able to pause?
As far ahead as you generate delivery days, and at minimum past the current cut-off. Letting customers schedule a pause for a known trip removes a message they would otherwise send at the last minute.
What happens if a paused subscription reaches the end of its term?
It should still expire. A term that has run out does not become open-ended because the customer paused before it finished, and treating it otherwise inflates your active-customer numbers.

See how this works in practice

The home page walks through the same mechanics against a real admin loaded with a demonstration kitchen: production, packing, routes and the customer side.