A checklist for switching point of sale without closing the restaurant

The reason many hotel restaurants stay on a system they hate is fear of the switch: “I cannot close for three days.” They are right not to close. They are wrong to think it is necessary. A well-planned point of sale change happens with the restaurant open, starts with a single revenue center and ends when the last cashier closes their first shift without calling anyone. This is the list.

Three weeks out: inventory what you have

Before touching the new system, write down what you have in the old one. Not what you think you have: what is actually there.

• The full menu, with current prices and categories. Mark what no longer sells: you will not migrate it.
• The modifiers: meat temperature, no onion, extra cheese. There are more than you think.
• The revenue centers: restaurant, bar, pool, room service, coffee shop. Each with its hours and its printer.
• The people: who collects, who voids, who applies discounts, who closes the shift. Write down what they do today, not their title.
• The active corporate agreements and the accounts with open credit, with the balance as of today.
• The devices: tablets, computers, kitchen and receipt printers, card terminals. Model and age.
• The reports someone actually opens every week. The rest do not matter.

Two weeks out: load and configure

1. Load the menu into the new system with the categories you are going to report: food on one side, beverage on the other, alcohol separate. If the system reports under the hospitality standard, this is your one chance to get it right from the start.
2. Draw the floor plan and create each revenue center with its own drawer and float.
3. Add your team with permissions per person: collect without voiding, void with a reason, view reports without operating. Start restrictive; opening a permission is easy, closing it after a problem is not.
4. Enter the corporate agreements by category, with their hierarchy. This is the moment to read them calmly, not on day one.
5. Configure kitchen printers or screens by station. A dish that comes out of the wrong printer takes longer to fix than loading the whole menu.
6. Decide which reports you will look at in the first week. No more than three.

One week out: the live rehearsal

Pick a quiet shift, a Tuesday mid-afternoon, and run both systems at once at a single revenue center. Every check is captured in both. At shift close, compare: total sales, sales by payment method, tips, room charges, expected cash. Whatever differences appear are configuration, not operation, and you will fix them calmly.

In that same rehearsal, test what always fails: splitting a check four ways, moving a dish to another table without the kitchen making it again, posting to a room under an agreement, applying a comp with a reason, closing a shift with a difference. If any of that cannot be done or requires calling someone, you are not ready. Repeat the rehearsal until the cashier closes on their own.

Day one: a single revenue center

Do not switch the whole property on the same day. Start with the simplest, lowest-volume revenue center: the breakfast coffee shop or the pool bar. That day, everything else stays on the old system. The team at the new revenue center has someone beside them for the whole shift, and that person does not take orders: they only watch and write down what got stuck.

At close, review that revenue center’s shift with the cashier. If it balances without explanations, the second revenue center goes live the next day. If it does not, fix it before adding another. A property with four revenue centers finishes the migration in one or two weeks without having closed a single hour.

What to migrate and what not to

The temptation to migrate “everything” is why migrations stretch into months. The sales history from the old system is exported, saved in a dated file and consulted when needed. The new system starts clean, with the correct open balances, and in thirty days it has a history of its own.

The first week with everything on the new system

• Review every close at every revenue center, every day. This is the week when misassigned permissions and crossed printers show up.
• Ask the servers what took more taps than before. It is almost always a modifier that ended up in the wrong place.
• Compare that week’s revenue per occupied room with the previous one. Not to judge, but to confirm that room charges are counting as restaurant sales.
• Confirm with the front desk that charges appear on folios with the check detail. If the front desk has to call the restaurant to explain a charge, something is missing.
• Turn off the old system only when the last revenue center has closed three clean shifts.

What to ask the vendor before you start

• Can I load the menu myself, or do I depend on an implementer?
• Can I run one revenue center on the new system and the rest on the old one for a week?
• Which devices do I need to buy? If the answer is “none, it runs in any browser”, your migration just got cheaper and safer.
• Are permissions defined per person and per revenue center, or are there three fixed profiles?
• Who answers me on day one at seven in the morning?

Inn Restaurant loads from any browser, with no proprietary hardware and no implementer, and each revenue center goes live when it is ready. See what a typical implementation looks like (/implementacion) and what you need before starting (/que-necesito). And the question worth asking before you switch: of every hundred guests who slept with you last night, how many ate with you, and does your current system know?