Staff roles and the permissions that follow

On a busy night, a guest's main course arrives cold, and the server wants to take it off the bill. Can they do that themselves, or do they need a manager? The answer, in many venues, depends on who is on shift, which login is open on the till and what the last manager happened to allow. Nobody wrote it down, so everyone does something slightly different, and the end-of-night figures show comps that nobody can explain.

Clear staff roles fix that. A venue that names four or five roles, writes down what each one may do and sets up its systems to match gives every member of the team a clear picture of their authority, and gives the manager a clear picture of who did what. The till, the booking system and the reports all follow from the same decisions.

This guide covers how to choose the roles, what each one should be able to do, how to match the systems to them and how to keep them current as the team changes. Every venue and figure in it is an example.

Roles answer a simple question for everyone on shift: what am I allowed to do? Without them, authority is informal, which means it depends on confidence, seniority and who happens to be nearby, and it changes from night to night.

With clear roles, a new server knows what they can decide alone and when to call someone. A supervisor knows what they can approve. And the systems the venue uses can enforce the same rules, so the authority on paper and the authority on the till are the same.

Most restaurants need only four or five staff roles: manager, supervisor or shift leader, server, host and kitchen, with a bar role where the bar runs separately. More than that, and the differences between roles become hard to remember; fewer, and people end up with access they do not need.

Name each role by what the person does, not by their seniority or their length of service. A senior server and a new one share the same role; what changes is their experience, not their permissions.

The manager runs the venue: bookings, the floor, the kitchen's needs, the team, the money at the end of the night and the decisions when something goes wrong. Their role covers almost everything in the venue's systems: menus, prices, reports, the team and the settings.

What managers usually do not need is the business owner's access: billing, the subscription, the ownership of the account and the power to create or remove other managers. Keeping those with the owner protects the business if a manager leaves.

The shift leader, or supervisor, runs a service when the manager is not there. They make the calls that cannot wait: a comp for a cold dish, moving a party to another table, dealing with a complaint, closing down at the end of the night.

The principle is simple: a shift leader needs the authority to solve problems during service without waiting for the manager, and the venue needs a record of the decisions they made, so the manager can see them the next day.

The server takes orders, looks after their tables and takes payment. Their role covers the till: opening tables, adding dishes, sending orders to the kitchen, taking payment and printing or sending the bill.

What a server can do beyond that is a choice each venue makes: whether they can void a dish they rang in by mistake, comp a dish for an unhappy guest or apply a change to a bill without asking. Write the choice down, and set the systems to match.

The host looks after the door: bookings, the waitlist, walk-ins and seating guests. Their role covers the booking system and the floor plan, and the guest details needed to take and manage bookings.

Hosts rarely need the till, the menus or the reports. Limiting their role to what the door needs keeps the booking system tidy and keeps guest details with the people who need them.

The kitchen team needs the kitchen screen or printer, the menu, to see what is on each dish, and the ability to mark orders as ready. They rarely need the till, the bookings or the reports.

A head chef may need more: the menu itself, to change dishes and mark items as sold out, and the kitchen's own reports, such as ticket times. That can be a separate role, or the manager role, depending on the venue.

Where the bar runs as its own section, a bar role may make sense: the till for drinks, the bar's own tabs and the drinks menu, without the dining room's bookings or the kitchen's screen. In smaller venues, bartenders often share the server role.

Decide by what the bar team actually does. If they take food orders at the bar and seat walk-ins, the server role may fit; if they only make and sell drinks, a narrower role keeps things simpler.

Many owners work services alongside the team. An owner on the floor should still sign in as themselves, so their actions are recorded like everyone else's, but they rarely need to use the owner's full access during service.

Some owners keep a separate, everyday login with a manager's role for working shifts, and use the owner's access only for billing, roles and the business's settings. It reduces the risk of a costly mistake made in the rush of service.

For each role, write a short list of what it may do and what it may not, in plain words. "Servers may void a dish they entered by mistake before it is cooked, with a reason. Servers may not comp a dish; ask the shift leader." "Shift leaders may comp up to one main course per table, with a reason."

