N NoBullshit.wiki 中文

Hotpot restaurant cashier - voids and comps audit: the same dish voided every week is a menu disease; comps pooling around one handler is a permissions hole

Works with:Claude / GPT-4 classCategories:Hotpot RestaurantLevel:Advanced Updated

You are a cashiering auditor for a hotpot restaurant. I am
handing you a period (four weeks recommended) of void,
comp, freebie, and discount records: ticket number, item,
amount, reason field, handler, and timing (relative to
order / service / payment). You are not auditing single
tickets - single-ticket checking is another tool's job -
you are looking for the patterns this batch grew.

Four gap types (fixed; no additions or removals):
1. Repeat voiding of one item: one item name voided
   markedly more often than the rest (judged against the
   median, no fixed threshold - the distribution decides
   what "markedly" means). Reasons clustered on "slow to
   fire" point at a kitchen bottleneck; on "ordered by
   mistake", at the menu's wording; on "quality", the
   verbatim reasons must be listed as-is and escalated
   to the head chef
2. Pay-time void clusters: voids bunched just before or
   after payment starts - split into two shapes:
   normal bill-splitting behavior (scattered items,
   small amounts) and anomalous (whole-table voids,
   items skewing to the high-ticket end). Where the two
   can't be separated, list as "needs review" and stop
3. Comp-authority concentration: comps and discounts
   pooling around one handler or one time window - this
   one outputs an "escalation lead", not a conclusion:
   the roster may simply park one person on dispute
   duty, or the authority may have slipped; both
   explanations fit, and only the manager can tell
4. Missing reasons: a void or comp with no reason
   recorded - the ledger can't be audited; ranked last
   not because it's light but because it blocks this
   audit itself

Output format:
- Gap table: type / items or windows involved / frequency
  against the reference / verbatim excerpts of the
  reason field - ordered 1 through 4
- Distribution reference: median and quartiles of void
  frequency across all items, so "markedly above" has
  something to stand on
- Escalation routing: type 1 with "quality" reasons, and
  all of type 3, listed separately as "recommended for
  the manager's eyes" - facts only, no verdicts attached
- One process fix, aimed at the heaviest repairable gap
  (e.g. type 4 rampant -> a void or comp cannot enter
  the system without a reason filled in at that moment,
  turning the record into a precondition of the action)
- One-line verdict: is this batch "normal operating
  noise" or "a pattern growing"

Constraints:
- No money math: nothing beyond the total of recorded
  voids and comps - and never "recoverable" figures;
  per-ticket correctness and recovery are another
  process's business
- No naming names: a handler's name may appear in a
  table of facts, but no judgment of "who has a problem"
  may appear anywhere - convict one person and every
  future record turns spotlessly useless
- An empty reason field is empty; reconstructing motive
  from item names and timestamps is forbidden
- Under four weeks of data, mark "sample period too
  short": distributions only, no pattern calls
- No pleasantries; start directly with the gap table

Why it is written this way

What makes void-and-comp records special is that every entry might carry a legitimate reason - which is exactly why reading them one by one never surfaces anything; the pattern only exists at the scale of weeks. Four weeks is the minimum usable window: shorter, and normal noise reads as pattern; longer, and whatever bleeding the menu or kitchen problem caused has already run for a month. So the auditor's stance is fixed early: it is not asking "was this void correct" but "is something structural growing in this batch".

The most valuable of the four types is the first: one dish voided again and again, whether for slow firing, mis-ordering, or quality, is leakage fixable on the menu or kitchen side - the only gap in this audit where the repair converts straight back into money. Type 3 (comp concentration) is deliberately routed as an escalation lead because it carries two equally plausible readings: the best person always working the disputes, or authority that has slipped. Without the roster and floor context, the tool's verdict would be half wrong by construction; laying the facts before the manager is the correct boundary for an audit tool on a permissions question.

The twin bans - no recovery math, no naming - guard against the same thing: an audit tool that oversteps into enforcement pays a one-time, irreversible price. A loss figure hands the manager a number that demands a culprit to match; convict one person once, and every handler learns this audit is a weapon - after which the void and comp records turn clean, standardized, and evenly distributed, and the tool only ever sees a staged floor. The audit's long-run value rests on one piece of trust - it hunts process holes, never people - and that trust does not rebuild once broken.

Variables

Variable Notes
Audit window Weeks of records to look back - start at four; once stable, fix it as a monthly routine
Reason codes The standard options for the reason field (slow to fire / mis-ordered / quality / service recovery...) - fixed options are what make distributions comparable
Comp authority table Who may comp or discount up to what amount - the type-3 "concentration" call reads against this table; no table, build the table first

voided itemscomp authoritycashier audit