One system for the restaurant and another for the hotel: the hidden cost of keeping them connected
Your hotel’s restaurant has its point of sale and the front desk has its own system, and someone said they were “connected”. Here is what that connection really costs: the integration that breaks with every version, two vendors pointing at each other and the room charge stuck in the middle.
In your hotel’s restaurant there is a point of sale chosen by the food and beverage manager. At the front desk there is a system the owner chose years earlier. Between the two there is an integration someone installed, which worked the first month and which today nobody is quite sure still works. Every room charge crosses that bridge, and the cost of keeping it standing shows up on no invoice.
How you end up with two systems
It is almost never a decision. The front desk system came first because without it you cannot sell a room. The restaurant worked for years with a notebook or a cash register, and when it grew, the food and beverage manager looked for a point of sale designed for restaurants, because that is what they knew. The point of sale vendor said it could connect to the hotel system. The hotel system vendor said it had an interface. And on that basis the contract was signed.
The result is a hotel with two systems designed for two different businesses that talk to each other through a connection neither of them considers its own. The restaurant thinks in tables, kitchen tickets and tips. The front desk thinks in folios, stays and check-outs. The room charge is the only point where the two worlds have to agree, and it is exactly the one left in the hands of the integration.
None of that is anyone’s mistake. It is the natural consequence of buying each system to solve one department’s problem. The cost shows up later, when the hotel already depends on the bridge working every day and nobody is in charge of the bridge.
What “connected” really means
When a vendor says its point of sale “connects” to the hotel system, it pays to ask exactly what crosses the bridge and in which direction. In many cases, the integration only sends the charge amount with a room number. It does not verify that the room has a guest. It does not bring the name. It does not know whether the stay ended this morning. It returns no confirmation that the folio received it.
That difference is what separates a verified room charge from a text field where the server types a number. If the integration does not bring the stay to the point of sale, the server is charging blind, and what looks “connected” is actually a send with no receipt. The room charge page (Room charge) has the list of what a charge should verify before being posted; almost no integration between two systems from different vendors meets the whole list.
The questions to ask the connection
- Does the point of sale see the guest’s name and the current stay before posting the charge, or does it only send a room number?
- What happens if the room is empty or the guest checked out an hour ago: does the system reject the charge or accept it and lose it?
- Does the point of sale receive confirmation that the folio recorded the charge, or does it assume it arrived?
- Do failed charges land on a list someone reviews, or do they disappear without notice?
- When the front desk corrects or cancels a charge on the folio, does the point of sale find out, or does the restaurant close end up with a different number than the hotel’s?
- Which of the two vendors answers when a charge does not arrive, and how quickly?
Versions: when one updates and the other does not
Two systems from two vendors have two update calendars. The point of sale updates in March and changes the format in which it sends the charge. The hotel system never heard about it. For a week the charges arrive with an empty field, the front desk finds them odd and enters them by hand, and nobody tells the restaurant because “they do arrive”. In June the hotel system updates and now it is the integration that stops receiving the confirmation. The restaurant does not notice because it never checked it.
Every update on either side is a risk to the bridge, and the bridge has no vendor of its own. The usual solution is to stop updating one of the two “so as not to break the integration”, which leaves the hotel with a deliberately old system, with its security flaws and without the improvements it pays for. That is one of the reasons the page for the hotel’s systems lead (IT) insists on asking about the version calendar before accepting any connection.
And there is a quieter version of this: small configuration changes. A new outlet is added in the restaurant and nobody registered it in the integration mapping. The room numbering at the front desk changes because of a renovation and the point of sale keeps the old one. Neither of those is a software update, and both break the bridge just the same.
Two vendors, one problem and nobody responsible
The day a charge does not arrive, the restaurant manager calls the point of sale vendor. They answer that the charge went out correctly and to check with the hotel vendor. They call the hotel vendor, who answers that nothing was received and to check with the restaurant vendor. Both are right from their side of the bridge. Meanwhile, the guest has already checked out and the consumption left with them.
That back and forth has a cost in hours from the manager, the controller and the front desk that appears in neither vendor’s contract, and it has a bigger cost: nobody owns the outcome. Each vendor is responsible for its system working, and neither for the charge reaching the folio. The hotel, the only party that cares about that, ends up acting as the integrator without ever having hired one.
On top of that comes the direct cost: two support fees, two maintenance contracts, two training sessions whenever new staff arrive, and often a third fee for the integration itself, which is sometimes from a different third party. The controller sees them as three separate lines and that is why they never get added up as the cost of a single thing: getting the restaurant’s consumption onto the guest’s bill.
The consumption lost between the two
The biggest cost is not in the fees or the hours. It is in the consumption stuck in the middle of the bridge. A charge that left the restaurant and never reached the folio is a sale the restaurant counted and the hotel never collected. Since each side sees its own number, the difference only shows up when the controller crosses the two reports, if they cross them, and by then the guest is gone.
The places where that consumption gets lost are fairly predictable. The eight places where consumption leaks in a hotel (The eight places where a hotel loses food and beverage revenue) are described in detail, but when there are two systems, the ones that weigh most are these:
- Charges posted to a room that was empty or whose guest had already checked out, because the point of sale did not verify the stay.
- Charges the bridge rejected because of a format error and nobody reprocessed because there is no failed-charges list.
- Charges entered by hand at the front desk with an amount different from the ticket, because of a misreading or rounding.
- Pool bar or room service charges that never entered the point of sale because the server, knowing the bridge fails, wrote them on paper to carry to the front desk.
- Charges corrected or cancelled on the folio by the front desk that the restaurant kept counting as collected sales.
- Corporate agreement consumption with a cap where the cap lives at the front desk and the point of sale does not know it, so it gets overcharged and later adjusted by hand.
An illustrative example with numbers
The figures below are invented to show the calculation. They are not market data and they are not from any hotel. Suppose a hotel with a restaurant, a bar and room service that generates 300 room charges a month with an average amount of 350, that is, 105,000 a month in consumption charged to rooms. Suppose the bridge between the two systems fails or is entered wrongly in 3 out of every 100 charges.
| Item | Value (illustrative example) |
|---|---|
| Room charges per month | 300 |
| Average amount per charge | 350 |
| Consumption charged to rooms per month | 300 × 350 = 105,000 |
| Charges that fail or are entered wrongly (3 in 100) | 9 per month |
| Consumption lost to failed charges | 9 × 350 = 3,150 per month |
| Hours per month chasing charges (manager, controller, front desk) | 12 |
| Support and maintenance fees for two systems plus the integration | 3 separate lines |
| Consumption lost per year from failed charges alone | 3,150 × 12 = 37,800 |
In the example, consumption lost to failed charges is 37,800 a year, and that is without counting the consumption that never even entered the point of sale because the team learned not to trust the bridge. Add the twelve monthly hours of three people chasing charges and the three fee lines, and the cost of “keeping them connected” stops being invisible. The useful part of the exercise is not the figure, it is that it can be done with your own numbers: count one month’s charges, count the ones the front desk had to correct and multiply.
The three options you have
The first is to keep both systems and take real ownership of the bridge: name someone responsible for reviewing the failed-charges list every day, freeze versions on both sides and renegotiate with both vendors who answers when a charge does not arrive. It is the option with the least change and the highest permanent cost, because the integrator’s work is still done by the hotel.
The second is to replace the front desk system with one that brings its own point of sale. It solves the bridge, but replacing the front desk system is the most delicate implementation in a hotel: it touches reservations, rates, channels and invoicing, and the point of sale that comes bundled was rarely designed for a restaurant with a kitchen, modifiers and tips.
The third is to replace the restaurant’s point of sale with one designed from the start to live inside a hotel: one that verifies the stay before charging, returns confirmation from the folio, keeps a failed-charges list and has a single vendor responsible for the charge arriving. It is the option that touches the hotel’s operation least and removes the bridge without removing the front desk system.
What to demand in any of the three
Whichever option you choose, there are three things without which the problem is not solved: that the charge is verified against the stay before being posted, that a failed-charges list exists and someone reviews it every day, and that there is a single named person responsible when a charge does not arrive. If an option does not guarantee all three, it is the same situation under another name.
Two systems from two vendors talk through a bridge nobody considers their own, and every version, every configuration change and every failed charge is paid by the hotel in hours and lost consumption. What solves the problem is not “integrating better” but verifying the charge against the stay, keeping a list of failed charges and having a single person responsible.
What to do this week
- Ask the controller for last month’s number of room charges according to the restaurant and according to the front desk, and compare the two totals.
- Ask the front desk how many charges they had to correct, enter by hand or cancel last month, and write down the amount.
- Ask each vendor in writing what their system does when a charge reaches an empty room and where failed charges end up.
- Check the date of the last update of each system and whether either was left un-updated “so as not to break the integration”.
- Add up on a single sheet the support fees for both systems and for the integration, and put them next to the month’s lost consumption.
- Name one person responsible for reviewing failed charges every day while you decide which of the three options to take.
Inn Restaurant was designed to live inside a hotel: it verifies the guest’s stay before posting the charge, confirms it reached the folio and has a single party responsible for it arriving, at one price per property per month. If you want to see how it would look with your front desk system, the fifteen-minute demo is scheduled on the contact page (contact).
More articles
Team resistance to the new system: what servers say and what actually worries them
When your hotel’s restaurant changes point of sale, the servers say “the old one was better”. It is almost never that. It is the tip, the permissions, the speed with a tray in hand and the fear that a room charge posted to the wrong room will come out of their pay. Here is how each one gets addressed.
Switching systems in high season: when to do it and when to wait
High season is when the old system hurts most and when you have the least room for error. Here is how to read your hotel’s calendar, which outlet to start with and the signals that tell you to wait.
The first shift close on the new system: what to check that night and what to expect in the first week
The first shift close on the new point of sale almost never balances on the first try, and that does not mean the system is wrong. Here is what to review that night in your hotel’s restaurant, which differences are normal, which are not, and how permissions get adjusted during the first week.
Your hotel’s restaurant already sells well. Now the hotel needs to know it.
Fifteen minutes, with your menu and your tables. Nothing to install.