The schedule you publish is a plan. What actually happens is the plan plus every request, swap, illness and late bus for the next two weeks. This topic is about handling that traffic without it taking over your day — which is almost entirely a question of channels and rules, not software.
📥 Availability is not a request
Two different things get confused constantly, and separating them fixes half the confusion:
| Availability | Time-off request | |
| What it is | The hours someone can work at all | A specific date they need off |
| How often it changes | Rarely — a class, a second job, childcare | Constantly |
| Who decides | They tell you; you plan around it or you cannot employ them for those hours | You approve or decline it |
| Where it lives | On file, permanently, in the tool | A dated request with an answer |
| When it can change | With notice, in writing — set the period yourself | Before the schedule is published, ideally |
Write down two deadlines and repeat them until they are boring: when availability changes must be in, and when requests for a given week must be in. Requests that arrive after the schedule is published are handled as swaps, not as requests. That single rule is what stops the schedule being rebuilt three times.
🔁 Swaps that work
A swap policy needs four sentences, no more:
- It goes through the app. Not a text to a colleague, not a note. If it did not happen in the tool, it did not happen.
- Only between people who can do the job. A server cannot cover the line. Set roles in the tool so it enforces this instead of you.
- A manager approves. Usually a formality, and it is where overtime and someone's sixth day get caught.
- Until it is approved, the original person owns the shift. This is the sentence that prevents the "but I found someone" conversation.
Say the fourth one out loud when you introduce the policy, and again the first time it is tested. Nobody argues with it once, and it saves a shift every few months.
📣 One channel, and what belongs in it
The most common failure in this whole course is scheduling traffic spread across personal messages, a group chat, phone calls and conversations at the pass. Pick one channel and be consistent:
- In the tool: the schedule, availability, requests, swaps, shift notes, and "who is covering this open shift".
- A phone call: anything happening in the next few hours. Nobody reads an app on the way to work.
- In person: hours being reduced, a pattern of lateness, anything with feeling in it. A notification is a bad way to deliver news that matters to someone's income.
Then hold the line for a month, kindly: "send that through the app so it does not get lost". A rule that is enforced for four weeks becomes the way things are done; one enforced for four days becomes a thing you say.
🚑 Calling out, no-shows and the open shift
- Have a stated call-out procedure. Who to call, how far in advance, and a phone call rather than a message so you know it landed. Put it in writing when people are hired.
- Post the shift, do not phone around. An open-shift notification reaches everyone who is qualified and free in one action, and whoever wants the hours takes it.
- Keep a short standby list. The two or three people who reliably want extra shifts. They exist in every restaurant and they are your insurance.
- Log it, every time. Late, absent, swapped out. Not to punish — so that a conversation three months later is about a pattern rather than about your memory. This is topic 6.
- Treat the first no-show as information. Transport, childcare and a second job explain most of them, and all three are fixable with availability. The second one is a different conversation.