Menu Engineering and Profitability Analytics for a Bengaluru Cloud Kitchen

Menu Engineering and Profitability Analytics is a records-based dissertation built around Vayu Kitchens, a fictionalised but realistic 34-item cloud kitchen in HSR Layout, Bengaluru that sells through two aggregator platforms and direct WhatsApp orders. Cloud kitchens live and die on a menu they rarely examine: dishes survive because the chef likes cooking them or because one week was busy, aggregator commissions silently eat 20–25% of every order, and discounts are handed out by platform campaigns nobody costed. The owner's question was blunt — which dishes should stay, which should go, and what should the menu actually push?

For my Bangalore University MBA dissertation (Semester 4), I analysed 26 weeks of order-level records — about 28,000 orders — together with the kitchen's ingredient cost sheet. Contribution margin per dish was rebuilt in Excel; the menu was classified on the classic Kasavana–Smith matrix (popularity × contribution margin → Stars, Plough-horses, Puzzles, Dogs); basket analysis (Apriori association rules in R's arules), k-means order segmentation and an OLS regression of order value were run in R with pre-processing in Python/pandas; and every result was validated on a holdout month and across time windows before being written up. The deliverables are a pruned and re-priced menu, three evidence-backed combo proposals, a discount policy, and a Tableau dashboard the owner can refresh weekly.

Vayu Kitchens prices and promotes 34 dishes with no per-dish profitability picture. Aggregator commissions and discounts are netted into a single revenue line, ingredient costs live in a rough cost sheet, and no one can say which dishes make money, which merely fill the stove, and which lose money on every order. Combos are designed by platform defaults rather than by basket evidence, discount depth is decided by aggregator campaigns, and the menu keeps growing because removal feels like admitting failure.

There is a need for a quantified menu-engineering study — rebuilding realised contribution margin per dish from orders and the cost sheet, classifying the menu on popularity and margin, mining real basket patterns for combos, and validating every claim on holdout data — so that the owner can prune, reprice and re-promote the menu on evidence, with a dashboard that keeps the answers current.

Abstract

Cloud kitchens compete on a menu they almost never measure. This dissertation applies menu engineering and retail-style analytics to a Bengaluru cloud kitchen's 26 weeks of order records and its ingredient cost sheet, classifying all 34 dishes by popularity and contribution margin, mining co-purchase patterns for combo design, and modelling order-value drivers. Validated in R, Excel and Tableau, the study ends in a pruned menu, re-priced SKUs, three combos and a discount policy with projected monthly impact.

Introduction

Vayu Kitchens (fictionalised) operates from one HSR Layout prep kitchen: 34 items spanning South Indian meals, dosas, Indo-Chinese and beverages, sold via two aggregator apps and direct WhatsApp orders. The owner works 16-hour days but decisions about the menu are folklore — the best-selling dish is assumed, the least profitable one is unknown, and the aggregator's discount campaigns are accepted because refusing them risks ranking. The kitchen has data: every order, every item, every discount, every commission. What it lacks is analysis.

Existing practice and literature gap

• Dishes are added on instinct and rarely removed; the menu has grown from 22 to 34 items in two years.
• Discounts and platform commissions are booked as one sales figure, so the realised margin per dish is invisible.
• Combo offers exist because platforms suggest them, not because basket data supports specific pairings.
• Menu engineering (Kasavana & Smith) is a four-decade-old, well-proven framework, but it is usually taught on restaurant case data; applying it with association rules and clustering on Indian cloud-kitchen order records — where aggregator commissions and free-delivery thresholds distort both price and basket — is under-explored in MBA dissertation work.
• Gap: a validated, low-cost analytics workflow that a one-kitchen owner can actually re-run.

Proposed study

• Margin rebuild (Excel): per dish, realised price minus platform commission, ingredient cost from the kitchen's cost sheet, and packaging — a contribution margin the owner has never seen per item.
• Menu matrix: classify 34 dishes by popularity (above/below median units) and margin (above/below weighted average) into Stars, Plough-horses, Puzzles and Dogs.
• Basket and segments (R): Apriori rules with support, confidence and lift to find genuine co-purchase patterns; k-means segmentation of orders by basket value, item count and daypart.
• Order-value regression (R): OLS on order value with daypart, weekend, discount depth, platform and item-count; validated on a held-out final month with RMSE, VIF checks and residual plots.
• Validation: rule stability across three bimonthly windows; menu-matrix sensitivity to ±10% ingredient-cost shifts.
• Decision layer: prune, reprice, combo and discount recommendations, plus a Tableau dashboard.

