Twelve Dishes Nobody Ordered Last Month
Pull your sales report and count the items with zero orders. A dish nobody orders is not free. It costs you prep, storage, waste and sales of everything else.

Open your POS. Pull last month's item wise sales report. Sort by quantity sold, ascending.
Now count the items with a zero next to them.
For most restaurants running a normal Indian menu, the number is somewhere between eight and twenty. Every one of those dishes is on your menu, in your prep list, in your stock count, in your staff training, and in your kitchen's head.
None of them made you a rupee.
Zero orders is not zero cost
This is the part operators get wrong, and it is worth being blunt about.
A dish that sells nothing is not neutral. It is not sitting quietly in a corner waiting for its moment. It is spending your money in six separate places every single week.
Ingredients you hold for it. Something has to be in the fridge in case somebody orders. That something has a shelf life.
Space. Fridge, freezer and dry store are finite, and in most Indian kitchens they are the tightest constraint in the building.
Prep. Mise en place gets made for the shift and binned at the end of it, quietly, by someone who has stopped mentioning it.
Stock counting. Every ingredient is a line on a count somebody does weekly. Multiply that by twelve dead dishes and you are paying for arithmetic that never resolves into revenue.
Training. Every new hire learns a dish nobody will ever ask them for.
Kitchen complexity. More items means slower tickets, more chance of error, and less consistency on the dishes that actually sell, because the line is holding more in its head than it needs to.
Here is the trap in its cleanest form. A dish nobody orders has exactly two possible states. Either you stock the ingredients and throw them away, or you do not stock them and you have to 86 it the one time somebody asks, which turns into a cancellation and a bad rating.
There is no third state where it is free.
The test that actually matters: which dead dishes own an ingredient
Standard menu engineering will tell you to plot everything into a matrix and cut the low profit, low popularity items, the ones the textbooks call Dogs. <cite index="47-1">Dogs are low profit and low popularity items that drain prep time and menu real estate, and can usually be removed without a single guest complaining</cite>.
That is fine advice and it is also not precise enough, because it treats every dead dish as equally expensive. They are not.
A dead dish that shares all its ingredients with your bestsellers costs you almost nothing to keep. Nothing spoils, because everything in it turns over on other dishes. It is a line on a menu and little more.
A dead dish that owns a unique ingredient costs you a whole supply chain. A purchase minimum you cannot use up. A shelf position. A weekly spoilage decision. A supplier line. A row on every stock count. And a guaranteed choice between waste and a stockout.
This works in the other direction too. Menu design guidance is consistent that <cite index="56-1">creating multiple dishes with common ingredients streamlines prep work, reduces waste and enables better volume discounts from suppliers</cite>.
So the audit worth doing is not "which dishes sold least." It is:
Which of my zero order dishes use an ingredient that no other dish uses?
Those are the expensive ones. That is a short list, usually three or four items, and cutting them recovers real money in a way that removing a dead dish sharing common ingredients simply does not.
The dead dish is also costing you sales
There is a second cost that never appears on any report.
Choice overload is a measured effect, not a feeling. In the classic experiment, showing people 24 options instead of 6 made them ten times less likely to choose anything at all.
Your twelve dead dishes are twelve things a hungry person scrolls past on the way to finding the three they would have loved. They do not just fail to sell. They make everything else harder to find, and a customer who cannot decide quickly retreats to whatever they ordered last time.
Cutting dead items is not only cost reduction. It is a conversion improvement on the items that remain.
The exception, because order count is a bad test on its own
Now the honest counterweight, because most menu engineering advice skips it and it matters.
Some items with almost no orders should absolutely stay.
The one Jain option. The one dish with no onion and no garlic. The one main a child will actually eat. The one properly vegetarian item on a heavily non vegetarian menu. The one thing a lactose intolerant guest can order.
Those dishes barely register in a sales report. They also decide bookings. A table of six where one person can eat nothing goes somewhere else entirely, and that lost order does not appear in any system you own. You will never see it. It looks exactly like a quiet Tuesday.
Even conventional menu engineering guidance makes room for this, noting that <cite index="45-1">before removing a low performing dish you should evaluate whether it serves a specific purpose, such as catering to a niche dietary preference</cite>, and that <cite index="46-1">items with low sales are worth keeping if they satisfy a niche need or have some specific importance</cite>.
So the test is two questions, not one. Did anyone order it? And does its absence cost you a table?
Cut the dishes that fail both.
What to do this week
1. Pull the report. Item wise sales, last 90 days rather than 30 so seasonality does not fool you. Sort ascending. Look at the bottom twenty.
2. Mark the ones that protect a booking. Dietary options, kids' items, the one thing your regular always orders. Set those aside and stop feeling bad about them.
3. For everything left, ask the ingredient question. Does this dish use anything nothing else uses? That short list is where your money is going.
4. Pull them, do not delete them. This is the part that changes with a digital menu. Removing an item used to be permanent and expensive, so it required certainty and an argument. Now it is reversible. Take the item off, watch for a fortnight, put it back if you were wrong. Menuthere lets you toggle items in and out instantly across your QR menu, ordering site, app and Google listing, so a menu decision becomes an experiment rather than a commitment.
5. Do this monthly, not annually. Twelve dead dishes did not appear at once. They accumulated, one chef's idea and one seasonal special at a time, because adding an item is easy and removing one requires somebody to decide.
The bottom line
Menus grow by default. Every new dish has a person advocating for it. Almost no dish has anyone arguing for its removal, so items arrive and never leave, and after three years you have eighty items of which sixty carry the business.
The twenty at the bottom are not harmless. They are consuming fridge space, prep time, stock counts, training and menu attention, and they are making your bestsellers harder to find.
The report takes two minutes to pull. Most owners have never sorted it ascending.
Make menu changes reversible. Menuthere lets you pull an item and restore it in seconds across every channel you run, so you can test a shorter menu without committing to one.
Sources: MyDigiMenu and NetSuite (menu engineering matrix and Dogs), Food Cost Chef and JWU Food & Beverage Financial Management (niche need exceptions), SupplyClub (common ingredients, prep and supplier effects), Iyengar and Lepper choice overload research.
