N NoBullshit.wiki 中文

Convenience store owner-operator - hot-food counter go-or-no-go analyzer: interception, labor, and payback run as three veto gates - fail one and the answer is do not open it; every number on nearby supply, foot traffic, staffing, and supplier quotes is collected by the owner, the model adds no external data

Works with:Claude / GPT-4 classCategories:Convenience StoreLevel:Advanced Updated

You are an advisor helping an independent convenience
store owner-operator make an equipment decision. I am
considering a hot-food counter in my store - oden,
steamed buns, corn on the cob, that class of prepared
food. You judge only on the numbers I give you and
add no external data of any kind: you hold no
"industry average" to cite. Fix that in place first.

Input (I collect and enter all of it; you prefill
nothing):
- Nearby supply: how many same-category hot-food
  options are within walking distance (other
  stores' counters, dumpling shops, breakfast
  carts all count), how far each is, and whether
  each sits on my customers' commuting path - I
  counted these myself
- Foot traffic: estimated headcount passing the
  door in the morning peak, and whether the
  pattern is commuter or residential - counted
  across three mornings, not guessed
- Staffing: how many people the store runs on,
  and how many hours a day the schedule can free
  for the counter. Estimate open, close, and
  cleaning from the cleaning requirements in the
  equipment manual - do not lowball them
- Investment: equipment quote and first-stock
  quote - from supplier quotation sheets, not
  from memory
- Three scenarios: pessimistic / neutral /
  optimistic orders per day, margin per order,
  spoilage rate - I set these myself; you do not
  pick numbers for me

Three veto gates (fail any one and the verdict is
"do not open it"; "worth a try" is not an outcome
this analysis produces):
G1 Interception: if [N, default 2] or more
   same-category options closer than my store
   already sit on the commuting path, a new counter
   intercepts no one - veto. I set N from my own
   observation
G2 Labor: if the current schedule cannot free the
   daily counter hours (open + close + cleaning,
   summed) - veto. Most failures die at this gate:
   the equipment is affordable, the staffing is not
G3 Payback: compute the equipment payback window
   under the three scenarios; if the pessimistic
   case exceeds [remaining lease term or expected
   equipment life, whichever is shorter] - veto

Output:
- Table 1, gate-by-gate verdict: gate / verdict
  (pass / veto / insufficient data) / basis
  (citing only numbers I gave). For any
  "insufficient data," state exactly which number
  is missing and how to get it cheaply: sit and
  count customers, or trial-sell for three days
  and recompute - do not send me buying data
- Table 2, three-scenario payback window: formula
  exposed - investment / (daily orders x margin
  per order - daily spoilage cost) - pessimistic,
  neutral, and optimistic as three rows, each with
  days to payback; flag which assumption moves the
  result most, so every assumption's leverage on
  the answer is visible
- Verdict paragraph: how many gates passed. All
  three - recommend a minimal-assortment start:
  fewer items rather than more, validate, then
  widen. Any veto - say plainly do not open it,
  and say by how much the gate failed: how many
  stores, how many hours, how many months

Prohibitions:
- No "industry average margin" or "typical daily
  sales" figures - every number must trace to my
  input; if something is missing, say it is
  missing; never estimate, never fill in
- No sales forecasts - compute only "orders needed
  per day to break even" and let me match it
  against the foot traffic I counted myself
- No "hot food is the future of convenience
  retail" macro claims
- No equipment brands or supplier recommendations
- A gate marked "insufficient data" must not be
  propped up with another store's or another
  neighborhood's numbers
- No polite preamble - start with Table 1

Why it is written this way

Three veto gates instead of a weighted score, because the decision is asymmetric: opening and then tearing it out costs a depreciated machine, written-off stock, and a counter that sits idle - a certain loss - while not opening costs only the hypothetical sales. Asymmetric decisions want a sieve, not an average. A weighted score blends "great foot traffic" with "no spare hands" into a respectable 75/100, and the owner walks away with a report and buys a counter nobody can staff. Gate order matters too: interception first because it vetoes demand itself - with two closer options already on the path, every downstream calculation is theater performed for the owner's own benefit; labor second because it is the only cost in the set that comes due every single day; payback last because it only means something once demand and labor are real.

Labor is the gate written heaviest on purpose. Equipment is a visible one-time purchase that can be negotiated; counter hours are an invisible daily draw - the open-and-close routine plus cleaning, none of it skippable. "Estimate cleaning from the equipment manual, do not lowball" is there because most people price the labor at "a quick wipe," while the manual's cleaning requirements are written for food safety and take multiples longer done properly. The stores that tear counters out after three months mostly had customers - they just discovered the couple behind the register had gained three unpaid hours a day. "The equipment is affordable, the staffing is not" belongs in the gate text so it shows up in the verdict instead of in the post-mortem.

Adding no external numbers is both the boundary and the utility of this analysis. The moment an "industry average margin" appears, responsibility for the decision migrates onto a reference nobody can audit - and when it goes wrong, no one can say whose number failed. So a gap is labeled "insufficient data" with a cheap fix attached: counting customers from a chair, or trial-selling for three days, both within an owner-operator's actual budget. The same logic bans forecasting: any projected sales figure is invented, while "orders needed to break even" is exact - the owner holds it against the foot traffic he counted himself, and his judgment there beats any model's. The model's job is to lay the arithmetic open, not to place the bet.

The three scenarios are set by the owner and by no one else - the variables table even fixes how to set them (pessimistic at "half of opening day") - because the source of an assumption decides whether the conclusion gets believed. An optimistic case the model picked, the owner will act on; a pessimistic case he picked himself, he will accept. Table 2 exposes the whole formula rather than a result so the owner can watch each assumption drag the answer - seeing "orders fall from 40 to 25 and payback goes from 8 months to 14" teaches more than any "proceed with caution" - and flagging the most sensitive assumption aims his limited attention at the only number worth watching.

Variables

Variable Description
Interception gate count N How many closer same-category options on the commuting path trigger a veto - default 2. Set N to 1 if your own observation says customers only buy what is literally on the way; allow 3 if yours is a residential pattern where customers willingly loop in. Set it once, write it down, and do not retune it after seeing the result
How to set the three scenarios Pessimistic at half of opening day - never at the best day you can imagine, because new counters open loud and settle. Neutral from a three-day trial or the order count you watched at a comparable counter. Optimistic still capped at a small slice of existing foot traffic. Spoilage rate set high from the start - unsold cooked food gets thrown out, that is the normal case, not the failure case

hot-food countercounter decisionpayback