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"
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 |