N NoBullshit.wiki 中文

Breakfast shop manager - the delivery-versus-counter capacity SOP: green/yellow/red states with quantified triggers for throttling delivery, pausing pre-orders, and bad-review proofing

Works with:Claude / GPT-4 classCategories:Breakfast ShopLevel:Intermediate Updated

Write an archivable SOP for my breakfast shop: "Delivery vs. counter
ticket priority during capacity conflict." It must be ready to post
at the kitchen and register as written.

Scope: weekday morning rush 6:30-9:00; counter and delivery platforms
share the steamer, griddle, and packing labor.

Master rule (one line, posted at the top):
Counter customers are walking away right now; delivery has a timeout
buffer - counter wins by default. EXCEPT: a delivery ticket within
[T] minutes of the platform's late penalty moves ahead of all
counter tickets.

Three capacity states (exactly three - inventing a fourth on the fly
is not allowed):

[GREEN - both lines fully open]
Trigger: queue at [A] or fewer, no core-item stockout, 2 or fewer
delivery tickets pending. Action: normal operation.

[YELLOW - throttle delivery, protect the counter]
Trigger: queue over [A] for [M] minutes, OR [B] or more delivery
tickets pending.
Actions, in order, each with its owner:
1. Register: disable "add-on suggestions" on the delivery platforms;
   bump stated prep time up one notch
2. Packing: finish ALL counter tickets first; sequence delivery
   tickets by time-to-penalty, shortest first - NOT by order time
3. Manager (or register, if no manager on shift): scan every accepted
   delivery ticket's projected handoff; for any projected past the
   penalty, message the customer proactively with an apology and a
   new time - never wait to respond after it's already late

[RED - stop delivery, keep the doors open]
Trigger: core-item stockout AND queue over [A]; OR delivery tickets
pending at [B+3] or more.
Actions:
1. Set the delivery platforms to "resting" with a posted note:
   "Morning rush at capacity, accepting orders again at X:00" -
   a fixed clock time, never "later"
2. Accepted-but-uncooked tickets still get honored, sequenced by
   penalty risk
3. Recovery: back to yellow only when the core item is replenished
   AND the queue has held at [A] or fewer for [M] minutes; yellow
   to green likewise - recovery needs quantified conditions so
   nobody forgets to reopen delivery after the rush

Bad-review countermeasure (every delivery ticket during yellow/red):
a sticker or pre-printed slip on the seal: "Rush-hour delays today -
we've added [small comp] to this order." The comp is fixed at one
tea egg; its cost lives in the delivery budget, decided now, not
mid-rush.

Record requirement: at every tray-out, packing marks the current
state (G/Y/R); at close the manager totals the day's yellow and red
minutes. Three straight days over yellow triggers a review of the
prep-quantity rules, not of the dispatching.

Ownership: yellow/red triggers and recoveries are judged by the
manager; on no-manager shifts the register judges strictly by the
numbers in this SOP - no discretion.

Constraints:
- No "handle flexibly as the situation requires," no "use judgment"
  - every action in every state must be executable without deciding
- No goal sentences like "minimize late orders" - an SOP contains
  only actions
- A, B, M, T stay as [] blanks for me to fill from my own traffic

Why it is written this way

Without rules, dispatch during a capacity conflict goes to whoever is loudest: a driver at the door pushes delivery out first, a customer tapping the window pushes the counter - alternating failures on both fronts, the worst double loss. The SOP's value isn't the "counter first" master rule (everyone knows that); it's hard-coding the single exception: a ticket within T minutes of penalty must jump the queue. Without it, "counter first" turns into a cascade of late penalties within half an hour; with it, what gets throttled is only the delivery that still has buffer - never the one about to be fined.

All three states quantify to headcounts and ticket counts so a no-manager shift can run them. The early rush at a breakfast shop is often just a register and a helper; any rule that needs experienced judgment is no rule at all - which is why even the judging role has a fallback path: the register judges by the numbers, discretion banned. Sequencing delivery by time-to-penalty rather than order time is the same logic: platforms penalize remaining time, and queue fairness is worth nothing at 7:30 a.m.

Recovery conditions are written as hard as the triggers because it's the paragraph everyone would call excessive - until they've watched a store stay in red and forget to reopen delivery, writing off dozens of orders for a morning. The fixed tea-egg comp turns compensation from a decision into a cost line: comps that require a mid-rush decision never get decided; budgeted, the sticker is just another step in packing. And tallying yellow/red minutes at close quietly turns this SOP into a data source for prep rules - three straight yellow days mean the real problem was last night's prep quantities, not the morning's dispatching.

Variables

Variable Notes
Queue line A Headcount that enters yellow - set by the physical space at the counter and handoff speed
Duration M How long past A the queue must hold before it counts - filters momentary spikes
Delivery backlog B Pending delivery tickets for yellow/red - set by rider arrival rhythms
Jump threshold T Minutes from platform penalty that forces queue-jumping - back-calculated from the platform's rules

delivery managementrush dispatchticket sequencing