Giving staff system access without exposing your revenue
The reason most owners keep the only login is not cost — it's that one login means one kind of user, and handing it out means handing out everything. That's a software problem, not a trust problem.
Most small hotels have exactly one login, and the owner holds it. Not because staff aren't trusted with a room board or a task list — because the software only comes in one kind of user, and that user sees everything: revenue, payroll, guest contact details, the lot. Handing out that account is not a small ask.
The result is predictable: everything routes through one person, and the system stops getting used the moment they're away for a day.
The actual fix is not trust, it's scope
A housekeeper does not need less trust than an owner. They need a smaller list of screens — the room board, and nothing that touches money or a guest's private details. Once access can be scoped to exactly the job a person does, the trust question mostly disappears, because there is nothing sensitive left in reach to worry about.
Roles built from the job, not from a template
A role is a name and a set of modules — Housekeeping, Front Desk, Kitchen, Night Duty, whatever your property actually runs. Build the set that matches your actual jobs rather than accepting a fixed list of generic titles that half-fit. Anyone without a custom role gets a sensible default automatically: operational screens, none of the money ones.
Finer than a module, in a restaurant specifically
A kitchen display screen hangs on a wall for an entire service — anyone walking past can see it. Granting Restaurant as one module would put the recipe book and the till behind that same screen. Per-screen access inside the module fixes that specifically: a cook gets the kitchen queue, a waiter gets Orders, and neither one gets menu prices or the till.
Some screens should never be grantable at all
Billing, team management, integrations and hotel settings are the kind of access that should not exist as an option to accidentally check on a role — they are structurally excluded from what any custom role can be granted, which removes the human error of a well-meaning admin ticking one box too many. Analytics, pricing, expenses and payroll are different: real modules, grantable, but only ever on purpose.
The record that makes handing out logins feel safe
Scoped access answers what someone *can* see. An audit log answers what they actually *did* — every create, update and delete, with the actor, the entity and the time, plus every login, logout and admin impersonation. Combined, that pair is what actually makes staff logins safe to distribute: limited reach, and a record that survives the question 'who changed this' being asked three weeks later.
What this changes on a normal week
The practical test is simple: can the property keep running the day the owner is unreachable. With scoped roles, the housekeeper updates the room board, the front desk takes bookings, the kitchen clears its queue — none of it waiting on one person's login, and none of it exposing a number that person shouldn't see. That is the entire point of the exercise, and it is also usually the moment an owner realises the software has actually started being used by the team, not just by them.
Building the first set of roles
Start from the people already working the property, not from an abstract org chart. Write down what each person currently touches — the room board, the task list, the till, the booking calendar — and that list is most of the way to the role definition. A property with four staff usually ends up with three or four roles, not a dozen; the exercise is smaller than it sounds once it starts from the actual jobs rather than a generic template.
Two-step login closes the gap a shared password leaves open
Scoped roles control what an account can see. They don't control who is actually behind the login on a given day — a password shared casually between two staff covering the same shift quietly turns one account into two people's actions with no way to tell which. A login step that requires a code sent to the individual's own email closes that gap: the account cannot become communal even if the password does, because the second factor only reaches one inbox.
What happens when someone leaves
The moment a staff member leaves is exactly when a shared, generic login becomes a real liability — nobody remembers to change a password everyone knew, and the account keeps working indefinitely. A named account, scoped to a role, is simply disabled when the person leaves. Nothing else needs to change, because the role itself never depended on that one person continuing to hold it.
The objection worth taking seriously
'What if someone senior needs to see everything occasionally' is a real, reasonable question, not staff being difficult about it. The answer is not making every account see everything by default — it's granting a specific person the specific additional modules they occasionally need, on purpose, rather than defaulting the whole team wide open because one person sometimes needs the wider view. That decision is worth revisiting every so often too — a broader grant made for a specific project has a way of quietly outliving the reason it was given.
Starting small, on purpose
A property nervous about handing out logins for the first time does not need to roll every role out on day one. Starting with the lowest-risk role — housekeeping, which touches no money and no guest contact details at all — is a low-stakes way to see the mechanism work before extending it to front desk or anyone touching payment. Confidence built on one safe role transfers quickly to the next.
What this looks like from the staff member's side
For a housekeeper or a waiter, a scoped login usually reads as a smaller, less intimidating system than a full admin view would — fewer menu items, fewer numbers they were never expected to interpret, a screen built around exactly the job in front of them. That is not a downgrade from their perspective; it is the difference between software that feels like it was built for the owner and grudgingly opened to staff, and one that was actually built with their specific job in mind. Staff notice that difference even when nobody explains it to them.
Turn the answer into a working view
See it on your own property
See the bookings, rooms and team workflow on your own property.