The server who also covers the pool: one user, several revenue centers, one close

At eight in the morning she serves breakfast in the restaurant. At noon she goes up to the pool with the handheld. At five she covers the bar until the bartender arrives. It is the same person, with the same cash float, serving the same guests in three revenue centers of the hotel. The trouble starts when the system forces her to be three different users with three closes that nobody knows how to add up.

A real-size hotel does not have a team per revenue center: it has a team

In a large resort every revenue center has its own brigade and its own cashier. In the hotel with twenty, forty or eighty rooms that does not exist. What exists is a team of five or six people who split the restaurant, the bar, the terrace, the pool and room service according to the hour, the occupancy and who called in sick that day.

That is not a shortcoming: it is the right way to operate when demand moves around the property during the day. Breakfast fills the restaurant, the sun fills the pool, the evening fills the bar. Placing a fixed person in each outlet would mean paying three salaries to serve the demand of one.

What is a shortcoming is a point of sale designed for the large resort rather than for this hotel. When every outlet is an independent register with its own users, the person who moves has to log out, log in somewhere else, remember another PIN and, at the end of the day, hand in three closes that the controller has to add by hand.

One user, not three: identity belongs to the person

The principle is simple: the user represents the person, not the spot where they are standing. A server has a name, a PIN and a history. What changes during the day is the revenue center they are selling from, and that should be recorded by each sale, not by the credential.

When identity belongs to the person, the month-end report can answer questions that are impossible with three users: how much did this person sell in total, how many comps did they apply today regardless of where, how many room charges did they post from the pool versus from the restaurant. And when the departure comes, it is processed once.

The guest experience changes too. The family that had breakfast with a server and sees her again at the pool expects “the morning check” and “the pool stuff” to land on the same room folio without repeating the room number three times. That only happens if the person who served them is the same person in the system.

The revenue center is decided by the check, not by the server

Here is the part that usually goes wrong. If the server picks “which outlet am I in” at the start of the shift, everything sold until they remember to switch goes to the wrong outlet. The nine o’clock breakfasts show up under the pool and the three o’clock beers show up under the restaurant. The report by revenue center, which is the foundation of the hospitality accounting standard, becomes useless.

The right design is for the revenue center to be determined by the check, not by the session. A check opened at table 4 of the restaurant belongs to the restaurant. A check opened at lounger 12 belongs to the pool. The server decides nothing: they open the check where the guest is and the system knows which revenue center that sale goes to, regardless of who took it or from which device.

With this design, one person can have two checks open in the restaurant and three at the pool at the same time, and each one reports where it belongs. The tables page (Tables and floor) shows how each outlet’s floor map defines where a check belongs, and the pool bar page (Pool bar) how you sell from the lounger without the guest carrying a wallet.

Permissions per outlet: what they can do here is not what they can do there

One user does not mean the same permissions everywhere. In the restaurant, the server can open checks, add items and request the room charge. At the bar, perhaps they should not be able to apply the welcome comp without the manager’s approval. At the pool, perhaps they can close in cash because there is no cashier nearby, but they cannot void without a reason.

Permissions, then, are defined by role and by revenue center, and they combine. The person is one; their powers depend on where the check they are touching lives. This avoids the classic mistake of granting “permission for everything” to whoever moves around, only because they need it in one of the outlets.

• Open a check and add items: in every outlet where they have a shift.
• Request a room charge with a verified folio: in every outlet, because it is the guest’s most common payment method.
• Close in cash: only where there is no cashier, with the cash declared at the close.
• Apply a discount or comp: only with manager authorization, in any outlet.
• Void items already sent to the kitchen or the bar: with a mandatory reason and authorization, in any outlet.

The cash: one float, one person, one close

If the person is one, so is their money. At the start of the shift they receive a cash float under their name. During the day they collect cash at the pool, cards in the restaurant and post room charges in all three outlets. At the end they hand in one envelope, declare one cash amount and sign one close.

That single close does not lose the detail per outlet: the system breaks it down. The controller sees how much that person sold in the restaurant, at the pool and at the bar, and each outlet adds up with the other servers’ sales to build the day’s report. The shift close guide by revenue center (A guide to the shift close by revenue center in a hotel) develops that double reading: by person for the envelope, by outlet for the accounting standard.

An illustrative example of one shift across three outlets

The figures below are invented to show the arithmetic. A server works from eight in the morning to seven in the evening and passes through three revenue centers of the hotel. She receives a cash float of 500 at the start.

The envelope she hands in at the end of the day should hold 500 of float plus 1,500 of cash collected: 2,000. The 2,700 in cards reconcile against the bank terminal. The 7,800 in room charges never pass through her hands: they live on the folios and the front desk will collect them when each guest checks out. One close, three outlets, four ways to read it.

Now picture the same shift with three users and three registers. Three floats of 500, three envelopes, three closes, three chances for pool cash to end up declared under the restaurant. And at month end, when the controller wants to know how much this person sold, they will have to add three reports that were never designed to be added.

What breaks when every outlet is an island

The first thing that breaks is the room charge. If the pool system does not see the same folios as the restaurant system, the guest has to give their room number and name at every outlet, and in one of them the charge will go to the wrong room or into a notebook. Food and beverage revenue per occupied room, the metric the owner looks at every month, ends up calculated on incomplete data.

The second thing that breaks is accountability for cash. When one person signs three closes, none of them is really theirs. The pool shortage is explained away with the bar overage and nobody knows whether there was a real shortage at all. The third is the operation itself: switching sessions with the handheld in one hand and a guest waiting by the lounger is time paid for in orders never taken.

And the last thing that breaks is the team’s trust. The server who moves gets chased about three closes; the one who stays in one outlet, about one. It is unfair and it shows. The cash page (Cash and shift close) explains how the float is assigned to the person and the close is read by outlet without anyone having to choose between the two.

What to do this week

1. List the restaurant staff who cover more than one revenue center during the week and how many users each of them has in the system.
2. Take yesterday’s close and check whether pool cash and restaurant cash were declared in separate envelopes by the same person.
3. Review five room charges posted from the pool and confirm they reached the right folio using the same data the restaurant uses.
4. Write on one sheet what a server can do in each outlet: open, close in cash, apply a comp, void. If the answer is “everything everywhere”, there is work to do.
5. Ask the team how much time they lose switching sessions when they move. The answer is usually surprising.

In Inn Restaurant the user is the person, the check defines the revenue center and the close is handed in once and read by outlet. If you want to watch the same server sell in the restaurant and at the pool with a single PIN, the 15-minute demo is booked on the contact page (contact).