Staff turnover in the hotel restaurant: what the system must not forget when someone leaves

A server announces on Friday that he is not coming back on Monday. He leaves two tables open, a charge to room 214 that was never confirmed and a PIN that half the shift knows because he lent it “just for a minute” more than once. In a hotel restaurant, a departure is not only a human resources formality: it is a pending accounting close that, if nobody does it, shows up weeks later on a guest folio or in the shift close difference.

Why a departure is an accounting event

In a restaurant that lives inside a hotel, everyone with access to the point of sale touches money that does not always pass through their hands. A server posts consumption to a room folio, applies comps, voids items and closes checks that the front desk will collect days later at check-out. When that person leaves, everything left half done stays alive in the system and on the folios.

That is why the controller should learn about a departure the same day the restaurant manager does, not when payroll arrives. What is at stake is not the employment relationship but three concrete things: the checks left open, the charges posted to rooms during the last shifts, and the credential that will keep opening the system if nobody closes it.

None of this assumes bad faith. Most departures are decent people moving to another job or another city. But the system does not read intentions, and turnover in food and beverage is frequent enough that the process has to work without depending on anyone’s memory.

First: deactivate the user, never delete it

The natural reaction is to delete the user from the system so it “no longer shows up”. That is a serious mistake. If you delete the account, every sale, void, comp and room charge that person recorded loses its author. The reports for the last few months end up with a hole where a name used to be, and when the controller asks who applied Saturday’s discount, the answer will be “someone who no longer exists”.

The right move is to deactivate: the credential stops working the instant the departure is marked, but the history is kept intact under that name. In practice this means the PIN, card or fingerprint opens nothing from that moment on, and the name keeps appearing on every earlier movement as if nothing had changed.

Timing matters. If the person worked a last shift and the departure is recorded “whenever they stop by human resources”, there is a window in which someone who no longer belongs to the team still has access to the drawer and to guest folios. That window must be zero. The security page (Security and control) explains how access lifecycle is handled in the hotel point of sale.

The open checks left behind

Everyone who waits tables leaves open checks at the end of a shift: that is normal, because the table keeps ordering after the server goes home. What is not normal is for those checks to be left without an owner. When someone leaves, every open check needs one of three destinations, and the system should force you to choose.

• Transfer it to another active server, recording who receives it and which manager authorizes the handover.
• Close it with its real payment method: cash, card or a room charge with the folio verified on screen.
• Void it with a written reason, if it truly was a mistake, authorized by the manager and never by the departing employee.

What must not exist is a silent fourth way out: the check that stays open for days under the name of someone who is gone and that one day gets closed “so the shift balances”. That check usually ends up as a comp without a reason or as a charge to a room that has already checked out, and that is where the trouble with the guest and the front desk begins.

The special case of the pending room charge

If the departing employee left consumption charged to rooms, each of those charges has a folio behind it. Before the departure is considered closed, the front desk and the restaurant must confirm that each charge belongs to a current stay and that the guest recognizes it. A charge posted to the wrong room during the last shift of a server who is gone is among the hardest disputes to resolve, because there is nobody left to ask. The room charge page (Room charge) describes how the verified folio prevents that charge from being born wrong.

The last shift under review

This is not about suspicion. It is about the fact that the last shift of anyone who leaves is the only one that can no longer be corrected with them present. So it gets reviewed in full, with the same criteria for everyone, and the review is documented. This is the table an orderly controller uses.

The review takes half an hour if the system stores everything with a name. It takes an afternoon if it has to be rebuilt from paper tickets and the cashier’s memory. And it cannot be done at all if the user was deleted. The shift close guide by revenue center (A guide to the shift close by revenue center in a hotel) explains where the figures in the last row come from.

An illustrative example of what a sloppy close costs

The numbers below are invented to show the calculation; they describe no property. Suppose a server leaves and nobody reviews his last month. At month end, the controller finds the following.

Of the total, 1,450 can be collected with effort from the tables if they are still in the hotel; 2,700 was already given away and will not come back; and 3,900 are charges the front desk cannot collect because those guests have left. Eight thousand and fifty units for a single badly closed departure, not counting the time of three people chasing tickets. With the review list applied the same day, the damage shrinks to whatever can be corrected while the table is still seated.

Who does what: manager, controller and front desk

The restaurant manager owns day one: records the departure, assigns a destination to open checks and collects the devices. Not only because it is their team, but because they are the one who knows which tables were seated and which charges were legitimate.

The controller owns the review: runs the last shift and last month reports, signs off that they were seen and files them with the final settlement. If something does not add up, it is raised in writing before the last payroll is paid, not after.

The front desk owns the folios: confirms that every charge from the departing employee sits on a current stay and reports any guest who disputes a consumption they do not recognize. The three roles talk the same day. If one of them finds out a week later, the list no longer helps.

The shared PIN: what turnover exposes

Turnover brings to light a habit that goes unnoticed in daily operation: the borrowed PIN. The new server who has no user yet uses a colleague’s; the cashier who steps away leaves the session open; the captain knows half the team’s PINs “just in case”. While everyone is still in the hotel, nobody notices. When someone leaves, that PIN leaves with them, and with it the trail of who did what.

The fix is not a memo. It is making user setup take under two minutes, so nobody has an excuse to lend theirs, and having the system close the session on its own after a few seconds of inactivity. If every movement carries the name of the person who actually made it, a departure closes in half an hour. If the name is a convention, it never closes.

It also pays, with every departure, to change the PINs of everyone who worked close to that person. Not out of distrust: because a PIN is like a storeroom key, and when someone hands back their copy it is a good moment to change the lock. The controller page (Controller) gathers the reports that make this review possible without leaving the office.

The exit list in five steps

1. Record the departure in the system the moment it is confirmed, with the date and time of the last shift. Access is deactivated; history is kept.
2. List their open checks and assign each one a destination: transfer, close or void with a reason and manager authorization.
3. Review their room charges from the last seven days against the front desk folios, and confirm with the guest any charge still sitting on a current stay.
4. Run the voids, discounts and comps report for their last month, and file it signed by the manager and the controller as the closing of the departure.
5. Change the PINs of the nearby team and verify that no device in the restaurant, the bar or the pool still holds their session.

What to do this week

1. Ask the manager for the list of people who left the restaurant in the last six months and check how many still have an active user in the point of sale.
2. Look for open checks older than two days and write down whose name they sit under.
3. Run the comps and voids by user report for the last month and flag the ones with no reason.
4. Agree with human resources that the departure is recorded in the system on the last day worked, not on settlement day.
5. Write the exit list on one sheet, put it in the manager’s office and apply it to the next departure with no exceptions.

Inn Restaurant keeps the full history of every user when it is deactivated and asks for a destination for every open check before the departure is closed. If you want to see that close happen on a single screen, the 15-minute demo is booked on the contact page (contact).