Your booking system knows the payment is late. Why are you the one chasing it?
Somewhere in almost every booking system in this industry there is a balance that has been overdue for twelve days.
The system knows the amount. It knows who owes it. It knows their email address and their phone number, because it collected both at the point of booking. It knows the arrival date is three weeks away, and it knows that this particular booking is for the August bank holiday weekend, which is the most valuable inventory the site sells all year.
And its entire contribution to the situation is a small red badge on a screen nobody has opened since Tuesday.
I have been thinking about that badge for most of this year, because I think it explains something about accommodation software that feature comparisons completely miss.
The category is built around recording, not acting
Most property management systems are systems of record. That is not an insult. It is the thing they were built to be, and for a long time it was genuinely the hard part.
If your bookings previously lived in a paper diary, then a database that holds every reservation, every guest, every payment and every rate, accurately, in one place, available from anywhere, is an enormous improvement. That was the achievement. The software's job was to know things, and to let you find out what it knew.
The problem is that the job description never got updated. Knowing things is now the easy part. Every system in this market knows your outstanding balances. The difference between products has quietly stopped being what the software knows and started being what it does about it, and most of the category has not noticed.
So you get software that is, functionally, a very well organised filing cabinet with an alarm on the front. It records that the balance is unpaid. It records that the enquiry came in on Thursday. It records that this guest has stayed four times. Then it waits for a human being to read all of that, work out what it means and take the action, which in practice means it waits for the owner, in the evening, after a fourteen hour day in August.
The software was reliably right about everything and did nothing, and the money is still outstanding.
Why it stays this way
It would be easy to say the reason is laziness or old code. I do not think it is, mostly.
A record is safe. A record is provably correct. Nobody has ever had an uncomfortable phone call because their PMS accurately stored a reservation.
An action can be wrong, in public, to your customer. Software that sends an email can send the wrong email. Software that cancels an unpaid booking can cancel the one the owner had personally agreed to hold for the family who rang about a bereavement. The moment a system acts on your behalf it takes on part of your relationship with your guests, and that is a genuinely serious thing to take on.
So there is a rational, defensible reason the category stopped at recording, and I want to be fair about it before I say the next part.
It is still the wrong place to stop. The cost of not acting is simply invisible, which is different from being small. Nobody sends you an invoice for the balance you never chased, the enquiry that went cold on a Saturday, or the guest who stayed three years running and then booked somewhere else because nothing ever reminded them you existed. Those losses do not appear on a report. They appear as a slightly disappointing season that everybody attributes to the weather.
Three places the gap shows up
The overdue balance. The system knows the amount and the due date. The record says unpaid. The action, sending the request, applying a deadline and putting the dates back on sale if it lapses, falls to a person who has forty other things to do, and so it happens late or not at all. It is the clearest example because it is pure arithmetic. There is no judgement involved in noticing that a date has passed.
The enquiry nobody answered. Someone asks about a fortnight in July. It is a Saturday in changeover season. By the time anyone replies on Monday evening they have booked elsewhere, and the loss is completely invisible, because a booking that never existed does not appear in any report. Most operators have no idea what their enquiry response time actually is, which means they cannot know what it costs them.
The guest nobody recognised. A family stays four years running, and the fifth year nobody at the site knows that when they ring. The information was in the database the whole time. Recognising a returning guest is one of the few genuine advantages an independent site has over a large group, and software that stores the history without ever surfacing it at the moment it matters has taken that advantage and filed it.
None of these are exotic. They are the ordinary weekly texture of running a site, and in all three cases the software holds every fact required to help and does not.
What I am willing to claim Keydesk does today
This is where I have to be careful, because it would be very easy to describe the product I intend to have rather than the one that exists in September 2026.
What acts for you today is mostly the payment workflow. Keydesk sends payment requests by email or text, schedules balance reminders before the due date, and can apply a deadline to a request so that an unpaid booking cancels automatically and the dates go back on sale without anyone having to remember. That last one matters more than it sounds. It is the difference between losing a bank holiday weekend to a booking that was never going to pay and selling it to someone who will.
The Pitchup integration is the same idea applied to availability. Two-way sync means closing two pitches for a repair updates the channel without anyone doing it twice, which removes the specific gap where double bookings live.
What is honestly still a record: Keydesk does not automatically collect a balance from a saved card. Reporting, which shipped in August, tells you your channel split, occupancy and revenue accurately, but it tells you. It does not yet prompt you. The guest record holds returning-guest context and shows it during booking, which is useful at the counter, but nothing in Keydesk chases a past guest for repeat business, and there is no marketing automation in the product. That is on the roadmap and it is not built.
So on the standard I am setting out here, we are some way along on payments, started on availability and barely begun on guest revenue. I would rather write that down than imply otherwise, partly because the operators we work with will find out within a week either way.
The conditions I think acting has to meet
Given the risk I described earlier, acting on an operator's behalf only works with rules attached. These are the ones we hold to, and they are worth asking any supplier about.
The operator sets the rule, not the vendor. Whether a reminder goes out seven days before or fourteen, whether an unpaid booking cancels at all, what the deadline is. Defaults are fine. Defaults you cannot change are not.
Every action is visible on the booking. If the system sent something, you should be able to see what it sent and when, without asking support. Actions you cannot audit are worse than no actions.
Nothing irreversible happens quietly. The auto-cancel on an unpaid deadline is the sharpest thing Keydesk currently does, which is exactly why it is something you switch on deliberately with a deadline you chose, rather than a behaviour that arrives in a release.
Judgement stays with the person. The rule I wrote about in what should a booking system automate still holds: automate a repeatable decision where the inputs and the safe outcome are clear, keep a person in the loop where context changes the right answer. A deadline that has passed is arithmetic. A guest ringing about a family emergency is not.
The question I would ask a supplier
If you are looking at booking systems this autumn, and late September to November is when most sensible people in this industry do look, there is a question worth adding to the list.
Not "does it track outstanding balances", because they all do, and the answer tells you nothing.
Ask what the system does on the day a balance becomes overdue, and who has to be at a screen for that to happen. Then ask the same question about an enquiry that arrives at 9pm on a Saturday in July.
The answers vary a lot more than the feature lists suggest.
I want Keydesk to be the product where those answers are good, and I am aware we are partway there rather than finished. But I would rather be judged against the right standard while we are still building than score well against the wrong one. The right standard is not how completely the software records your season. It is how much of your season it quietly handles while you are doing something else.
If you want the detail on what the payment workflow actually does today, including what it deliberately does not, it is on the deposits and payments page. If you are reviewing the season before setting next year's rates, the operator scorecard covers twelve measures across direct revenue, pricing and booking admin.