Feasibility

• Technical: order exports are CSVs; R, Excel and Tableau are free or already licensed; no new systems needed at the kitchen.
• Economic: the study costs nothing but time; recommendations save money by deletion, not investment.
• Operational: menu pruning requires no capital — a redesigned aggregator menu card and two removals per category are changes the owner can execute in a week.

In scope

• One cloud kitchen, 34 menu items, 26 weeks of order-level records (~28,000 orders) across two aggregator platforms and direct WhatsApp orders.
• Per-dish contribution margin, menu-engineering classification, basket rules, order segmentation, order-value regression, validation, recommendations and dashboard.
• Interviews with the owner and the head cook to sanity-check cost-sheet entries and interpret results.

Out of scope

• Second kitchen or multi-brand operations; demand forecasting and inventory purchase planning.
• Customer-level analytics (platforms mask customer identity — appropriately, the study never attempts to de-anonymise).
• Nutrition, FSSAI compliance or kitchen-process redesign; dynamic pricing algorithms.

This is a quantitative, records-based, applied-analytics dissertation following the analyse–validate–recommend sequence. Data pre-processing in Python (pandas); margin and matrix computation in Excel; statistical work in R (dplyr, arules, stats, ggplot2); visualisation in Tableau. The Kasavana–Smith matrix provides the decision framework; association-rule mining and regression provide the evidence beneath it.

Ethics and data care: a signed data-use agreement with the owner; no customer names, phone numbers or addresses are extracted from platform exports; order IDs are pseudonymised at import; dish-level margins are commercial confidential and the dissertation reports them only in relative terms; the kitchen's name is fictionalised in publication.

The dissertation is organised as a pipeline from raw exports to a decision pack, with validation gates before anything reaches the recommendation layer.

flowchart TD
  A["Platform + WhatsApp order exports<br/>26 weeks, ~28,000 orders"] --> B["Python pandas: clean,<br/>flatten to order-item rows"]
  C["Ingredient cost sheet<br/>(verified with head cook)"] --> D["Excel: contribution margin per dish<br/>price - commission - cost - packaging"]
  B --> D
  B --> E["R: Apriori basket rules<br/>support, confidence, lift"]
  B --> F["R: k-means order segments<br/>basket value, items, daypart"]
  B --> G["R: OLS order-value model<br/>daypart, weekend, discount, platform"]
  D --> H{"Validation gates:<br/>holdout month, rule stability,<br/>cost sensitivity"}
  E --> H
  F --> H
  G --> H
  H --> I["Decision pack: prune, reprice,<br/>combos, discount policy"]
  I --> J["Tableau dashboard +<br/>managerial recommendations"]

The analytical heart is the Kasavana–Smith classification, which places every dish in one of four boxes and each box carries a distinct action:

flowchart TD
  Q1{"Units sold above<br/>median popularity?"}
  Q1 -->|"Yes"| Q2{"Contribution margin above<br/>weighted average?"}
  Q1 -->|"No"| Q3{"Contribution margin above<br/>weighted average?"}
  Q2 -->|"Yes"| ST["STAR — protect price,<br/>feature at top of menu"]
  Q2 -->|"No"| PH["PLOUGH-HORSE — reprice or<br/>re-engineer cost, keep volume"]
  Q3 -->|"Yes"| PU["PUZZLE — reposition, rename,<br/>bundle into combos"]
  Q3 -->|"No"| DO["DOG — drop or replace,<br/>after one promo test"]

Two design choices deserve the viva's attention. First, commissions and discounts are reconstructed per order rather than accepted as net revenue — otherwise the matrix ranks dishes by how much the platforms subsidised them. Second, every menu-matrix label must survive a ±10% ingredient-cost shock; a dish that flips from Star to Dog when onion prices move is reported as volatile, not as a Star.

• A demand-forecasting layer per dish (the regression groundwork is already laid) so prep quantities and ingredient purchasing follow the pruned menu.
• Dynamic discount testing: A/B the proposed discount policy across platforms and measure realised margin, not order count.
• A second-kitchen replication to test whether the stable association rules transfer across locations and cuisines.
• Price-elasticity estimation per category using the kitchen's own discount history, upgrading re-pricing from margin arithmetic to demand-aware pricing.
• Weekly automated refresh of the dashboard from platform exports, with threshold alerts when a Star dish's margin slips below its volatility band.