Staff logins: one till, eleven people

At the end of a busy Saturday, the manager finds three voided bottles of wine on the till, each removed after the bill was printed. Who voided them, and why? The till says "Bar". Eleven people used the till that evening, all signed in as Bar, because one login was quicker than eleven. The question cannot be answered, so it will not be asked, and next Saturday it may happen again.

Shared logins are one of the most common shortcuts in hospitality, and one of the most expensive. They save a second or two at the till, and they cost the ability to know who did anything: who took an order, who gave a discount, who voided a dish, who recorded a payment. When something goes wrong, every member of staff is equally suspect, and nobody can show it was not them.

This guide covers why staff logins should be one per person, how to make signing in quick enough that nobody shares, how PIN codes should work, what an audit trail gives you and how shift reports depend on it. Every venue and figure in it is an example.

Staff share logins because it is quicker, and because nobody stopped them. A busy bar with one till and four bartenders feels slowed down by signing in and out for every drink. So someone signs in as the bar, or as the manager, and everyone uses it.

Sometimes the system encourages it: long passwords, slow sign-in screens or a till that signs out too often. Sometimes the venue does: a new starter given someone else's code on their first night, or a manager's code written on a sticky note under the till.

Each reason is understandable. The result is the same: a till that knows what happened but not who did it.

A shared login costs you every question you might want to ask later. Who gave that table a discount? Who voided the bottle of wine? Who recorded the card payment as cash? Who opened the drawer at eleven o'clock with no sale? With a shared login, the till records the action and loses the person.

It also costs fairness. When money goes missing, a shared login puts everyone under the same suspicion, including the honest majority. Staff who would happily show their record cannot, because there is no record that is theirs.

And it costs the reports. Sales by server, voids by member of staff and tips by person all depend on each action being recorded against the right name.

The rule is simple: every member of staff has their own login, and signs in as themselves every time they use the till. Managers too, and owners. Especially managers and owners, because their logins can do the most.

That includes temporary and agency staff. A new starter should have their own login before their first shift, not borrow someone else's "just for tonight". A login set up in advance takes a minute; one borrowed for a night can hide a problem for months.

When someone leaves, their login is removed on their last day. Old logins left active are one of the most common gaps in a venue's security.

Logins matter on every screen, not only the till. The host stand, the kitchen screens, the reporting dashboard and the menu editor each let people change something. A booking moved, a dish's price changed or a report exported should each be recorded against the person who did it.

Give each person access to the screens their role needs, and nothing more. A server does not need the menu editor; a cook does not need the payment reports. Fewer people with access to each screen means fewer questions when something changes unexpectedly.

Where tips are recorded on the till, individual logins are what make sharing them fair. Tips recorded against the right server can be shared according to the venue's policy; tips recorded against a shared login cannot be traced to anyone.

Even where tips are handled outside the till, the sales recorded against each server help when tips are shared by sales. A shared login makes every fair method harder.

People share logins when signing in is slow. The fix is to make it quick. On a shared till, the best approach is usually a screen that shows the names of the people who can use it: tap your name, type a short code, and you are in. Two seconds.

Long passwords, typed on a touchscreen in the middle of a rush, do not survive a busy night. Staff will find a way around them. A short code with a tap on a name is secure enough for the till, as long as each person's code is their own.

The till should also make it easy to switch: the next person taps their name and signs in, and the previous person is signed out. No menus, no logging out by hand.

PIN codes are the usual way to sign in at a shared till: four to six digits, known only to the person. They work well, if they stay private.

Let each person set their own PIN, rather than being given one by a manager, so nobody else knows it. Avoid obvious codes such as 1234 or a birthday. Never write a code on a note near the till. If someone suspects their code is known, they should change it at once.

Explain why it matters. A server who understands that their PIN protects them, by proving which actions were theirs, is far more careful with it than one who sees it as a nuisance.

A till left signed in when its user walks away is as bad as a shared login: the next person to touch it acts as the last person to sign in. Tills should lock themselves after a short time untouched, and staff should lock them by hand when they step away.

On a busy bar till, a short lock time makes sense, because the till changes hands constantly. On a host stand, where one person works for a long stretch, a longer one is fine. The aim is that nobody can act as someone else by accident.

Bars are where shared logins are most common, because drinks are made quickly and bartenders work side by side at one till. They are also where shared logins cost most, because bar stock is easy to give away and hard to count.

Make bar logins especially quick: a tap on a name and a short code, with the till switching to the next person as soon as they sign in. A bartender who can sign in faster than they can pour a drink has no reason to share.

An audit trail is the record of who did what, and when: every order, change, void, comp, discount, payment and drawer opening, each with a name and a time. With individual logins, the till builds it automatically. The general idea of an audit trail is simple: a record you can follow back to the person and the moment.

The audit trail answers questions. It shows who voided the wine and what reason they gave. It shows which server's tables had the most comps. It shows when the drawer was opened without a sale. Most of the time, it simply confirms that everything was fine.

Without individual logins, there is no audit trail worth the name, only a list of actions by "Bar".

Shift reports, the summaries a manager reads at the end of each shift, depend on knowing who did what. Sales by server show who sold what. Voids and comps by member of staff show where the giveaways and corrections came from. Payments by member show who took which money.

With a shared login, all of these collapse into one line. The manager can see the totals but not the people, and cannot tell whether a high void count is one person's mistakes or a pattern across the team. Our guide to POS reports a manager should read daily covers which reports to read.

Individual logins are also what make pos permissions work. Permissions decide what each role can do: a server can take orders, a supervisor can comp, a manager can void after sending. But permissions follow the person who is signed in. If everyone signs in as the manager, everyone has the manager's permissions.

