Team resistance to the new system: what servers say and what actually worries them

The new system in your hotel’s restaurant has been live for three days and the most senior server has already said, in front of everyone, that the old one was better. Two more nod. The manager takes it as an attitude problem and the owner starts to doubt the purchase. It is almost never attitude. It is that nobody has answered three concrete questions: what happens to my tip, what will I be able to do without asking permission and how long will each table take me.

What they say and what they mean

Resistance from a floor team is almost never expressed as it is. A server does not walk into the meeting and say “I am afraid the card tip will be paid to me fifteen days late”. They say “the system is slow”. They do not say “I am embarrassed to ask the manager for permission in front of the guest to split a check”. They say “with the old one I could”. The job of the manager and the implementation lead is to translate.

That translation follows a fairly stable pattern. Behind almost every phrase of resistance there is one of four worries: the tip, the permissions, the speed or the fear of a mistake with personal consequences, which in a hotel restaurant is almost always the charge posted to the wrong room. The table below puts them side by side.

The tip: worry number one

In a hotel restaurant the tip has a complication that does not exist on the street: a large share of consumption is charged to the room and the guest pays at the front desk on check-out, sometimes three days later. On the old system, the server wrote their tip on the paper ticket and trusted the front desk to record it. Sometimes yes, sometimes no, and nobody could prove anything. The new system changes that mechanism, and the first thing the server wants to know is whether they come out ahead or behind.

What they are really asking is four things. Whether the card tip is recorded under their name. Whether the room charge tip reaches their report even though the guest pays on departure. When it is paid and by whom. And whether they can see for themselves how much they have accumulated, without asking the cashier for the paper. A system that answers those four questions with a report by server turns the most resistant person into the biggest advocate, because for the first time they have evidence of what is owed to them.

What does not work is saying “do not worry, the tip is the same”. It is not the same: it is more visible, and that visibility has to be explained with the report in hand on day one, not when the first payment arrives. The page for the server (Server) describes what every server should see of their own tip when closing the shift.

Permissions: “now everything asks for permission”

The second cause of resistance is the easiest to solve and the most ignored. When the system is configured before go-live, permissions tend to be left closed “for safety”: splitting a check asks for authorization, moving a table asks for authorization, adding an item to a closed check asks for authorization. Every one of those authorizations is the server walking over to the manager in front of a guest who is waiting. Three times per shift and the server already hates the system, and rightly so.

The rule that works is to separate two lists. The short one, of what should ask for authorization because that is where consumption leaks: voiding something already sent to the kitchen, giving a comp, applying a discount outside an agreement, reopening a closed ticket, changing the payment method on a paid ticket. And the long one, of everything else, which the server does alone. If a permission is on the long list and the system asks for it, it gets opened that same week.

It helps to tell the team that distinction clearly: what asks for permission asks in order to protect the hotel’s consumption, not because the server is distrusted. And what does not ask for it will not ask for it. A team that understands why each authorization exists accepts it; one that is only told “that is how the system comes” resents it.

Speed: “with a tray in my hand there is no time”

The speed complaint is real during the first week and false afterwards, almost always. It is real because the server is still looking for buttons and every order takes twice as long. It is false afterwards because within two weeks the taps become reflex and the simple order takes the same or less than before. The problem is that the complaint is voiced in the first week and the decision to “go back to the old one” sometimes is too.

The way to address it is to measure instead of argue. On day one, time the simple order, from opening the table to sending to the kitchen, with the most reluctant server. Write it down. On day seven, time it again. If it dropped, the complaint solved itself and the number proves it. If it did not drop, something is off in the configuration: a menu with too many levels, a mandatory modifier that should not be mandatory, a slow device. That gets fixed, and it gets measured again.

What is slower by design

There is one step that takes longer in a hotel restaurant than on the street, and it is best said up front: room charge with verification. Look up the room, see the guest’s name, confirm the stay is current and post. That is a few seconds more than typing a number into a text field. Those seconds are what prevent consumption from being charged to an empty room or to a guest who already checked out, and they are what protect the server from the next worry.

The fear of the wrong charge

It is the worry least said out loud and the one that weighs most in a hotel restaurant. On the old system, a charge to the wrong room was discovered by the front desk the next day, sometimes after the guest had left, and in more than one hotel the custom was to deduct it from the server. That is why many servers preferred to close in cash or ask for a card “to avoid problems”, and the hotel lost room charges it actually wanted.

The new system changes this if the charge is verified against the stay before it is posted: the server sees the name, the guest confirms with “to my room, please”, and the charge is tied to the correct folio. The rule to say out loud to the team is that a charge verified on screen is deducted from nobody, because the system does not allow posting to a room with no guest. The room charge page (Room charge) explains that verification step by step, and showing it to the team removes more resistance than any speech.

An illustrative example with numbers

The figures below are invented to show the tip arithmetic, which is where resistance is most often decided. They are not from any hotel. Suppose a server who in one week serves consumption of 20,000, of which 8,000 is paid in cash, 7,000 by card and 5,000 as room charges. Suppose an average tip of 10 % across all payment methods.

The cash tip, 800, they keep on the spot and it was never the problem. The card tip, 700, on the old system depended on the cashier recording it properly; on the new one it is recorded under their name on every ticket. The room charge tip, 500, was the one that got lost: the guest wrote it on the ticket, the ticket traveled to the front desk and part of it was never recorded. If on the old system half of that part was lost, the server stopped collecting 250 per week, 1,000 per month, without knowing it for sure.

With the charge tied to the folio, the 500 shows on their report and is paid on the agreed date. The server who said “the old one was better” earns 1,000 more per month on the new one, and can see it on screen. That is the argument that convinces, and it is arithmetic, not persuasion.

How each one gets addressed, one by one

Resistance is not solved in a general meeting. It is solved server by server, with each person’s concrete worry and with evidence, in the order that weighs most. What follows is the order that tends to work in the first week.

• On day one, before the shift, each server is shown their tip report and told the date and method of payment for card and room charge tips.
• On day two the short list of what asks for authorization is reviewed with the team and the reason for each action is explained; everything not on the list gets opened.
• On day three the simple order is timed with the most reluctant server, in front of them, and the time is written down with the date to compare after a week.
• Room charge with verification is demonstrated, an attempt is made to charge an empty room so they see the system reject it, and it is said out loud that a verified charge is not deducted.
• Training for those who say “I am not a computer person” is done in pairs with a colleague, not with the manager and not in front of the team.
• On day seven the simple order is measured again and the result is shared with the team, good or bad, along with what will be corrected.

None of that is technology. It is managing people with data in hand. And that is why the implementation cannot be led by someone who only knows the system: it is led by whoever knows the team and has the tip report and the stopwatch, as the implementation page (implementacion) describes.

What to do this week

1. Write the short list of actions that ask for authorization and check against the system that nothing else asks for it; open whatever is left over before the next shift.
2. Define the date and method of payment for card and room charge tips, and tell the team before the shift, with the report by server on screen.
3. Time the simple order with the most reluctant server and write down the time with the date; repeat after seven days.
4. Show the team the attempt to charge an empty room and the system rejecting it, and set the rule that a verified charge is not deducted.
5. Assign a training partner to every server who declares themselves “not a computer person”, with no manager present.
6. Turn every phrase of resistance you hear into the worry behind it and write it down; that list is your agenda for the second week.

Inn Restaurant shows every server their tip by payment method, room charge included, and verifies the guest’s stay before posting any charge, which are the two things that remove the most resistance on the floor. If you want to see that report and that verification with your team, the fifteen-minute demo is scheduled on the contact page (contact).