← All playbooks
Operations14 July 2026 · 6 min read

Fallback rules explained: what happens to a subscriber who never picks their meals

Priya Iyer
Operator at MealDispatch

Every tiffin operator has them. The subscriber who signed up six months ago, receives their meals faithfully every week, and has never once opened the selection page. Not a single pick. Saturday 10 PM passes and they have not tapped a single meal.

This is not a hypothetical. Operators we work with in Delhi NCR consistently see a meaningful share of their subscriber base fall into this silent category at any given week. Some are travelling. Some trust you to send what you sent last week. Some simply forgot. The question is not whether silent subscribers exist — they always will. The question is what your system does about them at cutoff.

The fallback rule is a retention decision, not just a logistics one. Most operators treat it as a last-resort default — something the system needs to fill in an empty slot. The smarter way to think about it: the fallback rule is your promise to a subscriber who didn't show up. Get it wrong and you lose them quietly, not loudly.

MealDispatch offers three fallback modes, each suited to a different subscriber type. The mistake is picking one and applying it uniformly across your entire base.

Repeat-last-week sends the subscriber the same meals they received the previous week. This works beautifully for subscribers with stable preferences — a Jain family who always wants no-onion no-garlic, a solo professional who found two meals they like and sticks to them, a corporate bulk account ordering the same office lunch every week. The failure mode is a subscriber who last week received a special Diwali thali. Repeat-last-week sends the Diwali thali for three consecutive Mondays. The subscriber calls to complain. The operator is confused.

Chef's pick lets you slot in the meals you choose — typically from your current week's menu, weighted towards what you need to move. This suits adventurous subscribers who have said, in some form, "surprise me." It also works for operators who want to manage inventory by nudging silent subscribers towards the higher-volume dishes. The failure mode is a subscriber who happens to have a dietary restriction you haven't tagged. A chef's pick that lands a meat dish with a quietly-vegetarian subscriber creates a support ticket and a trust problem.

Skip means no delivery that week for the silent subscriber. They are not billed, nothing is packed, no driver goes to their door. This is the right choice for price-sensitive subscribers who would genuinely rather miss a week than receive something they didn't consciously choose. The failure mode is operational: if a large share of your subscriber base is set to skip, your prep-quantity planning becomes unreliable. Kitchens that use skip broadly find their Monday prep is chaotic — they cannot confidently batch until the last silent subscriber resolves.

The right answer is per-subscriber segmentation. MealDispatch lets you set the fallback rule at the subscriber level, not just at the plan level. This matters more than most operators realise.

A practical segmentation that works in Delhi NCR: Jain or vegan subscribers get repeat-last-week by default — if they have tagged dietary requirements, sending chef's pick is a liability. Corporate accounts get repeat-last-week — they want the same reliable meal for the office floor every week, and inconsistency creates complaints from the HR contact. New subscribers (first 8 weeks) get chef's pick — they are still learning what they like, and the best way to keep them engaged is to show them variety they did not know they wanted. Subscribers who have explicitly skipped more than twice in a season get the skip fallback — they are telling you they are occasional users, not daily-plan users.

The moment that exposes a bad fallback rule is Monday morning, not Saturday night. Operators find out something is wrong when the delivery rider calls from a subscriber's building — "didi, unhone bolya yeh meal nahi chahiye tha." By then the tiffin is packed, the rider is at the gate, and the next 12 stops are waiting. There is no fix at that point. The fallback rule was either right or it wasn't.

This is why the rule matters before cutoff, not after. MealDispatch's cutoff automation auto-locks selections at your configured time, applies the per-subscriber fallback rule for anyone who hasn't picked, and generates the prep sheet and pick-list from the resolved orders. The prep sheet your cook receives on Sunday night already reflects the fallback — there is no manual reconciliation.

One practice that smooths silent-subscriber management: look at the fallback report weekly, not just when something goes wrong. MealDispatch's operator dashboard shows you week-by-week which subscribers triggered the fallback rule and which fallback applied. A subscriber who has triggered fallback four weeks running is either very satisfied (keep them on repeat-last-week) or quietly drifting (consider a personal check-in via WhatsApp). The dashboard tells you which it is.

Operators who treat the fallback rule as a set-and-forget default tend to see gradual unexplained churn — subscribers who stop their plans without a clear complaint. Operators who segment the fallback rule by subscriber type and review the fallback report weekly retain those same subscribers, because the meal that arrives is either exactly what they expected or exactly the right surprise.

The silent subscriber is not a problem to solve. They are a relationship to maintain with the right default.

If you want to walk through how to configure fallback rules for your subscriber base and connect them to your cutoff settings, book a demo with the MealDispatch team. We cover this in the first onboarding session for every Delhi NCR kitchen.

Limited Delhi pilot

Stop chasing weekly orders on WhatsApp.

We're onboarding the first 25 Delhi NCR kitchens with white-glove setup, free for the first 3 months. Pay only when you're saving time.

Chat on WhatsApp