Bubble tea delivery menu relaunch checklist - SKU count capped by what the bar can actually produce, hero prices parked near the discount threshold, set combos locked (no build-your-own), allergens in every description; six fixed blocks, the model only ticks boxes and ranks fixes

You are a delivery operations consultant for a bubble
tea shop. I am relaunching the delivery menu. The six
blocks of standards below are fixed - check my menu
data against them item by item and output the tick
results plus a fix order. Do not modify the standards
and do not invent a seventh block.

Inputs I will provide:
- Live SKU list with prices and description text
- Current threshold-discount rules and minimum order
  amount
- How many drink types my bar can produce in parallel
  at peak (measured on this store's layout)
- Combo list if any, and how each combo's pairings
  work
- Hero drinks and their share of daily cup volume

Six blocks (tick every SKU or setting against each):

1. SKU count: live SKUs <= parallel-production count
   x 2; every live item explainable to a new hire in
   one sentence of preparation difference
   - If failed: rush-hour drink times blow past
     target, delivery and in-store drag each other
     down

2. Pricing and threshold anchor: hero drinks priced
   from 1 below to 2 above the discount threshold;
   one uniform rule for delivery-versus-store pricing
   (same price, or a flat markup - never mixed)
   - If failed: the threshold either cannot be
     reached or gets exploited by large stacked orders

3. Combo structure: combos <= one third of total SKUs;
   pairings locked, no build-your-own; the saving
   versus ordering separately statable in one
   sentence
   - If failed: open combos are error machines at
     peak; wrong-drink complaints cost more than the
     combo adds to the ticket

4. Description completeness: dairy and nut topping
   allergens written into every item's description;
   customization options (sugar / ice / base swap)
   listed item by item
   - If failed: allergen and wrong-order complaints
     land on the delivery channel, refunds a notch
     higher

5. Stock-out linkage: who owns marking an item out of
   stock, the maximum time from stock-out to app
   delisting, and who cancels and compensates if an
   order slips through anyway
   - If failed: accept-then-cancel orders, platform
     penalties and customer rage in one package

6. Minimum order versus hero price: the cheapest
   single-drink order must not fall too far below the
   minimum (I give the ratio), and the minimum must
   not be so high it blocks single-drink customers
   - If failed: the minimum is decorative, or it eats
     the order count

Output:
- Tick sheet: block / check item / which SKUs or
  settings it touches / pass | fail | cannot verify
- Fix list: failures ranked by what complaint or loss
  they invite, each with one concrete change (delete
  which SKU, move which price, rewrite which
  description), tagged "fix before launch" or "fix
  within week one"
- "Cannot verify" items listed separately: what I
  need to pull from the backend or check in store

Constraints:
- No platform ranking or weighting algorithm lore -
  do not write what neither of us knows
- "Optimize the menu structure" / "raise the average
  ticket" - anything without a tickable standard is
  banned
- The checklist covers the menu only. Order brushing
  and paid-traffic topics are out of scope: drop them
- Anything I did not provide gets "cannot verify" -
  never fill in a default from what shops "usually"
  do

Why it is written this way

Baking every standard into the prompt and letting the model only tick and rank is the defining trade-off of the checklist form. Ask a model to "design a delivery menu checklist" and it will write standards like "the menu should be clean and focused" - true, and impossible to tick. A checklist earns its keep only when every standard is binary: pass, or fail. The SKU cap is not a round "keep it under 30" but "parallel-production count x 2," derived from this store's bar lane, because bar capacity is the real constraint - a number copied from another shop just hides your own slowness inside your menu.

Parking hero prices next to the threshold (1 below to 2 above) is the most mechanically valuable rule in this trade: a hero priced just under the threshold pushes customers to add a topping to cross it; just above, they hesitate over whether to pad the order. Both ends lead to ticket size and promo efficiency, but only a concrete price band makes it checkable - which is why it lives in the standards, not in "suggestions."

Locked combos and allergen-in-description correspond to the two most expensive delivery accidents. Build-your-own combos push the choosing onto a bar at peak, and one wrong-drink complaint costs more than the combo ever added to the ticket; a missing allergen line is a refund plus a review plus occasionally far worse, which is why it is a per-item tick rather than a general reminder. The separate "cannot verify" bucket and the ban on defaults keep the audit itself from becoming the place where data gets invented.

Variables