How to run a live rehearsal of the point of sale with real orders before the first service

The new system in your hotel’s restaurant is configured, the menu is loaded and the servers have been trained. Only one thing is missing, the only thing that really says whether it is ready: a service. Not one with guests, not yet. One with real orders, a real kitchen, a real register and a real front desk, at a time when mistakes cost nothing. That is the live rehearsal, and almost everything that goes wrong on day one would have shown up there.

What a live rehearsal is and what it is not

A live rehearsal is a complete simulation of service on the new system, done in the restaurant itself, with the team that will operate it and on the same devices they will use. Tables are opened, orders are entered, the kitchen receives tickets, payments are taken in all three methods and the front desk verifies that the charges reached the folio. At the end, the shift close is run as if it were real.

It is not a training session. In training someone explains and the rest listen. In the rehearsal nobody explains: everyone does their job and the lead writes down what gets stuck. Nor is it a desk test where the manager enters three tickets in the office. That test shows the system turns on; it does not show whether the server can find the room charge button with a tray in the other hand.

And it is not the first service with guests. Some hotels go straight into a “test breakfast” with real guests, and when something fails, the guest waits. The rehearsal exists so that day never happens. The implementation page (implementacion) describes where the rehearsal falls within the full calendar.

The scenario: when, where and with which orders

The best moment is the afternoon before go-live, between the end of lunch and the start of dinner, or the morning before if the first service will be breakfast. You need between ninety minutes and two hours: thirty for the simulated service, thirty for the close and the cross-check with the front desk, and the rest to go through the list of what failed and decide.

The place is the restaurant itself, with the dining room set, the kitchen on and the register open with a real float. The devices are the final ones: if the server will use a tablet, rehearse on the tablet; if the kitchen ticket will come out of the kitchen printer, rehearse on that printer. A rehearsal on an office computer tests something else.

The real orders

The orders have to be real, with dishes the kitchen actually prepares, even in small portions. The reason is simple: the ticket that reaches the kitchen is the proof that the order traveled complete, with modifiers and notes. If the kitchen prepares nothing, nobody checks the ticket, and the “no onion” that did not print shows up on day one with an allergic guest.

Whatever is consumed in the rehearsal is eaten by the team when it ends. It is a small cost in ingredients and it gets recorded as internal consumption with an authorized comp, which also tests the comp flow. Eight or ten orders are enough if they are well chosen: two simple, two with modifiers, two with split checks, two with room charge and one that gets voided after being sent to the kitchen.

Who takes part and what each person does

The rehearsal fails if two people are missing: the one from the front desk and the one from the kitchen. Without the front desk, nobody can confirm that the charge reached the correct folio, and that is the single most important test in a hotel restaurant. Without the kitchen, nobody checks the ticket. The rest of the team can be reduced, but those two roles cannot be replaced by someone “pretending”.

One detail that helps: the servers who rehearse should be one of the fastest and one of the most reluctant about the change. The fast one finds the shortcuts; the reluctant one finds the real obstacles, and if they approve, the rest of the team approves. Putting only the enthusiasts in the rehearsal gives a result that day one will not repeat.

The test list, in order

The tests go from simple to complex and each one is marked as passed or failed on the spot, not at the end. If a test fails, it gets written down and the next one follows; the rehearsal does not stop to fix things, because fixing on the fly hides what is still left to test.

1. Shift opening: the cashier records the float and the system shows it. Without this, the close will not balance by design.
2. Simple order: a server opens a table, enters two dishes and a drink, sends to the kitchen. The kitchen confirms the ticket arrived complete and legible.
3. Order with modifiers and notes: a dish without one ingredient and a free-text allergy note. The kitchen confirms both appear on the ticket.
4. Adding to an open tab: a second round is ordered at the same table. It must add to the same ticket, not open another.
5. Table move and table merge: a couple moves to another table and then joins another party. The ticket follows the people.
6. Split check: a table of four pays in three parts, one in cash, one by card and one to the room. The system must allow it without calling the manager.
7. Room charge with verification: the server looks up the room, sees the guest’s name and the current stay, posts the charge. The front desk opens the folio and confirms amount and room in under a minute.
8. Charge to an empty room: the server tries to post to a room with no guest. The system must reject it; if it accepts it, that is a serious failure.
9. Void after sending to the kitchen: a dish already fired gets voided. It must ask for authorization and be logged with name and reason.
10. Comp: a comp is applied to the rehearsal consumption. It must ask for authorization and appear on the close as a comp, not as a discount or a zero sale.
11. Tip: on a card payment the tip is entered. It must appear separate from sales on the close.
12. Simulated check-out: the front desk checks out the room with the charge and confirms the restaurant consumption appears on the guest’s final bill.
13. Shift close: the cashier closes. Cash, cards and room charges must match what happened, with no manual adjustments.

