Create a staff rota: Building the week around real restaurant demand

The week starts with the floor picture, not with a list of names

When I create a staff rota, I do not begin by asking who is free first. I begin by asking what the restaurant week is likely to look like in real service terms. A quiet Monday needs a different shape from a Wednesday with a group booking and an earlier setup window. Then the weekend changes the picture again, because weather, walk-ins, and reservation patterns can shift pressure fast. So I sketch the week as workload: reception, setup, table service, support, and closing. That gives me a realistic map of where attention is needed before I start assigning people and times as if every assumption were already settled and ready to be announced to the team.

In Bonzumo, I treat that first version as a draft on purpose. The distinction matters because a draft lets me plan shifts, consider absences, and see the intended staffing level without presenting unfinished thinking as a promise. For a week like this, that saves me from creating avoidable uncertainty. Monday may be light, Wednesday may need earlier hands for a group, and Saturday may still depend on one open cover question. If I want to create a staff rota that people can trust, I need a space where the structure is visible before the plan is published. The draft stage gives me that space, so I can shape the week without pushing half-checked decisions straight into the team’s working day.

Why a plan published too early creates twice the work later

The trouble in rota planning is often not resistance from the team, but assumptions that were never clearly checked. Maybe Saturday cover has been requested but not confirmed. Maybe the Wednesday group needs someone earlier than normal to prepare tables, glasses, and internal handover points with the kitchen. Maybe Monday looks calm, yet I still need one person to hold reception properly instead of being stretched across several jobs at once. If I publish under those conditions, the plan looks stable on the surface while still wobbling underneath. Later changes then feel like disruptions, even though the uncertainty was there from the beginning and should have been handled before release.

That is why I separate open, workable, and approved in my own process. Open means a cover question or task assignment still needs clarification. Workable means the shift pattern could function if the remaining point is confirmed. Approved only starts when I have checked the critical parts well enough to stand behind them. Bonzumo supports that discipline with draft and published rota states, which helps me avoid acting as if planning were either finished or non-existent. My team ends up seeing a more reliable schedule, and I avoid the familiar problem of publishing quickly and then chasing corrections through messages and side conversations that could have been prevented by a better check before publication.

Turning a Wednesday group booking into actual tasks instead of a longer generic shift

A useful rota appears when I translate reservations into work, not when I merely add more hours. With the Wednesday group booking, I look beyond occupied seats and think about the time before guests arrive. Someone may need to start early for setup, table layout, glassware, station preparation, and coordination on how the booking will be handled during service. I mentally split the evening into phases: setup, arrival, core service, and close. Once I do that, it becomes clearer who truly needs an earlier start and who can join later without creating idle time. That is the point where planning stops being a list of names and becomes an operational decision about how the evening should actually run.

Bonzumo helps me keep those decisions organized around the planned shifts and the people involved instead of losing them across separate chats. Employee profiles help me keep track of who I am assigning, while roles and permissions make sure shift leads, service staff, and office functions do not all need the same access. For this Wednesday, that matters because the person coordinating the setup may need a different level of responsibility from someone joining for the main service period only. I can create a staff rota with that structure in mind and keep the setup visible in the plan, so the group evening becomes a prepared part of the week instead of a surprise that the team has to decode on the day itself.

Saturday reception pressure is usually one small bottleneck with large consequences

In a mixed week, the biggest risk is often not where the most tables are, but where one role holds the flow together. For me, that is often Saturday reception. If arrivals bunch up, the phone rings, and walk-ins appear at the same time, a weak start there can spread tension through the whole floor. So when I create a staff rota, I test not only total headcount but the exact points where timing matters most. Is reception really covered during the first rush, or have I simply counted bodies and hoped it would work itself out? If the answer is uncertain, I mark that pressure point in the draft openly instead of covering it with optimism and forcing the team to absorb the strain later.

