N NoBullshit.wiki 中文

Fast food restaurant server - delivery packing and double-check SOP - the last gate against missing items is reading the ticket out loud, not "a quick look"

Works with:Claude / GPT-4 classCategories:Fast Food RestaurantLevel:Beginner Updated

You are a delivery-operations consultant for a fast
food restaurant. Write the packing and dispatch SOP
with one goal: drive missing items, wrong items, and
spills as close to zero as possible. The reader is a
packer handling three delivery platforms' orders at
once at peak.

Four fixed steps:

1. Verify (on order arrival):
- Check ticket against the order screen once: items,
  quantities, notes (allergies, spice level, utensil
  counts)
- Lay out boxes to match the ticket's item count in
  one pass - a missing box is visible at a glance;
  this is the first wall against missing items
2. Seal (written per category, three tracks):
- Soups and sauced items: seal method, upright
  placement, separated from dry items
- Dry items: seal sticker placement
- Drinks: lid plus secondary seal, own bag
- Every track written as concrete actions - "packaged
  securely" is forbidden wording
3. Extras check:
- Utensils, sauces, and promos placed item by item
  against ticket notes and the platform's config
  [per this store's delivery setup sheet]
- Ticket stapled or taped to the bag at a fixed
  position - the number-one cause of rider mix-ups
  is ticket and bag not matching
4. Rack and handoff (the last gate):
- Read it out at racking: item names and counts read
  aloud against the ticket (or ticked line by line)
  - not "a quick look"
- Rack slot = last [N] digits of the order number,
  written to match this store's actual rack layout
- The rider reads the order number's last digits
  back; the packer confirms before releasing the bag

Exception handling:
- Item out of stock: run "contact the guest or the
  platform" first, then handle the order - no
  unilateral equivalent substitutions
- Rider pressuring: pack by "closest to its promise
  time first", not by order arrival - and state how
  to tell which order is about to breach its promise

Output format: one action-level section per step, plus
a peak priority card for "one person, three
platforms": which signal says which order to handle
first (promise time closing / rider arrived / large
order still incomplete).

Constraints:
- No platform names or platform rules - platform
  actions written generically; specifics follow this
  store's dashboards
- No specific minute counts - timing standards stay
  [per store]
- No "be more careful" requirements - every error
  proof must be an action or an arrangement

Why it is written this way

Reading aloud replaces "a quick look" as the SOP's smallest and most consequential design. The natural enemy of double-checking is fluency: the better trained the packer, the faster the hands, the more the eyes glide instead of verify - missing items cluster among veterans, not rookies. Reading each item aloud (or ticking line by line) is the cheapest forced interruption: every item spoken must be fetched from the list once, and nothing skips. When one person is juggling three platforms, those five seconds are the best insurance money can't buy.

Laying boxes out to match the ticket translates counting into seeing: checking "are there five boxes" is a visual task anyone can do; checking "does the ticket say 5 items total" is memory-plus-arithmetic that fails precisely when it's busy. This translation - turning a mental check into an eye check - is the universal move of error-proofing.

"No unilateral substitution" is written as a prohibition because it wears the costume of goodwill and harvests reviews: the store's logic is "equivalent, even pricier"; the guest's logic is "this is not what I ordered". The substitution must clear the guest or the platform first - lock in that order, and goodwill finally has somewhere to stand.

The rider-pressure rule is equally counterintuitive: pack by nearest promise time, not by order arrival. Arrival order is fairness; promise time is damage control - reviews and platform rulings attach to breached promise times, not to "the order after yours went out first".

Variables

Variable Notes
Delivery setup sheet Each platform's default utensil and sauce configuration plus guest-selectable options - the execution basis for the extras check
Rack layout How rack zones map to order numbers - written to the store's actual shelving
Promise-time reference Where to check each platform's dispatch promise - this drives packing order when riders push

delivery packingdouble-check processreview prevention