The pool menu and the restaurant menu: what they share and what they do not

The guest orders a beer at the pool at two in the afternoon and another one in the hotel restaurant at nine at night. It is the same bottle, from the same purchasing cooler, at the same cost. But at the pool it is served in a plastic cup, charged by a server with a handheld and posted to the room from the lounger; in the restaurant it is served in a mug, charged at the dining room register and sometimes paid by a diner from the street. Is it one product or two? That question decides how the hotel’s catalog is built.

Two menus, one catalog: the difference that matters

The menu is what the guest sees. The catalog is what the hotel maintains. When the two get confused, every revenue center ends up with its own catalog: the restaurant with its 90 products, the pool with its 30, room service with its 40, and the beer existing three times with three codes, three prices someone has to keep identical and three inventory lines that never reconcile.

The right way is the reverse: a single catalog for the whole hotel, and every product with a visibility rule that says at which revenue center it appears, at what time and with what presentation. The pool menu is not a document; it is the catalog view filtered by “pool”. The restaurant menu is the view filtered by “restaurant”. The beer is a single product that appears in both.

This looks like a technical detail and it is not. It is the difference between a hotel that knows how many beers it sold yesterday and a hotel that has to add up three reports to guess.

What they share

Everything that describes the product itself, regardless of where it is served, lives once in the catalog and is shared by every revenue center. Changing it in one place changes it everywhere:

• The product identity: name, description, category and the code purchasing and inventory use.
• The recipe and the cost: the same grams of the same things, no matter which glass it is served in.
• Inventory: the beer that leaves through the pool and the one that leaves through the restaurant deduct from the same store, or from separate stores fed by the same product.
• Allergens and attributes: if the dish is gluten-free in the restaurant, it is gluten-free at the pool; it is not marked again.
• The base price and taxes: the list price is one, and exceptions are handled as rules per revenue center, not as new products.
• Room charge: the same product can be posted to the guest folio from any revenue center, with the same stay verification.

The list is longer than many people expect. Almost everything that defines a product is common. What changes between the pool and the restaurant is a thin layer on top, and that layer is what gets configured per revenue center.

What they do not share

On top of the common product there are decisions that depend on where it is sold. Those do not live on the product; they live on the relationship between the product and the revenue center. There are few of them, but they are what make the pool feel like a pool and the restaurant like a restaurant:

• Visibility: the steak appears in the restaurant and not at the pool; the fruit slush appears at the pool and not in the restaurant.
• Hours: the pool sells from eleven to six; the restaurant opens breakfast at seven and closes dinner at eleven. The same product can be visible at one revenue center and hidden at another depending on the hour.
• Presentation and container: plastic cup at the pool, mug in the restaurant, and that may mean a modifier or a different supply item in that revenue center’s recipe.
• Price, when the hotel decides it does change: a price rule per revenue center, not a duplicated product.
• Ticket routing: the pool order goes to the pool bar; the restaurant order goes to the main kitchen. Same product, different station.
• The predominant form of payment: at the pool almost everything is a room charge; in the restaurant there is cash, card, corporate agreement and folio.

When these six things are handled as attributes of the product–revenue center relationship, the catalog remains one. When they are handled by duplicating the product, the catalog breaks and there is no way to put it back together without manual work.

Visibility per revenue center: how it is configured

On every product card there is a simple matrix: rows of products, columns of revenue centers, and in each cell whether it is visible, during which hours and at what price if it differs from the base. It is a single screen the food and beverage manager can review in full in twenty minutes and that answers the perennial question: why does the guest see this here and not there?

With this matrix, the pool bar menu (Pool bar) generates itself: everything with the “pool” column set to visible, within its hours. If the chef decides the club sandwich is no longer served at the pool, one cell changes and it disappears from that menu immediately, without touching the product or the restaurant.

The price: one or two

There are two schools here and both are legitimate. One says the product price is one across the whole hotel, because a guest who pays differently for the same beer depending on where they order it feels cheated. The other says the pool has a higher cost of service and the price can reflect it. What is not legitimate is resolving the difference by creating two products.