Tests seven, eight and twelve are the ones that set a hotel restaurant rehearsal apart from a street restaurant one. If you have to cut for time, cut the table tests, never the folio tests. The room charge page (Room charge) explains why verifying the stay before the charge is the test that protects the most consumption.

The criteria for passing

Passing does not mean everything went perfectly. It means the failures that remain are the kind fixed with a conversation or a permission change, and none are the kind that leave a guest waiting or a charge without a folio. It helps to have the criteria written before the rehearsal so the decision does not depend on the mood at the end of the afternoon.

• Every room charge in the rehearsal reached the correct folio with the correct amount, and the front desk confirmed it looking at the screen, not by word of mouth.
• The attempt to charge an empty room was rejected by the system.
• Every ticket reached the kitchen complete, with modifiers and notes.
• The close balanced in cash, cards and room charges without any manual adjustment.
• Voids and comps were logged with the name of whoever authorized them and a reason.
• No server needed the manager to open, split, move a table or post to a room.
• The simple order, from opening the table to sending to the kitchen, took the reluctant server less time than on the previous system, or about the same.

If the first four criteria are met, you go live even if the other three fail, with the list of corrections for the first week. If any of the first four fails, you fix it and repeat the rehearsal, even a shorter one, before the first service. A charge that does not reach the folio is not a detail: it is consumption the hotel will not collect.

An illustrative example with numbers

The figures below are invented to show how the rehearsal close is read. They are not from any hotel. Suppose 10 orders were entered in the rehearsal for a total of 3,200. 800 was collected in cash, 1,200 by card with a 120 tip, 900 was posted to two rooms, and 300 was applied as a comp for the team’s internal consumption.

The close should show net sales of 2,900 (3,200 minus the 300 comp), with 800 in cash, 1,200 in cards, 900 in room charges and 300 in comps, and the 120 tip on its own line, outside of sales. The drawer should hold the 500 float plus 800, that is, 1,300. The front desk should see 900 split across two folios, for example 550 in one room and 350 in another.

If the close shows sales of 3,020, the tip was entered as a sale. If the drawer holds 800, the float was not recorded. If the front desk sees 550 and not the 350, the second charge was posted to the wrong room or was not confirmed. Every rehearsal difference points to a specific test on the list, and that is what makes it useful: it does not tell you “something is wrong”, it tells you what.

What to do with what fails

At the end, the lead reads the failure list out loud and sorts it into three groups. Configuration failures, such as an open permission or a modifier that does not travel to the kitchen, are fixed that same afternoon with whoever configured the system. Learning failures, such as the button the server could not find, are solved with five minutes in front of the screen with that person. Process failures, such as the front desk not knowing where to see the charges, are solved by agreeing who does what, and the page for the front desk (Front desk) helps set that agreement.

What you should not do is keep the list to “look at next week”. The rehearsal loses almost all its value if the failures are not fixed before the first service, because the first service will repeat them with guests watching. And it pays to keep the list with its date: when the first real close arrives, comparing what failed in the rehearsal with what fails live says a lot about how well it was fixed.

What to do this week

1. Set the date and time of the rehearsal for the afternoon or morning before the first service, and block ninety minutes on the front desk and kitchen schedules.
2. Write the ten rehearsal orders with their modifiers, notes and payment method, and ask the kitchen for the ingredients in small portions.
3. Choose the two servers: the fastest and the most reluctant, and tell them they are rehearsing, not being evaluated.
4. Print the list of thirteen tests and the seven criteria, and hand them to the lead to mark on the spot.
5. Confirm with the front desk that they will have access to the folios during the rehearsal and will run a simulated check-out of a room with a charge.
6. Reserve one hour at the end to fix configuration and permissions before the first service, with whoever configured the system available.

Inn Restaurant verifies the guest’s stay before posting any charge and shows the front desk every restaurant consumption on the folio the moment it happens, so the rehearsal focuses on the people and not on chasing charges. If you want to see how this rehearsal would run with your menu, the fifteen-minute demo is scheduled on the contact page (contact).