The hotel network for the restaurant: pool coverage, tablets, and what to do when the internet goes down

A hotel’s network was designed so the guest has internet in the room. Nobody planned it for a server posting a charge from the farthest pool lounger at three in the afternoon, with a hundred people connected to the same access point. And yet that charge is what pays the pool bar’s payroll. If the signal does not reach, the sale goes into a notebook or goes nowhere.

A hotel restaurant does not fit on one network

A street restaurant has a dining room, a kitchen and a register, all under one roof. A hotel restaurant is several things at once: the main dining room, the lobby bar, the pool bar, the terrace, the room service that walks the corridors, and the kitchen that serves them all. Each of those revenue centers has a different network need, and treating them the same is the first cause of “the system went down” complaints.

The second cause is sharing the guest network. The guest network is built for many devices with low priority; the point of sale needs few devices with total priority. When the two share one network, the server’s ticket competes with the video call in room 305, and loses.

What follows does not require being a network engineer. It requires understanding what each zone needs and asking IT or the provider for it in plain words.

Zones: what each revenue center needs

The table says something uncomfortable: the two zones that lose the most sales to weak signal, pool and room service, are the ones almost no hotel designed with the point of sale in mind. An access point was installed so the guest could check email on the lounger, and later someone asked the server to post charges with it.

The pool: where the signal dies and so does the sale

The pool bar has the guest most willing to spend and least willing to get up: in a swimsuit, without a wallet, with the whole afternoon ahead. Their only way to pay is the room charge. If the server cannot post it from the lounger, they have three options: walk to the counter and lose time, write it in a notebook and enter it later, or not offer.

All three cost. The first reduces the orders they can serve per hour. The second produces charges that reach the folio late, without a verified room number, and get disputed at check-out. The third is a sale that never existed. That is why pool coverage is not an IT topic: it is a food and beverage revenue topic.

What works is a dedicated outdoor access point for the pool area, on a network separate from the guest one, placed to cover the last lounger and not just the counter. And a simple test the manager can run alone: stand at the four farthest loungers with the tablet and post a test charge from each. If any fails, the network is not ready. How sales are organized in that zone is detailed on the pool bar page (Pool bar).

Priority: the point of sale before the guest

It sounds wrong put that way, but it is exactly the reverse of how it seems: giving priority to the point of sale is giving priority to the guest, because what the guest wants at the pool is their drink, not ten more megabits for their video. The hotel network can be configured so point of sale traffic goes first, and that configuration costs IT one afternoon of work.

• A separate operations network: a network name known only to restaurant and front desk devices, with its own password.
• Traffic priority: the network team can mark that network as having priority over the guest one. Ask for it in those words.
• No time limit and no captive portal on the operations network: the tablet should not have to log in again every two hours.
• One device, one network: restaurant tablets never connect to the guest network, not even “while it gets fixed”.
• Cable for everything that does not move: the fixed terminal, the kitchen printer and the dining room router go on cable, not wireless.

If the internet provider or the IT team says it cannot be done, the right question is what equipment would be needed to do it. It is almost always one access point and a configuration, not construction work.

Tablets: the ones that last a shift

A hotel server’s tablet has a harder life than a street server’s: sun at the pool, water, sunscreen, sand, and an eight-hour shift without passing near an outlet. What matters in choosing one is not the brand but four things you can check before buying.

1. A battery that lasts the full shift with the screen on. If it lasts six hours, you need one charged spare tablet for every two servers.
2. A case with water and impact protection and a hand strap. The case costs less than a single broken tablet.
3. A screen readable in direct sun. Test it at the pool at two in the afternoon, not in the office.
4. Offline capture: the order is saved on the tablet if the signal drops and sent only when it returns. Without this, everything else matters little.

And one operating rule: tablets are charged in a single place, with one person responsible per shift, and none goes out on the floor with less than a full charge. It is boring and it works.

When the internet fails: the realistic plan

The internet will fail. It is not a matter of whether but of when, and it will almost always be at the moment of highest sales. A realistic contingency plan is one the captain can execute at nine at night without calling anyone. If the plan says “notify IT”, it is not a plan.

What should keep working

With a well-designed point of sale, the restaurant’s local network stays alive even if the hotel’s internet drops: the tablets talk to the kitchen printer and the terminal over the internal network, and orders keep coming out. What stops is whatever needs to leave the hotel: the real-time folio lookup, report delivery, and card payments on terminals that depend on the line.

What has to be decided in advance

1. Room charges during the outage: accepted with name, room and signature on the ticket, and verified against the front desk as soon as the line returns. The front desk reports which rooms leave in the next hour.
2. Card payments: if the bank terminal depends on the internet, offer room charge or cash, and the captain decides case by case.
3. Orders: if the tablets cannot reach the kitchen, fall back to handwritten orders on a printed form that already exists at the station, not in a locked office.
4. Shift close: not closed until the line returns and the contingency tickets are entered. The time of the outage and of recovery is noted.
5. One person in charge: the shift captain declares the contingency and ends it. Nobody else decides.

What exactly happens in each type of system when the power or the line goes, and why a server in the hotel is not the same as the cloud, is explained in the article on cloud or on-premise server (Cloud or a server at the hotel: what happens when the power goes out).

An illustrative example with numbers

The figures below are made up to show the calculation; they describe no hotel. Picture a pool bar that in season posts 35 room charges a day with an average of 280 per charge. That is 35 × 280 = 9,800 in daily sales, and in a 30-day month, 294,000.

Now suppose the signal does not reach half the loungers, and because of that the server stops offering or writes in a notebook on 7 of every 35 orders. Of those 7, say 3 are lost entirely and 4 reach the folio late, of which one is disputed and waived. The daily loss is (3 + 1) × 280 = 1,120, and per month, 33,600. That is more than 11 % of the center’s sales (33,600 ÷ 294,000 = 0.114).

Against that, an outdoor access point, its installation and two cases cost, in the example, less than a single week of losses. The comparison needs no more precision than that: the pool network pays for itself in days, not years.

What to ask IT and what to ask the point of sale provider

The most common confusion is asking the point of sale provider to fix the network, or asking IT to make the system work without a network. Each has its part.

• From IT or the internet provider: a separate operations network, traffic priority, an outdoor access point at the pool, cable in kitchen and dining room, and a coverage test signed off lounger by lounger.
• From the point of sale provider: offline capture on the tablet, a local network that works without internet for orders and printing, automatic sync when the line returns, and a log of what was captured during the outage.
• From both together: a real contingency drill, on a Tuesday at four in the afternoon, disconnecting the hotel’s internet for twenty minutes and watching what happens.

How to frame that conversation with the hotel’s IT team, and which minimum requirements are worth demanding, is developed on the page for IT (IT).

What to do this week

1. Walk every zone of the restaurant and the pool with a tablet and mark on a floor plan where the signal drops. That is your map of lost sales.
2. Ask IT whether the point of sale is on the guest network. If the answer is yes, request a separate network this same week.
3. Check how many tablets finish the shift with battery and how many do not. Buy cases and a spare if needed.
4. Write the contingency plan on one sheet, post it at the register of every revenue center, and read it with the captains.
5. Schedule a twenty-minute internet outage drill during low sales hours, with the front desk informed.

Inn Restaurant captures orders and room charges on the tablet even when the signal is lost, and syncs them with the guest folio as soon as the line returns. In a fifteen-minute demo (contact) you can see what happens on the server’s screen when the hotel’s internet drops mid-afternoon.