Staff roles in the dashboard: who sees what

Access should be divided so that everyone sees and can do exactly what their job involves: the host seats guests, the manager handles bookings and conversations, the general manager looks at statistics, and the owner runs everything. Then a random mistake won't delete someone else's booking, and unnecessary guest data won't reach people who don't need it. Below we look at how to think roles through, how to invite people and how to organise sign-in on a shared tablet.

Why divide access

While a venue has three people, roles seem unnecessary: everyone knows everything. Problems start later, and usually for the same reasons:

• Excess permissions. A new member of staff accidentally cancels a booking or moves guests because the button happened to be at hand.
• Excess data. Not everyone needs guest cards, preferences and staff notes. The fewer people see the database, the lower the risk of it ending up in the wrong hands.
• It's unclear who did it. A booking disappeared, and nobody remembers why.
• A shared password. When everyone uses one login, it's impossible to tell who did what, and impossible to cut off someone who has left without changing the password for everyone.

A good permissions scheme solves all of this at once: everyone has their own login, their own permissions and a trail in the log.

How to think roles through

Start not with the dashboard but with paper. Write down the positions and for each one answer three questions: what the person needs to see, what they need to change, and what they must never touch.

An example split you can start from (adapt it to your venue):

The dashboard sections in GuestKeepr: Overview, Tables (or Specialists) with the live floor, Bookings (or Appointments), Guests (or Clients), Log, Statistics, Marketing, Conversations, Settings, Channels, Staff and Roles. Role permissions are set in the Roles section. Compare the table above with what's available there, and set up roles for your positions.

Practical tips:

1. Start with the minimum. Granting permissions later is easier than taking them away from someone used to full access.
2. One position, one role. Don't create a role for each person, or you'll get confused.
3. Take special care with “dangerous” actions. Leave erasing guest data, connecting channels and managing staff to the owner or one trusted person.
4. Review every quarter. Positions change, permissions get forgotten.

Invitations by email

There's no need to register a member of staff by hand. In the Staff section you invite a person by email and choose their role, and they sign in with their own account. Signing in with Google is possible, so there's no need to come up with a separate password for the dashboard.

What this gives you:

• everyone has their own login, which means actions are tied to a person;
• when someone leaves, you close access only for them, without touching the others;
• when a person moves from host to manager, they're simply assigned a different role.

The order in practice:

1. Ask the member of staff for a work email (better not a personal one, if you tie it to the position).
2. Send the invitation and choose the role.
3. Ask them to sign in and check that they see exactly what they need.
4. Show them the two or three actions they'll be doing every shift.

The dashboard works on a phone as an app (PWA), so the manager doesn't need to sit at a computer. That's convenient for those who are on their feet all evening.

PIN sign-in on a shared tablet

The floor often has a single tablet at the host stand that people take turns using. Typing a long password every time is inconvenient, and leaving it signed in is unsafe. For such cases GuestKeepr has PIN sign-in: each member of staff has their own short code.

This is how a good scheme for a shared device works:

• each member of staff has their own PIN and doesn't share it with colleagues;
• actions are recorded against a specific person, not against “the tablet”;
• signing out of your session at the end of the shift should be as routine as closing the till.

The PIN has four digits and is quick to enter. So don't use obvious combinations like a birthday or “1234”, and keep the tablet at the stand under supervision, not in a passageway.

How this fits with the live floor is covered in the article about seating guests and working the floor: that's where a shared tablet is needed most often.

The activity log

The log answers the question “who did what”. It shows who did what in the dashboard, for example with a booking. It's useful in three situations:

• A dispute with a guest. “But we booked for nine” can be checked against the records rather than memory.
• Analysing a mistake. The log shows the sequence of actions, and it becomes clear where the failure was: in the process or with the person.
• Training. You can see which operations newcomers find difficult.

How you treat the log matters. If you use it as a tool for finding someone to blame, staff will start hiding mistakes. If you use it as a tool for keeping order, it helps everyone. Tell the team this when you introduce it.

All guests' conversations with the bot are gathered separately in the Conversations section. To learn how to bring order to chats, read the article about WhatsApp chaos at the front desk.

Privacy and guest data

Permissions are also tied to data protection. Each venue's data in GuestKeepr is isolated from other venues' data. The owner can erase all of a guest's data entirely. A venue can also forbid the use of its conversations (in anonymised form) to improve the service.

Think about which members of staff really need the right to erase data: it's better if only one or two people have it. For questions about personal data law, check the requirements with a lawyer in your country: we don't comment on this.

The overall order of setting up a venue, with roles as the last step, is described in the article how to set up a booking bot, and you can read about the product itself on the page of the GuestKeepr virtual front desk.

How to introduce roles without conflict

People don't like having things taken away from them. So introduce roles when the dashboard is launched, not after the first mistakes. Explain to everyone why it's done: not out of distrust, but so that one person's mistake doesn't ruin the shift for everyone.

A short plan for the first week:

1. Hold a five-minute briefing: who sees what and why.
2. Have everyone sign in with their role and check the actions they work with.
3. After a week, ask what they were missing and adjust the permissions.
4. A month later, look at the log and make sure actions are performed by the people they're meant for.

Frequently asked questions