If the hotel decides the price changes, the tool is a price rule tied to the revenue center: “at the pool, +10 over the base price” or “in room service, a fifteen percent service charge”. The rule lives apart from the product, is applied at the moment of sale and is reported as what it is: the same product sold at another price in another place. The mix report still says how many beers were sold in total, and the controller can also see how much extra revenue the rule generated.

The ticket: same product, different station

The guest on the lounger orders a club sandwich and a beer. The pool bar serves the beer; the main kitchen prepares the sandwich, because the pool has no griddle. The order is one, the folio charge is one, but the ticket splits by station according to the revenue center it was ordered from. That is routing configuration, and it also lives on the product–revenue center relationship, not on the product.

What the pool server needs is for the pool menu to appear on the handheld, take the order, verify the room and send. The server does not need to know which station prepares what. What the kitchen needs is for the ticket to say “pool, lounger 14” so the runner knows where to take it. Both come out of the same catalog with different rules.

Reports by revenue center and USALI

The reason the controller insists that the pool and the restaurant be separate revenue centers, even though they share a catalog, is the report. Under the hospitality accounting standard, the pool bar and the restaurant are separate revenue centers, with their own sales, their own cost and their own payroll. If the catalog is duplicated, the report per revenue center comes out right but inventory and cost of sales come out wrong. If the catalog is one and the revenue center is an attribute of every sale, both come out right.

In practice, this means every sale records two things: which product and from which revenue center. The shift close of each revenue center (A guide to the shift close by revenue center in a hotel) adds up only its own sales; the hotel’s mix report adds up every revenue center by product. Both numbers come from the same record, which is why they always reconcile.

Illustrative example: maintenance and shift close

The figures below are invented to show the calculation; they do not describe any hotel. Suppose a hotel with 90 products in the catalog: 60 are sold only in the restaurant, 20 are sold in the restaurant and at the pool, and 10 only at the pool. With separate catalogs, the restaurant maintains 80 cards and the pool 30, that is, 110 records for 90 products. With a single catalog, there are 90 records and one visibility matrix.

The day the beer price goes up, with separate catalogs you have to edit the restaurant card and the pool card, and if there is room service, that one too: three edits and the chance that one gets forgotten. With a single catalog it is one edit. And at that day’s close, the pool reports 8,000 in sales and the restaurant 22,000; the hotel reports 30,000 in food and beverage, and the 55 beers in the mix report are the same 55 that left inventory: 35 through the pool and 20 through the restaurant. Nobody had to add anything by hand.

Room charge from the lounger

What makes the pool menu the most profitable one to maintain properly is that almost everything sold there is posted to the room. Nobody carries a wallet in a swimsuit. If the server can open the guest folio from the handheld, verify the stay and post the charge, the sale happens. If the server has to write it in a notebook and walk to the restaurant register, the sale is lost or reaches the shift close late.

With a single catalog, a charge from the pool is exactly the same charge as one from the restaurant: same product, same folio, same verification, same line on the guest’s bill at check-out. The only difference is the revenue center that was recorded, and that is the one the controller needs to see. The guest, reviewing the bill at the front desk, sees “pool bar, beer” and “restaurant, dinner”, and understands both.

What to do this week

1. Count how many times the best-selling beer exists in your hotel’s point of sale: if it is more than once, you have duplicated catalogs.
2. Draw the visibility matrix for your 30 best-selling products: at which revenue centers they appear, at what hours and whether the price changes.
3. Decide with the owner and the controller whether the pool price is the same as the restaurant price, and write the rule in a single line.
4. Verify that the pool ticket reaches the right station with the lounger number, and that the kitchen can tell it apart.
5. Take yesterday’s close for the pool and the restaurant and compare the beers sold against the ones that left inventory.

In Inn Restaurant the hotel’s catalog is one, and every product has its visibility, hours, price and ticket routing per revenue center, with room charge (Room charge) available from any of them. If you want to see how the pool menu is built without entering a second catalog, book a 15-minute demo (contact).