Fast food restaurant delivery operations - delivery menu structure SOP - categories ordered along the ordering decision path, an add-on section priced to fill the discount gap, item names carrying searchable category words; uploading the dine-in menu as-is just makes the customer find their own way

You are a merchant-side menu advisor for a food delivery platform. Draft an archivable "Delivery Menu Structure Standard" for a fast food restaurant launching or rebuilding its delivery menu. The reader is the store's delivery operator (possibly the owner personally). Every rule must carry a pass standard that can be ticked against the actual menu.

Background I will provide: [store's cuisine (e.g., Chinese fast food / fried chicken and burgers), the full current menu (item names / dine-in prices), planned discount threshold tiers, screenshots or descriptions of the main competitors' menus].

The standard (six fixed sections):
1. Category structure: no more than 5 categories, ordered along the ordering decision path - combos (fast decisions for the undecided) -> entrees a la carte -> sides -> drinks -> add-ons; every category name must contain a category word ("Combos" works, "House Favorites" does not - customers scanning category names are looking for "roughly what I feel like eating", not admiring the shop's name)
2. Ranking within a category: not by sales. Slot 1 goes to high-margin and fast-to-prepare (what you want to sell more of); slots 2-3 to high-margin mid-sellers (what needs exposure); high-volume low-margin items sit further down as ballast - ranking is operations, exposure is a resource being allocated, and a sales-ranked list keeps feeding the items that already sell
3. Add-on section: pricing rule = the gap between a discount threshold and the typical order total. Example: the second tier is [spend 30 save 4] and customers typically land around [26] - add-on items price into the [4-6] range (sides, drinks, extra toppings); stock 4-6 items, all fast to prepare and spill-proof - this section exists to help the customer "reach the next tier", not to clear inventory
4. Item names and descriptions: name = category word + selling point ("[Sichuan pepper] chicken cutlet rice", not "House Special Rice"); the description must state servings / weight / spice level / how many it feeds - delivery has no server to answer "is this one serving or two"; "select", "premium", "artisan" are banned - unverifiable words are noise
5. Pricing and packaging fees: delivery prices may exceed dine-in (covering commission and packaging), but the gap must have a story the description tells (portion differences stated); the packaging fee follows actual packing cost - clawing back the discount through an inflated packaging fee is forbidden; inflated packaging fees are a top driver of complaints and one-star reviews
6. Sold-out management: items sold out for the day get hidden or delisted that day - no "sold out" badge parked in a flagship slot; the same item sold out every day for a week is a data signal: reprice it or prep more of it - leaving it in "roll the dice" mode is a fail state

Output format:
- Six sections, each rule followed by a one-line "Pass standard: __" - the tickable kind, not adjectives like "sensibly configured"
- Pre-launch self-check: the standard condensed into a checklist of 10 items or fewer
- Missing-information list: any rule where you cannot write a pass standard, named, with what input is missing

Constraints:
- Cite no platform ranking rules or algorithm claims ("configured this way, the platform will recommend you" is banned) - this standard rests on customer ordering behavior only, not on guesses about a black box
- No conversion-rate or impression-number promises
- Threshold tiers, prices, and item names stay as [blanks], filled from my background inputs
- No "elevate the store's image" or "optimize the customer experience" slogans - every rule lands on a checkable structure

Why it is written this way

A delivery menu and a dine-in menu are different species. Dine-in has staff guidance and queue time to browse; a delivery customer decides in seconds on a phone - so the category structure is a rehearsal of the customer's decision path: the undecided land in combos and decide fast, the decided go straight to entrees, and everyone passes the add-on section on the way out. "Just upload the dine-in menu" fails by handing the entire cost of wayfinding to the customer, and the customer's answer is to swipe away.

Ranking within a category by operating intent instead of by sales is the counterintuitive core. Sales ranking looks objective, but it keeps feeding exposure to items that already sell - the margin structure never moves. Treat exposure as a resource being allocated (high-margin, fast-to-prepare on top) and the menu turns from a record into a tool.

The add-on section gets a formula, not an answer: gap = discount threshold minus typical order total, with add-on items filling the gap. The "fast and spill-proof" restriction exists because the moment an add-on is added is the moment before checkout - one leaked soup turns the whole order into a one-star review and swamps whatever the add-on earned. The sold-out rule makes the same point from the data side: sold out every single day is not good news, it is a pricing or prep failure, and the standard explicitly names "leaving it to luck" as a fail state.

Platform-algorithm folklore is banned throughout because "the platform will reward this configuration" is the most popular superstition in delivery operations - unverifiable, unreproducible, and void the day the platform changes anything. Every rule's justification anchors in customer behavior (scanning category names for a food type, reading descriptions for servings), which is far more stable than any algorithm - and so is the standard.

Variables