Keep the list to a page. It should answer the questions that come up every night, not every question that could ever arise.

POS permissions decide what each role can do on the till, and they are where informal authority causes the most trouble. Voids, comps, discounts, refunds, reopening a closed bill and cash handling are the usual areas.

Match the till's permissions to the written list. Our guide to POS permissions: who can void, who cannot covers the decisions each venue has to make and how to set them.

Some venues require a manager's approval for certain actions: a comp above a set value, a refund, reopening a closed bill. Approvals add control, but they can also stall a service if the manager is busy or off the floor.

Use approvals sparingly, for the actions that carry real risk, and make sure someone with approval rights is always on shift. Our guide to manager approvals that do not stall a service covers how to balance control and speed.

Roles only work if each person signs in as themselves. A shared login on the till, or one login for the whole bar, means every void, comp and payment is recorded against "Bar" rather than a person, and the roles mean nothing.

Give every member of staff their own login and a PIN they keep to themselves, and make signing in quick enough that nobody is tempted to share. Our guide to staff logins: one till, eleven people covers how.

Temporary staff, agency workers and people covering a single shift still need their own logins and a role, even if only for a few days. Sharing a permanent member's login with a temporary worker records their actions against someone else.

Set temporary access to end when the work ends, and check after each busy period that nobody who has left still has access.

Reports deserve as much thought as the till. Sales figures, staff performance and guest spending are sensitive, and not everyone needs to see them. Most venues give reports to managers and, sometimes, shift leaders, and keep them from servers, hosts and the kitchen.

Where a team member needs a figure, such as the head chef needing ticket times, consider sharing it at the briefing rather than giving access to every report.

A good rule for setting roles is to give each one the access it needs and no more, often called the principle of least privilege. A host does not need the reports; a server does not need to edit the menu; a cook does not need guest records.

Least access protects the venue and the staff. Fewer people can make costly mistakes, guest details stay with those who need them and nobody is put in the position of being blamed for something they should never have been able to do.

Guest details deserve particular care. The host needs names, phone numbers and booking notes; the kitchen needs allergies; the manager may need visit history and spend. Not everyone needs everything.

Set roles so each person sees what their job needs. A server who can see a regular's allergy and preferences serves them better; a server who can browse every guest's spending has access they do not need.

Money is the other area that needs care: refunds, voids after payment, cash drawers, the end-of-night totals. Limit these to the roles that are responsible for them, usually the shift leader and the manager.

Where a server can void or comp, make sure every void and comp carries a reason and the name of the person who made it, and that someone reviews them after each service. Clear records are as important as limits.

In a group, some people work at more than one venue: a manager covering two sites, a chef who moves between kitchens, servers who pick up shifts elsewhere. Their role should travel with them, with access to the venues they work at and no others.

Set access by venue as well as by role. A server at one venue should not be able to open the till at another, and a manager of one site should not see another's reports unless their job needs it.

When someone is promoted, their role should change on the day, not weeks later. A new shift leader who still has a server's permissions cannot do the job; a former supervisor who has moved to part-time server work should not keep supervisor permissions.

Make the change part of the promotion itself: a new role in the system, a new list of what they may do and a short briefing on their new authority.

When someone leaves, remove their access on their last day. A former employee who can still sign in to the till or the booking system is a risk, however well they left.

Keep a simple leaving checklist: access removed, keys returned, uniform returned, final pay agreed. The access is the item most often forgotten, and the one that matters most.

The role a person holds in the system should match the job they were hired for. A job description that says "server" and a system role that gives them a manager's access tell two different stories.

Write the role into the job description, and set it up before the person starts. Our guide to job descriptions that describe the actual job covers how to describe each role plainly.

Each role needs its own training, matched to what it may do. A server learns the till's ordering and payment; a shift leader learns the comps, the end-of-night checks and how to handle complaints; a host learns the booking system and the floor plan.

