Guides
When a customer changes their dietary requirements mid-plan
A dietary change arriving mid-term is unlike any other amendment, because it retroactively invalidates choices that have already been made — including meals that are already frozen for production.
It is three problems arriving together
First, a safety problem: meals already selected for future weeks may now contain something the customer reacts to, and nobody has re-checked them. Second, a selection problem: the customer needs to choose again, possibly from a smaller set. Third, a production problem, if any affected day has already passed its cut-off.
Most operations handle the first by memory and the second by message, and discover the third on the morning it matters. All three are foreseeable and each has a defined right answer.
The order to work through it
Update the structured record first
Before anything else, so every subsequent check runs against the new reality rather than the old one.
Re-check every future assignment
Not only the next delivery. Any already-selected meal in any future week has to be revalidated, and this is exactly the check a human will not perform reliably.
Deal with frozen days explicitly
If an affected day is past its cut-off, decide and tell the customer: substitute if you can, or omit and credit. Silently delivering it is the one unacceptable option.
Re-open selection for affected weeks
With the newly unavailable dishes filtered out rather than left visible to be chosen again.
Confirm in writing
What changed, from when, and what happens to anything already committed.
Severity should change the handling
A customer who has decided to reduce dairy and a customer who has been diagnosed with a serious allergy have made the same shaped request and require very different responses. Storing both in one field guarantees they get the same treatment, which means either over-reacting to preferences or under-reacting to allergies.
Separating severity in the data is what lets the system be loud about one and quiet about the other, and it is the difference between warnings that get read and warnings that get dismissed.
The frozen-day decision is a policy, not a case
Decide once what happens when a dietary change affects a day already committed to production. Substitute where a suitable dish exists, omit and credit where it does not — but pick a rule and apply it identically.
Handled case by case, this becomes an argument each time, and staff under time pressure will occasionally choose the option that sends the meal. That is the one outcome that must never be available, which is a good reason to remove it from the decision entirely.
Common questions
- What should happen to meals already selected for future weeks?
- Every one has to be re-checked against the new dietary record, not just the next delivery. This is precisely the check a person will not perform reliably across several weeks of selections.
- What if an affected day is already past the cut-off?
- Substitute if a suitable dish exists, otherwise omit and credit. Decide the rule once rather than case by case, because under time pressure the case-by-case answer occasionally becomes "send it anyway".
- Should preferences and allergies be stored the same way?
- No. Storing both in one field means they get the same treatment, so you either over-react to dislikes or under-react to allergies. Separating severity is what makes a warning worth reading.
- Who should be able to update the dietary record?
- The customer, with the change taking effect on future assignments immediately. A record only the office can edit goes stale, and in this particular field stale data is the dangerous kind.
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.
Related reading
- SolutionsAllergen management software for meal businessesEvery other field in a meal-plan system can be wrong and cost you money. This one can be wrong and cost someone a hospital visit, which is why it deserves different treatment from the rest of the customer record.
- GuidesAllergen management in a meal-prep kitchenAllergen handling is the one part of a meal-plan operation where a data-entry problem becomes a medical one. It deserves a different standard of care from the rest of the customer record.
- SolutionsCustomer self-service for meal plansEvery routine change a customer cannot make themselves becomes a message someone has to read, interpret and apply correctly before a cut-off. That workload grows with your customer count, not with your feature list.
- GuidesWhat to collect when a meal plan customer signs upEvery field you skip at signup becomes either a chase later or a guess. Two of them, added late, mean re-contacting your entire customer base.
- SolutionsSoftware for nutritionists and diet clinicsIn a clinic-led meal plan the person eating the food did not choose it. A professional did, for a reason, and that inverts the permission model most meal-plan software assumes.