$96,000 a year for a PMS that got the money wrong
The off-the-shelf system charged $16 per flat per month. Across a portfolio of 500 flats that is $96,000 a year. And it still calculated owner payouts incorrectly.
$96,000 a year → $3,000In short
An off-the-shelf PMS charged $16 per flat per month — $8,000 across a portfolio of 500, with a Monday subscription on top: the PMS could not be extended, so cleaning and cleaner hours were run on a separate board. It calculated owner payouts without VAT and without part of the Booking.com commission, and had no field for occupancy at all.
We are moving the company onto its own system gradually, flat by flat, without pausing the business. We pointed the channels at our own data, moved dynamic pricing onto a partner integration, launched a direct-booking site and a cleaning workflow, put AI on the first line of guest messaging, and rebuilt owner payouts as itemised ledger entries.
What hurt
The company runs short-let rentals in the UK. Five hundred flats. Every operation lived inside an off-the-shelf PMS: calendars, bookings, guests, owner settlements.
Not quite every operation. The PMS could not be extended: whatever it did not have, you could not add. So cleaning, cleaner hours and half the operational work moved to Monday — a separate board, reconciled with bookings by hand. Two places instead of one, and neither knew about the other.
The system charged $16 per flat per month. Across five hundred flats that is $8,000 every month and $96,000 a year — for software that had not changed in years. The Monday subscription came on top, because operations could not run without it.
But an expensive subscription was not the main complaint.
The system calculated the money wrong
We went through it with the client's team, on live bookings. It turned out the owner payout was worked out crudely: take the amount from the channel, subtract the cleaning, multiply by the management company's commission. That is all.
There is no VAT in that formula. And no extra 2–2.5 % that Booking.com charges on top of its headline commission. Which means every month, on every flat, on every booking, the payout drifted away from reality.
This is not an interface annoyance. This is money miscounted five hundred times a month.
And what it simply did not hold
They were listed as “Untitled”, and the ones that did have names duplicated each other. Finding the right one in the list was an exercise in itself.
A quarter of the active flats had nothing to say about what the money should be counted in. The system did not mind.
The database holds “0” or nothing at all, while the interface shows 11:00 for the same flat. You cannot schedule a clean on that.
Empty on every single row without exception — flat, house or studio, the system did not know.
How many people a flat sleeps — no such field exists in the system. And it is the first thing a guest asks.
For a business built entirely around check-in and check-out times, a strange place to leave a gap.
What we did
We built a system of our own and we are moving the whole company onto it: data, sales channels, pricing, operations and owner settlements. The move goes gradually, flat by flat — not as one big switch overnight.
The same portfolio on the new system costs $250 a month — $3,000 a year instead of $96,000. The Monday subscription is gone entirely: operations now live inside. And that is before counting direct bookings with no channel commission, and owner payouts that finally add up.
A move with nothing lost and nothing stopped
The requirement was not “fast”, it was “lose nothing”. The business keeps running through the move: guests check in, bookings arrive, money is counted. So flats cross over one at a time, and both systems run side by side until the end.
Not a single change request goes into the old system. We only read from it: the client's live business sits in there, and a migration must not break it.
Any flat can be migrated again as many times as needed — no duplicates appear. And it is always visible what has moved and what has not: that is exactly what makes it possible to go in small steps instead of holding everything in your head.
The channels take their data from our system
Distribution to Booking.com, Airbnb, Expedia and Vrbo is handled by a channel manager — a separate service that knows how to talk to each platform. There is no need to write our own integration with them, and no reason to.
What was needed was different: that it take prices and availability from our system rather than the old one. That link is what we built. Prices and availability now live in our database, and any change travels onward by itself — no “sync” button.
There is one source of truth. Edits made in someone else's interface get overwritten by the next push, and that is deliberate: the moment there are two sources, they start to drift apart.
Every push and every response is written to a log. The question “did the new price actually reach Booking?” used to have no answer at all. Now a failure does not bring the operation down — it becomes a visible task for an operator.
Dynamic pricing moved across with us
The client already had dynamic pricing in place and working — but it was tied to the old PMS. It had to move onto our system along with everything else, without breaking anything on the way.
The obvious route — connect to it through the client API and let it write prices straight into the channel manager — we looked at and dropped. In that mode it becomes a second writer: it knows nothing about prices an operator has fixed by hand, and quietly overwrites them on the channels. And because prices are never read back, nobody would ever have noticed.
So we built the integration on the partner protocol instead — it sees our PMS exactly as it would see any commercial one. We hand over flats, calendar and bookings; it sends recommended prices back to us. It writes nothing to the channels. A price an operator fixes by hand holds until a chosen date and overrides the automation for the whole of that time.
Along the way something appeared that had never existed before: price history. Every change is recorded with what it was, what it became and who set it.
A booking site of their own
Every booking came from a channel, and each one took 15–18 % in commission. There was no sales channel of their own: even returning guests booked through Airbnb.
We built their own site on the same database — the same flats, the same calendar, the same prices. There is no second database, so there is nothing to drift.
Availability is re-checked live before the quote and again before payment. A race with a channel turns into an honest “that date has just gone” rather than a double booking.
Cleans are born with the booking
Cleans used to live on a separate Monday board, and cleaner hours were reconciled by hand at the end of the month. The board knew nothing about bookings, the bookings knew nothing about the board — the link was held together by a person who remembered both.
Now a booking appears and with it the check-in, the check-out and a cleaning task set to the moment of departure. The same for a channel booking and a direct one. No separate board and no separate subscription needed for it any more.
A manager still assigns the person: the task sits unclaimed until it is handed to a particular cleaner. Spreading cleans across people automatically is a bad idea — shifts carry context the system does not have.
The cleaner files a report afterwards. If the actual hours differ from the planned ones, the report does not go through to payment until a supervisor has checked it. Cleaners see their own pay themselves: hours times rate, month by month, and only their own.
The money adds up
The whole point of the exercise. A guest payment is broken down into ledger entries: accommodation, fees, taxes, channel commission, discounts, payments and refunds. VAT and the extra Booking.com commission are now in their proper places instead of being left out of the formula.
The commission model is attached to a flat through a dated log: change it mid-month and the calculation splits itself at the boundary.
The owner sees the breakdown in their own portal and no longer writes in to ask where the figure came from.
AI on the first line of guest messaging
Half of all guest messages are the same questions: how to get in, where to park, what time check-out is, whether there is an iron. The answer sits in the flat's record and in the booking itself, but a person typed it out every time.
Now AI takes the simple questions, and anything beyond them goes to a manager. All model calls run through one shared layer: a prompt registry, protection against instructions smuggled into guest text, timeouts, retries and cost accounting in one place.
What it costs
That is $93,000 saved a year. Direct bookings with no channel commission, and owner payouts that finally add up, are not counted here.
The same job, as a product
The real work here is not «moving off a PMS» but connecting systems: channels, pricing, cleanings, the bank and guest messages stopped living apart and started passing data to each other on their own.
This is one of six jobs an AI assistant does for a business — the same shape as connecting a CRM, accounting, a warehouse and a delivery service.
Result
Recognise the problem?
Give us 30 minutes and we will tell you which of this can be repeated at your company.