In practical terms, I do not look for just any name to fill that gap. I look for a solution that can carry the first hour of service. That might mean moving tasks within the opening phase, starting one shift earlier, or clarifying a cover arrangement before I release the week. Until that question is checked, the plan stays in draft. That makes sense for the team because I am not declaring something final today and qualifying it tomorrow. The same care applies later if recorded times or shift details need adjustment. Even when a correction is requested by an authorized person, I still review the reason and whether the change is plausible in the context of the shift before accepting it as part of the record.

Matching demand with availability, absences, and clear responsibilities

Once demand and bottlenecks are visible, I compare them with the people I actually have available. That takes more than counting free hours. I look at absences, the spread of work across the whole week, and who can realistically carry which responsibilities. A quiet Monday may suit a smaller team or a training-focused shift, while Wednesday and Saturday usually need stronger structure and clearer handover points. In Bonzumo, shifts and absences are visible in one place, which does not remove judgement from the process but helps me organize it. I spend less time piecing the week together from scattered agreements and more time deciding whether the draft is truly workable or just polished on the surface while hiding weak spots underneath.

Roles and permissions matter just as much as staffing numbers. Not everyone in the business should change everything or see everything. If shift lead, service, and office each have different responsibilities, I want that reflected in the way the week is organized. Bonzumo supports roles and permissions, which helps me distribute planning, review, and follow-up more clearly. Personal documents also do not have to live in random message threads when they can be made available in a personal document inbox for reading and downloading. That fits the way I want the team to work: a rota should not only exist, it should be understandable, orderly, and connected to clear responsibilities so that people know both their shift and their part in making it function.

Publishing only after open assumptions are clarified changes the tone of the whole week

Right before publication, I read the draft as if I were the person actually working the shift rather than the manager who built it. Is the unresolved Saturday cover now confirmed? Does the early Wednesday setup team know that setup is part of the planned shift and not an informal expectation? Is reception on Saturday protected in practice, not just in a neat grid? Are there moments where two time-sensitive tasks still fall onto one person at once? Only when those questions are answered plausibly do I publish. That is the step that makes create a staff rota more than data entry. Publication becomes a deliberate commitment that the week should function in the restaurant, not just a click that moves an unfinished schedule into view.

I also try to discuss open assumptions before publication instead of after. That changes the conversation with the team completely. Rather than reshuffling in a rush later, I can say clearly that a shift remains in draft because one cover point is still unresolved or because Saturday reception still needs securing. Bonzumo supports this way of working through the distinction between draft and published plans, and for me that is more than a technical state. It is an operating habit that reduces misunderstandings. The team sees a rota that has been checked with care, not a provisional one disguised as final. That is why the schedule remains a draft until tasks, people, and remaining assumptions actually fit together in a way I can defend.

After the week, I use recorded time to learn from reality without waving corrections through

Once the week is over, planning is not finished for me. I review where the draft matched reality and where it did not. Were the early Wednesday hours set well, or would a different setup pattern have worked better? Did Saturday reception hold, or should I protect that first hour differently next time? For that kind of review, actual working time matters, but only if it is recorded in a way that can be followed and discussed. Bonzumo includes personally assigned time tracking sessions with start and end times, configurable rules with exceptions, and working time accounts with separate editing rights. That gives me a structured basis for reviewing the week, instead of relying on memory or rebuilding events from fragments after the fact.

If time corrections come up, I do not treat them as routine clicks. Even if the request comes from an authorized person, I still check the reason and whether the correction is plausible against the shift flow, handovers, and the other recorded times. Was it a forgotten clock-in, a wrong assignment, or an exception that needs a clear explanation? That review matters because I want create a staff rota to be part of a dependable operating process, not an isolated planning exercise. My goal is not to predict every week perfectly. My goal is to learn cleanly from a concrete week and use that learning to build a stronger next draft, where reservations, tasks, staffing, and actual time worked line up with fewer open questions and less avoidable pressure on the team.