One integrated system, or four that talk to each other
Nobody sets out to buy four systems. It happens one reasonable decision at a time, and the cost turns up later, somewhere nobody is looking for it.
This page argues for one system doing the whole property. It also sets out where the opposite is the right answer, because for some operations it genuinely is.
How a hotel ends up with four systems
The property management system comes first, because you have to have one.
Then the restaurant manager finds a point of sale they prefer to the one that came with it, and they are not wrong about the features. Then finance wants their own accounting package, because that is what the bookkeeper already knows and retraining is a cost too. Somewhere in the middle a spreadsheet appears to reconcile the parts that do not meet, and after a while nobody can remember who built it or what the formula in column H is for.
Every one of those decisions was defensible on the day it was made. The result usually is not, and the reason is that nobody ever decided on it.
The cost does not appear in the licence fees
It appears at month end.
The point of sale says one number and the ledger says another. Someone spends a morning finding out that a bar tab was posted to a room that had already checked out, and another hour deciding whose job it is to correct it. A guest asks for a copy of their bill and reception assembles it from two screens. Stock says you have eighteen bottles and the cellar has eleven, and the difference is not theft, it is that the two systems disagree about what a case is.
None of that is dramatic. It is a steady tax on people's attention, paid forever, and it is invisible in any comparison of subscription prices.


Interfaces are the part people underestimate
An interface between two systems is a promise that data will move. Like any promise, the interesting question is what happens when it is broken.
When an interface fails properly, it is almost a relief. Everything stops, an error appears, somebody rings somebody. You know.
The expensive failure is the quiet one. Data mostly flows and a small percentage does not, silently, for weeks. Nothing alerts because from each system's point of view nothing is wrong: one sent, the other simply never received. You find out at a month end, or a year end, or when a guest disputes a charge you cannot evidence.
Double entry is more honest by comparison. It is slow and it irritates your staff and it produces its own errors, but at least everybody knows they are doing it. Nobody is under the impression the problem is solved.
There is a third cost that only shows up when something is wrong, and it is the one operators mention first when you ask them. Four systems means four suppliers, and every one of them can tell you it is somebody else's problem. The property management vendor says the point of sale is sending malformed data. The point of sale vendor says the interface specification changed. Both are being reasonable and neither is fixing it, and the person in the middle holding a hotel together is you.
The honest argument for separate systems
We should make this properly, because for some operations it wins.
If you are running a large group with a real IT function, best of breed can genuinely beat one vendor's version of everything. A dedicated point of sale from a specialist will out-feature the module bundled into a property management system, because it is that company's entire business. The same is true of a serious accounting package once your finance operation is large enough to need what it does.
Best of breed works when somebody owns the integration layer. That means a person whose job includes noticing that the nightly transfer ran short, holding four vendors to account, and testing the interfaces after any of them ships an update. With that person in place, the trade can pay for itself.
Most independent hotels do not have that person. What they have is a general manager who also handles anything technical that goes wrong, which means the integration layer is the general manager, in the evening, after service.
What one system changes
Not elegance. Elegance is not worth paying for.
- A restaurant charge reaches the room because there is nowhere else for it to go, not because a transfer ran successfully at two in the morning.
- The night audit reconciles because there is nothing to reconcile it against.
- A guest folio is one document, assembled from one place, whoever is on the desk.
- Stock movements, sales and the ledger describe the same event once rather than three times in three formats.
- Reporting covers the property rather than covering a system, so occupancy, spend and margin can be looked at together without an export and a spreadsheet.
- When something is wrong there is one number to call, and nobody at the other end of it can tell you it is the other vendor's problem.

That last one is worth more than it sounds. It is the difference between a problem being solved and a problem being adjudicated.
What Resort Manager actually covers
One system handling reservations, the front desk, guest relations, point of sale, stock, reporting and the accounts. Two editions, depending on the size of the property. Add-ons for the interfaces a particular hotel needs, such as door locks, the telephone system, guest wi-fi or a CRM, chosen from a list rather than bundled in to inflate a quote.
The one thing that genuinely lives outside the building is distribution. Selling rooms means talking to online travel agents, and we do that through a channel manager rather than connecting to each agent separately. That is a deliberate choice and the reasoning is on that page.
Being one system is also why it survives a bad connection. There is no nightly transfer to fail and no interface to go quiet, so when the internet drops the building carries on working.
If you are looking at this now
The usual trigger is a month end that took three days instead of one, or a supplier conversation that went in circles.
There is also an account we did not commission and cannot take credit for. Ananda Mello Costa is a systems engineer with about two decades in enterprise systems and quality management, who ended up running a small eco resort on a remote island in the Philippines. Eight rooms, forty-five staff, a restaurant, a spa, a dive centre and a kite centre, held together by spreadsheets on three laptops.
Most of what she wrote is not about software at all. It is about what happens when information lives on paper, in cash, and in files that do not relate to each other, which is the condition this page is really describing and the reason it is worth reading whether or not you ever speak to us. Her account is on her own site, and we link to it there.
Two customers have written up their own decisions, and both are worth more than anything we could say about ourselves. Code Hotel on Koh Samui left one of the three largest property management systems after three years of support problems. Maekok River Village had a system they liked, and left because keeping it current meant buying servers and workstations again.
Tell us how your property is put together, including the parts that are held together with a spreadsheet, and we will tell you honestly whether one system would be an improvement or just a different arrangement of the same work.
Ready to experience the benefits of Resort Manager for yourself?
Contact us today to schedule a demo or learn more about our software.