Create a shift schedule: Plan the work phases before assigning names

A long Saturday becomes manageable when I split it into real work phases before I assign anyone

When I need to create a shift schedule for a long Saturday, I do not begin with who is available. I begin with the day itself. I write down when the outdoor area has to be ready, when cutlery, glasses, and stations must be set, when the kitchen should expect the first tickets, and when the quiet setup turns into active service. That changes the planning conversation immediately. Instead of seeing one large shift, I see a sequence of phases with different demands. In practice, this helps me notice where I need preparation time, where I need overlap, and where I need a clear closing role rather than simply another person on site for the same number of hours.

This matters most on a long Saturday because small weak points can add up fast. Before lunch, someone needs uninterrupted time to prepare the terrace. Between lunch and dinner, I need an overlap that prevents open tables and half-finished stations from falling between teams. Late at night, a group round can delay the final close even if the official end time looked tidy on paper. If I define the day as a chain of tasks and handovers first, I can create a shift schedule that reflects responsibility rather than only attendance. My team understands why some windows are tighter, why others are mainly preparatory, and why the last part of the day cannot be treated as an afterthought.

The usual cause of restless shifts is not a lack of people, but looking at names too early

Many schedules go wrong at the first step because the planning starts with names: who is free, who asked to leave earlier, who often agrees to cover. That feels practical, but it hides the transitions that decide whether service runs smoothly. The overlap between lunch and dinner does not always need a full extra shift; often it needs the right thirty or sixty minutes with a clear purpose. If I describe the work blocks first, I can see whether I truly need another person or whether I need better sequencing. That is how I create a shift schedule that responds to operations instead of stacking availabilities next to each other and hoping the day organizes itself.

Another recurring mistake is treating setup and closing as if they happen automatically. The outdoor area does not prepare itself, and a late group does not disappear exactly at the planned finishing time. If these phases are too tight in the first draft, the missing time comes back later as confusion. Handovers stay verbal, end times drift, and nobody is sure who owns the final checks. For me, the better approach is simple: make the work visible before assigning the crew. Once the work is visible, I can discuss where I need a reserve, where I need a stronger handover, and where a reliable closer matters more than adding one more name to the busy middle of the day.

In Bonzumo, I start the duty roster as a draft so I can test the logic of the day before I confirm staffing

For this workflow, I use the duty roster in Bonzumo as a draft first. That fits the way I plan, because I can see the intended staffing in context without treating the roster as final too early. I enter the shifts, define sensible time windows, consider absences, and review where the day needs deliberate overlap. The draft status is useful because it gives me room to test the operational logic before approval. Is the terrace setup long enough? Is the gap between lunch and dinner actually covered? Who must still be available if a late group stays longer than expected? Only when those questions are clearer do I start assigning people to the structure I have laid out.

Roles and permissions also matter in that discussion. A shift lead needs different access from a server or someone in the office, and Bonzumo supports roles and permissions so responsibilities can be reflected in the system. That helps me keep the conversation focused. Not everyone has to change every detail, and not every question belongs to the same person. When I review a long Saturday with service, kitchen, shift leadership, or the office, we can work from the same roster while keeping responsibilities clear. That reduces the noise that comes from parallel edits and last-minute calls, and it makes planning feel like preparation instead of a chain of improvised messages before the roster is approved.

Once the phases are clear, I assign people for handovers and strengths, not just for start and end times

After the work phases are defined, I begin assigning available people. At that point, I am not simply looking for the longest availability block. I am looking for good handovers, station confidence, pace, and reliability in specific parts of the day. The person who sets up the outdoor area does not automatically need to stay until the late close. The person who handles the lunch rush well is not always the best choice for the final group round at night. When I create a shift schedule this way, I deliberately build short overlaps that are long enough for a proper transfer but still purposeful. That keeps responsibility visible and reduces the chance that important details remain stuck in someone’s head.

The lunch-to-dinner overlap is where this becomes especially practical. I define what should happen during that shared window: review open checks, refill stations, note special reservations, reset the outdoor area, and check glassware and cutlery levels. Once the team understands that the overlap is a work phase with a purpose, it no longer looks like unnecessary double staffing. If someone asks why two people are scheduled at the same time, I can explain the reason from the flow of the day. That makes the roster easier to accept and easier to follow. It also means the handover is not reduced to a hurried sentence at the door, but treated as part of service quality and closing discipline.

Before approval, I review the draft with the team and compare it to how time recording will later be discussed

Before a duty roster receives its approval status, I review the draft with the team or at least with the people responsible for leading that shift. I am not only asking whether someone is available. I am checking whether the handovers sound plausible, whether the closing coverage is realistic, and whether special situations are visible early enough to adjust the plan. If a late group is likely to stay longer, or if weather may increase the terrace workload, I would rather change the draft than pretend the original timing will somehow hold. In that sense, approval is a conscious step, not an administrative checkbox. It marks the point where the team has tested the logic of the day together.

That review also gives better context later for time tracking. employee time tracking becomes much easier to discuss when there is a clear planned starting point. In Bonzumo, time recording sessions can be personally assigned with a start and end, which helps when the actual day differs from the roster and needs to be discussed afterward. If a correction is requested, even by an authorized person, I still require a check of plausibility and the reason. A correction is not a shortcut for weak communication. I want to know whether the setup started early because of weather, whether the handover took longer than expected, or whether a late group genuinely extended the close. That keeps reviews factual and fair.

Exceptions, working time accounts, and documents help me keep order after the shift without replacing leadership

Long Saturdays almost always produce exceptions. Someone starts earlier for the terrace, someone stays later because of a group, or a handover takes more time than planned. In Bonzumo, configurable rules, exception references, and working time accounts with separate editing permissions give me a structured way to review these deviations afterward. I do not treat that as automatic judgement; I treat it as organized follow-up. If I keep seeing the same exception around the same phase, that usually tells me the original roster was too narrow or the handover task was underspecified. This is useful because it lets me improve the next draft with evidence from operations instead of relying only on memory after a long service.

Employee profiles and a personal document inbox with reading and downloading also support this routine. I use them to keep important information findable, especially when a Saturday depends on clear setup notes, a service sequence, or an internal instruction that should not disappear in a chat from last week. At the same time, I do not confuse system order with leadership. No tool can replace the conversation about responsibility, pace, and handover quality. The roster, recorded times, and documents create a stable base, but I still have to lead the day with clear decisions before service and with clean follow-up afterward. Structure supports management; it does not remove the need for it.

I introduce this method with one demanding Saturday first, then make it the team standard for future rosters

If I want to introduce this approach in my team, I do not begin with the whole week. I begin with one demanding Saturday that everyone recognizes as operationally tricky. Together, we break the day into setup, outdoor preparation, first service, overlap, evening peak, late group round, and close. For each phase, I define the purpose before anyone talks about preferred names. Only then do we place available people into the structure. This gives the team a direct experience of why I create a shift schedule from work phases rather than from a list of names. Absences, preferred times, and workload still matter, but they are discussed after the work has been made visible, not before.

The result is a roster that people can read more clearly: who prepares, who takes over, who closes, and where the planned handovers sit. Only after that shared review does the duty roster move to its approval status. That is the crucial difference for me. I am no longer hoping that a hastily assembled Saturday will somehow carry itself. I have a draft that was discussed, tested for plausibility, and then approved with intent. Once the team has seen this on one long Saturday, the pattern becomes reusable. The next time I need to create a shift schedule, the conversation starts in the right place: not with names first, but with the actual flow of work that those names must support.