Fast food restaurant scheduling supervisor - shift swap and emergency cover SOP - a "sure" in the group chat is not a handover; every no-show shift starts with two rounds of "I thought they were coming"

You are a scheduling-process consultant for a fast
food restaurant. Write the shift-swap and emergency
cover SOP. Readers: the scheduling supervisor and
all staff. Context: high part-time share, late
absence notices, frequent swaps, and a no-show
incident in the past.

Two fixed paths:

Path one - peer swap (two people voluntarily
trading shifts):
1. Initiation: both people file it in the swap log
   [online form or paper book] - names, original
   shift, target shift, date, both signatures or
   confirmations
2. Supervisor verification: before approving, check
   three things - skill coverage intact (the
   incoming person can run the station the period
   needs), neither party over the weekly cap, no
   excessive doubles created
3. Effect: the swap exists only once the log's
   approval line is signed. "Sure" and "got it"
   in the group chat never count as handover -
   this rule goes into the SOP body as an iron
   rule
4. Deadline: swap requests at least [24 hours]
   before the shift; later requests route to
   path two

Path two - absence cover (one person out, a body
needed), three gates counted back in time:
1. [24 hours] before: the supervisor works down
   the availability list by skill gap first (not
   by who replies fastest) - ask qualified people
   before available people
2. [12 hours] before: still uncovered -> post the
   shift's skill requirements and hours to the
   group, open it for claims
3. [2 hours] before: still uncovered -> the
   fallback ladder: supervisor or store manager
   covers -> adjacent-shift staff extend (with
   consent and within the weekly cap) -> close
   one station and notify the front counter to
   adjust service. Closing a station is a
   decision, not a failure - that sentence goes
   into the SOP

Universal rules:
- Every swap and cover action lands in the log:
  who, when, reason, cover, approver - the written
  trail is the only defense in a dispute, and "I
  thought they were coming" is the fixed overture
  of every no-show
- Sudden no-shows (slept in, emergency) enter
  directly at gate three of path two; no more
  searching

Output format:
- One action-level section per path
- Swap log field design: field / who fills it /
  example
- Gate timing card: for tomorrow's 17:00 shift,
  what happens at each of the three checkpoints

Constraints:
- Hour caps and gate timings stay [per store
  policy and local rules]; no regulation citations
- No "staff should take more responsibility"
  language - every rule lands on action, time,
  and written trail
- No communication tools this store doesn't have
  (e.g. scheduling apps) - channels follow the
  current state I describe

Why it is written this way

Swaps and cover must be two paths because their risk structures differ: a swap is consent-plus-verification filing; cover is search-plus-fallback firefighting. No-show incidents almost always come from treating cover with a swap's looseness - two people agree in the chat, the supervisor likes the message, and the cover thinks they were talking about next week. Written as one blurred path, both fail.

"'Sure' in the chat is not handover", written into the body as an iron rule, is the SOP's teeth. Ninety percent of fast food swaps complete verbally in group chats, and when it goes wrong the chat log proves neither that the supervisor knew nor that anyone promised. The one version that protects everybody is the written log; without this rule the rest of the SOP is decoration.

The fallback ladder ends with "closing a station is a decision, not a failure" to unblock the supervisor's decision-making. Without that sentence, supervisors keep searching to avoid closure until they schedule themselves into every gap - the person burns through first and the process collapses right after. Legitimize closure and the supervisor dares to trigger the fallback at gate two - and fewer stations actually close.

The gates finally land as a concrete timing card for "tomorrow's 17:00 shift" because 24/12/2 hours written in a policy read as nothing: "by 9 tomorrow morning do X, by 3 pm do Y, at 5 do Z" is understood on first use. An SOP's executability always bottoms out at that granularity.

Variables