Set up logins and roles together: each person signs in as themselves, and their role decides what they can do. Our guide to POS permissions: who can void, who cannot covers how to set the roles.

The manager's code deserves special care, because it can do the most. It should never be shared with staff, never written down near the till and never used by someone else to approve their own void.

If a manager has to approve an action at the till, they should enter their own code themselves, in person. A manager who tells a server their code to save walking to the till has given that server the manager's permissions for as long as the code stays the same.

Change the manager's code if there is any chance it is known.

Individual logins protect staff as well as the business. A server whose record is clean can show it when money goes missing; one who shared a login cannot. A bartender accused of over-pouring can point to the record of what they rang in.

Explain this to the team. Most staff, once they see that their own login protects them, become its strongest supporters. The ones who resist are often the ones the record would most help.

Agency and temporary staff are often given a shared login, because setting up a login for someone working one shift feels like too much effort. It is not. A login takes a minute to create and a minute to remove, and it gives every action of a temporary worker a name.

Create the login before the shift, give the person a short briefing on signing in and locking the till, and remove it at the end of the shift or the end of the booking.

Explain logins on a new starter's first day. Show them how to sign in, how to lock the till when they step away and how to change their PIN. Explain why their login matters: it protects them, it makes the reports fair and it lets the team answer questions when something goes wrong.

Make it part of the standards: every person signs in as themselves, every time, and locks the till when they walk away. Our guide to onboarding staff so night one is not chaos covers the rest of the first week.

People forget their PINs. Have a quick way for them to reset it, without borrowing someone else's login in the meantime. If the reset needs a manager, make sure a manager is always available during service.

A server who cannot sign in at the start of a busy shift will be tempted to use someone else's login. A quick reset removes the temptation.

Every few months, review the list of logins. Is everyone on it still working at the venue? Does each person have the right role? Are there any logins that nobody recognises, or that belong to people who left long ago?

Remove what should not be there, fix the roles that are wrong and record what you changed. Half an hour every quarter keeps the list clean.

As a venue grows, more people use the till, and the case for individual logins grows with it. Eleven people sharing one login is bad; thirty sharing one is impossible to manage. A group with several venues needs each person's access to match the venues they work at.

Set up individual logins from the first day, even when the team is small. Changing habits later, when the team is large and used to sharing, is much harder than starting well.

The audit trail is a tool for understanding, not for catching people out. Most of what it shows is ordinary: mistakes corrected, guests looked after, a busy night recorded accurately. When it shows something unusual, ask about it privately and listen to the answer.

Use it to help staff as well as to check them. A server with many voids may need help with the till's layout; one with many comps may be handling the most difficult tables. The record tells you where to look; the conversation tells you what it means.

Sometimes the audit trail reveals a real problem: a pattern of voids after the bill is printed, cash payments that do not reach the drawer, discounts given without reason. Handle it carefully: look at the evidence over weeks, consider innocent explanations, talk to the person privately and follow your employment policies.

Without individual logins, none of that is possible. The problem continues, the team stays under suspicion and the honest staff have no way to show it was not them. Our guide to spot checks: twenty lines, ten minutes, every week covers comparing stock with sales to find gaps.

The cost of shared logins is rarely seen in one night. It shows over months: a stock gap that cannot be explained, voids and discounts nobody can account for, an honest team member who leaves because they felt suspected, a problem that grows because nobody could ask the right question.

Individual logins cost almost nothing: a few seconds at the till and a few minutes of setup per person. Few changes in a restaurant offer so much for so little.

An invented cocktail bar runs one till with a shared login called Bar. Its stock counts show a steady gap in spirits, and its voids are high, but nobody can say who made them or why. Two bartenders leave in a year, one saying they felt watched without being trusted.

The bar gives every member of staff their own PIN, sets the till to show each person's name and lock itself after a couple of minutes untouched, and asks each person to choose their own code. Voids now carry a name and a reason, and the manager reads voids and comps by member at the end of each shift.

Within a month, voids fall by more than half, most of them corrections that are now caught before the drinks are poured. The spirits gap narrows. The team says the change felt fair, because everyone's record is now their own.

In servearound, a till or a host stand shows the names of the people who can work it. Each person taps their own name and enters their PIN, which they set themselves in servearound under Account, then Security, and until the screen locks, every order, void and booking change is recorded as theirs. The screen locks when its user locks it by hand, when the next person signs in, or when it has sat untouched for two minutes on a till or ten on a host stand, and a check half built stays there for whoever signs in next.

Each person's role decides what they can do, and only people whose role lets them take orders appear on a till. Payment analytics show takings, voids and comps by member of staff, and order analytics list each check with the server who rang it, so the shift report carries names rather than "Bar". See Order Fulfillment.

Because you lose the ability to know who did anything, and every member of staff falls under the same suspicion when something goes wrong.

A screen showing each person's name, a tap and a short PIN. Two seconds.

Each person sets their own, so nobody else knows it.

Yes, after a short time untouched, so nobody acts as someone else by accident.

The record of who did what and when, built automatically when everyone signs in as themselves.

Yes, especially managers, because their logins can do the most.

Remove their login on their last day, and review all logins every few months.

No. It is about understanding what happened, protecting honest staff and finding where help is needed.

A shared login saves a second at the till and costs every answer later: who voided, who discounted, who took the payment. Give every person their own login, managers and owners included, and make signing in quick: a name to tap and a private PIN, with the till locking itself when left untouched.

Individual staff logins build an audit trail automatically, make shift reports and permissions meaningful, and protect honest staff when something goes missing. Explain them on the first day, review them every few months and use the record to understand, not to accuse.