Build the role's permissions into the training checklist, so new starters learn what they can do and when to call someone in their first weeks. Our guide to a training checklist for the first four weeks covers how.

Review the roles once or twice a year. Are the lists still right? Are the systems still set to match them? Does anyone hold a role that no longer fits their job? Has a new task appeared, such as a new delivery service or a new till feature, that needs a decision about who may do it?

A short review keeps the roles and the systems in step. Without it, they drift apart, and the informal authority the roles were meant to replace creeps back.

Tills, host stands and kitchen screens are shared devices, used by many people in a shift. Roles work on them only if each person signs in as themselves and the device locks when they walk away, so the next person cannot act under their name.

Set the devices to lock quickly when idle, and make signing in fast with a short personal PIN. A shared device that stays signed in to one person for the whole night undoes every role the venue has set.

Sometimes a role's limits get in the way: a server who cannot fix a simple mistake on a bill while the shift leader is busy, a host who cannot see a note the kitchen added. When the same limit causes trouble every week, it may be in the wrong place.

Listen to the team when they say a rule slows them down, and change the role if the risk is small. Roles should protect the venue, not make the job harder than it needs to be.

Explain the roles to the team, and why they are set as they are. Staff who understand that a server cannot comp a dish because the venue wants every comp approved and recorded are more likely to accept it than those who feel they are not trusted.

Include the roles in training. A new starter who learns their role's list in their first week knows from the start what they can decide and when to call someone.

Clear roles are sometimes seen as a sign of distrust. They are the opposite. A team where everyone knows their authority, and the systems back it up, can be trusted with more, because every action is clear and recorded.

Trust is easier when the rules are fair and the same for everyone. A role that applies to every server, rather than permissions given to favourites, is a role the team can believe in.

An invented brasserie has one shared login on each till and no written roles. Comps vary from nothing to several hundred a night, and nobody can say who gave them. The manager defines five roles: manager, shift leader, server, host and kitchen, and writes a one-page list of what each may do.

Every member of staff gets their own login and PIN, the till is set to match the roles and every void and comp needs a reason. After a month, comps are lower and every one has a name and a reason beside it. The shift leaders say the clear rules make their job easier, because they no longer have to argue about what they are allowed to do.

In servearound, staff roles live in the system, not in heads. The Owner role is fixed and holds everything, and a new network starts with four roles it can edit, rename or delete: Manager, which runs the venue day to day, with every module, the venue's settings and the team but not the plan, billing or roles; Server, which takes orders and payments at the tables; Host, for bookings, the waitlist and seating guests; and Kitchen, which works the kitchen board. The owner can add more, choosing view, create, edit and delete module by module, and a role someone holds cannot be deleted until nobody holds it.

Staff are invited by email with their role and the venues they work in, and sign in on shared screens with their own name and PIN, so every action is recorded against them. Anyone whose role lets them take orders can void or comp, each with an optional reason, and there is no separate manager-approval step today, so the roles decide who uses the till and payment analytics show voids and comps by member of staff. See point of sale and kitchen.

Usually four or five: manager, shift leader, server, host and kitchen, with a bar role if needed.

Usually not. Their experience differs; their permissions can be the same.

Decide it for your venue, write it down and set the till to match, with a reason recorded for every comp.

For high-risk actions, if someone who can approve is always on shift.

Because every action is then recorded against the login, not the person, and the roles mean nothing.

Change their role on the day, with a new list of what they may do.

On a leaver's last day.

Once or twice a year, and whenever a new task appears.

Staff roles answer the question every member of the team asks on a busy night: what am I allowed to do? Name four or five roles by what people do, write a one-page list of what each may and may not do, and set the till, the booking system and the reports to match, with POS permissions and any manager approvals following the same decisions.

Give everyone their own staff logins, follow least access, take particular care with guest details and money, and change roles on the day someone is promoted or leaves. Include the shift leader's authority in the list, review the roles once or twice a year and explain them to the team, because clear roles are what let a venue trust its people with more.