Permissions by role in the hotel restaurant: what each person can do and what they cannot

In many hotel restaurants the system has a single password and it is taped next to the screen. The server voids, the cashier discounts, the captain reopens yesterday’s close and the manager finds out on Monday. When the controller asks who voided a table of four at eleven at night, the answer is the same as always: the system. And the system has no name.

A permission is a responsibility with a name

A permission is not a restriction born of distrust. It is the way every action in the hotel restaurant gets an identifiable owner. When the server logs in with their own password or PIN, every ticket sent to the kitchen carries their name. When the captain authorizes a void, the void carries theirs. Nobody has to accuse anybody: the record says who did what and at what time.

This matters more in a hotel than in a street restaurant for one reason: the hotel restaurant touches the guest folio. A room charge posted wrong, voided or duplicated does not stay in the restaurant; it reaches the front desk, appears on the guest’s bill at check-out and, if it is wrong, the guest argues it at the counter with a line behind them. Permissions are the first line of defense against that.

The five roles and what each one needs

Almost every hotel restaurant can be described with five roles, even if in a small property one person covers two. What changes between them is not hierarchy: it is which decisions they make about money and about the guest folio.

Server

Opens tables, captures orders with their modifiers, sends to kitchen and bar, prints the check and posts the room charge when the guest says “To my room, please.” What the server does not do: void an item already sent to the kitchen, apply discounts, change prices or close the shift. If the server can void without authorization, the system cannot tell an entry mistake from a dish that was served and never charged.

Captain

Sees every table in the room, not only their own, and reassigns tables between servers when someone gets swamped. Authorizes with their code the voids after sending to the kitchen, always with a reason, and authorizes comps within a cap set by the manager. The captain is the first filter: if the captain approves a void, that void exists with two names, the server who asked for it and the captain who authorized it.

Cashier

Takes payment in cash, card, transfer and split tender, records tips, closes their shift and hands over the cash with the report. Does not capture orders or void items, because whoever collects should not be able to alter what they collect. Cannot reopen a closed shift either: if there was a mistake, it is corrected with an identified movement in the next shift, not by erasing the past.

Restaurant manager

Configures the menu and prices, sets comp caps, creates and deactivates users, approves discounts above the cap and sees the reports for their revenue center. Can reopen a same-day close with a recorded reason. Should not be able to delete the void history nor edit a room charge the front desk has already posted to the folio: that is corrected from the front desk with an adjustment that also carries a name.

Hotel controller

Sees everything and touches nothing. The controller’s permission is read-only across every revenue center in the hotel: restaurant, bar, room service, pool bar. Reviews sales, voids, discounts, shift closes and room charges, and reconciles them against what the front desk posted to folios. If the controller has write access in the point of sale, they stop being the reviewer and become one more operator. The controller page (Controller) describes which reports are used for that reconciliation.

The permission matrix

Laid out as a table, the matrix reads in seconds. Each row is a system action and each column a role. Where it says “with reason”, the system requires picking a reason before continuing and stores it together with the name.

Notice two columns that must never blend: whoever captures does not collect, and whoever collects does not capture. In a small property where the same server also takes payment, the answer is not to give them every permission but to have the system record every action under their name and have the manager review voids and discounts every day.

The two permissions that need the most care

Of the whole matrix, two rows concentrate almost every problem in a hotel restaurant. The first is the void after sending to the kitchen. A dish that was already cooked and gets voided without a reason may be an entry mistake, a customer who walked out without paying, or a consumption that was served and collected in cash outside the system. Without a mandatory reason and the authorizer’s name, all three look the same on the report.

The second is the room charge. In a text field where anyone types a room number, the permission does not matter because there is nothing to verify. When the charge is verified against the guest’s stay, the permission means that this server can start a charge and that the guest, with their name confirmed on screen, accepts it. What no restaurant role should be able to do is modify a charge the front desk has already posted to the folio. The article on why a text field is not enough (Room charge: why a text field is not enough) covers the rest.

An illustrative example with numbers

The figures below are invented to show the calculation; they are not data from any hotel. Imagine a hotel restaurant that issues 1,200 checks a month and wants to know how much it voids after sending to the kitchen.

In the example, the difference is not that people become more honest with permissions. It is that every void now costs an explanation with a name, and the ones without an explanation stop happening. And the 18 that remain carry a reason: the manager can see whether the problem is a new server’s entry, a dish the kitchen keeps rejecting, or a table that leaves without paying on Fridays.

How to roll out the matrix without slowing service

Every manager’s fear is that permissions make service slow: that the server has to hunt for the captain for every little thing. Well designed, the opposite happens. The server does everything within their role without asking, and only sensitive actions request an extra code, which the captain types on the same screen in three seconds.

• One user per person, with a short PIN. Shared passwords are banned from day one, even with a single shift.
• Predefined void reasons, and few of them: entry mistake, customer changed their mind, kitchen could not make it, customer left. A free text field invites people to type “xx”.
• Comp caps in money per day and per role, set by the manager and visible to the controller.
• Daily review of voids and discounts by the manager, five minutes, before the shift close.
• Immediate deactivation of the user when someone leaves the hotel, the same day they return the uniform.

The security page (Security and control) describes how those records are stored and who can consult them. The underlying rule is simple: nothing is deleted, everything is corrected with a movement that carries a name.

What to do this week

1. Create a user with a PIN for every person in the hotel restaurant and take the shared password off the screen.
2. Define the allowed void reasons, no more than five, and make choosing one mandatory.
3. Set the captain’s daily comp cap and the manager’s, and tell the controller.
4. Remove order capture from the cashier and payment from the server, or if they are the same person, turn on the manager’s daily review.
5. Confirm with the front desk that no restaurant role can modify a charge already posted to a folio.
6. At the end of the week, pull the void report by user and reason, and read it with the captain.

Inn Restaurant ships this matrix configured by role, with mandatory reasons and a record of who authorized each action, and the hotel controller reads it without being able to alter it. If you want to see it with your own team’s roles, the fifteen-minute demo is booked on the contact page (contact).