Booking software problems: what to check before you sign up
30 September 2026 · 9 min read
Booking software demos all look the same: a tidy calendar, a phone with a confirmation text, a happy customer. The complaints owners actually make afterwards are about different things entirely — setup that takes three weekends instead of an afternoon, reports that stop being useful the moment you grow, and the system going down on the one morning you couldn't afford it. This post covers what genuinely goes wrong, and the specific questions to ask before you hand over a card.
The three complaints that keep repeating
If you read enough reviews of booking and scheduling tools written by small business owners — not agencies, not enterprise buyers — the same three themes surface again and again. They're worth understanding separately, because they hurt at different stages of ownership and you can test for each one differently.
1. Setup takes far longer than anyone said
This is the most common early complaint, and it's rarely about the software being badly built. It's that a real appointment business is more complicated than a demo calendar. You have services with different durations. You have a colour that needs a 45-minute gap in the middle for processing. You have two treatment rooms but one of them can't take the machine. You have a Saturday price and a weekday price. You have a deposit on some services and not others. You have one member of staff who only works alternate Fridays.
Every one of those rules has to be typed in by someone. The signup flow takes ten minutes; encoding your actual operating logic takes hours, and you usually discover the gaps live, when a customer books something impossible. The honest complaint isn't "it's hard to use" — it's "nobody told me how much of my own business I'd have to describe to it before it was safe to switch on".
What makes this worse is that the work isn't transferable. Spend two weekends configuring one platform and you've built a sunk cost that makes leaving painful even when you should.
2. You outgrow the reporting before you outgrow the calendar
The second complaint arrives later, usually a year or two in. The booking engine itself still works fine. What stops working is your ability to answer questions about the business with it.
Basic packages tend to give you bookings taken, revenue by period, and maybe cancellations. What owners start wanting is narrower and more awkward: rebooking rate per stylist, no-show rate by day of week, how many new clients came from the online link versus the phone, revenue per hour of chair time, which service is quietly eating your diary at a poor margin. Those are the numbers that change decisions. They're also the ones parked behind the next tier up, or missing entirely, or available only as a CSV export you then have to wrangle in a spreadsheet yourself.
It's a mild complaint compared with the next one, but it's the one that drives migrations. You don't leave because the calendar broke. You leave because you can't see anything.
3. Downtime — and it lands when it costs most
This is the serious one. In the worst cases owners describe, the platform went down for long enough to directly cost bookings and revenue — severe enough that at least one moved provider mid-season rather than risk it happening again during their busiest weeks. Not an inconvenience. A move made under pressure, at the worst possible time, precisely because the alternative was another outage.
An outage in booking software is unusually expensive because of when it tends to matter. Your online booking traffic isn't spread evenly. For a salon it stacks up on Saturday morning and Sunday evening. For a clinic it's the hour after work. For a trades business it's whenever something breaks. If the system is down during a quiet Tuesday afternoon, you lose almost nothing. If it's down for three hours on a Saturday morning, you lose the busiest booking window of your week, and most of those customers don't come back later — they go and book somewhere that's working.
Do the maths on one bad Saturday
Say your online booking page normally takes 15 appointments across a Saturday morning, at an average ticket of £55. That's £825 of diary. Assume half of the people who hit a broken page come back or ring you instead — generous, but let's be kind. The other half book elsewhere.
One three-hour outage in your peak window: roughly £400 gone, plus whatever those clients would have been worth on repeat. Two of those a year and the outage has cost you more than a year of most subscription tiers.
Now run the same sum on a slick platform that costs £10 a month less than a plainer one. The saving is £120 a year. The reliability difference is worth several times that. Price is almost never the deciding factor here.
Why reliability beats the feature list
The common thread through all three complaints is that a booking tool's job is narrow and unforgiving. It has to be available and correct at the exact moments demand arrives. Everything else — the design, the loyalty points, the marketing emails, the app — is secondary to that.
Buyers get this backwards because demos are designed to sell features. Nobody demos uptime. Nobody shows you the incident history. So you end up comparing the shortlist on the things that are easy to compare, which are the things that matter least. A plain interface that has never once failed on a Saturday is worth more than a beautiful one that fails twice a year.
This isn't unique to booking software. The same pattern shows up across small-business tools — we've written about it in the context of review and messaging platforms, where the complaints are about contracts and stacked fees rather than the product demo.
What to actually check before you sign up
Here's a checklist you can work through in an hour, mapped to which complaint it protects you from.
| Check | Protects against | How to do it |
|---|---|---|
| Public status page with history | Downtime | Ask for the URL. Scroll back 12 months. No page, or a page with no history, is an answer in itself. |
| Free trial with your real rules | Setup pain | Configure your three most awkward services during the trial, not the three easiest. |
| Export your data, today | Lock-in | Run a full export on day one. If clients, appointment history and notes don't all come out in a usable file, you're stuck later. |
| See a real report | Reporting ceiling | Ask them to show rebooking rate and revenue per staff member in the tier you're buying — not the top tier. |
| Who covers the phone when the site is down | Downtime | There should be a fallback: a number, a paper diary process, someone who knows what to do. |
| Contract length and notice period | Everything | Monthly rolling means a bad outage costs you one month, not twelve. |
| What happens to deposits during an outage | Downtime | Payment failures mid-booking are the messiest version of this problem. |
Questions vendors answer badly (and what a good answer sounds like)
- "When did you last have an outage, and how long was it?" A bad answer is "we've never had one" with no evidence. A good answer names an incident, a duration and what changed afterwards. Everyone has outages. Only some are honest about them.
- "How long does setup usually take for a business like mine?" A bad answer is "minutes". A good answer asks how many staff, how many services and whether you have resource constraints like rooms or chairs — because those are what make setup long.
- "What's in the tier above mine?" If reporting is the main thing behind the upgrade wall, assume you'll be paying that price within two years. Budget for it now rather than being surprised.
- "Can I be up and running in parallel with my current system?" Running both for two weeks is the cheapest insurance in a migration. Vendors who make this awkward are telling you something.
- "What happens to bookings made during a failed sync?" Double bookings are the reputational version of downtime. Find out where the truth lives when two systems disagree.
The migration nobody budgets for
Switching booking platforms is worse than switching almost any other tool, because the data is live. Your client list has to move. Future appointments have to move. Deposits taken in one system have to be honoured in another. Anyone with your old booking link in their phone has to be redirected. Staff have to relearn a layout while customers are standing in front of them.
Which is exactly why owners describing the worst outages sound so weary: they weren't choosing to migrate. They were forced into it at the busiest point of the year by a system they'd already invested weeks in. If you take one thing from this, make it the export test on day one. The ability to leave cheaply is what stops a bad year turning into a terrible one.
Where booking software isn't the problem at all
There's a category of complaint that gets blamed on the software unfairly. Owners say "the booking system isn't bringing me enough work" when what's actually happening is that most of their enquiries never reach the booking system. They arrive by phone, mid-job or mid-colour, and go unanswered. A perfectly functioning calendar can't capture a call that rang out. We've done the arithmetic on that gap for trades and for salons.
If that's your actual leak, no amount of booking software shopping will fix it — you need something answering the phone. That's the job an AI receptionist does: it picks up every call, round the clock, and logs what the caller wanted. If you want the step-by-step of how a call actually goes, there's a walkthrough here.
And where an AI receptionist is the wrong answer too
To be straight about it: an AI receptionist is not a booking system, and it won't solve the three complaints in this post. It doesn't hold your diary rules, it doesn't produce rebooking-rate reports, and it doesn't replace the calendar your staff work from. If your problem is genuinely that your scheduling tool is clunky or unreliable, you need a better scheduling tool — answering the phone differently changes nothing about that.
It's also the wrong fit if your bookings are overwhelmingly self-serve. A business where nine out of ten clients book online, at their convenience, without ever ringing, has very little call volume to rescue. Paying for call cover there is paying for a problem you don't have. And if your calls are long, emotional or highly technical — complex medical triage, distressed customers, detailed specification work — a human handles them better, and some callers simply don't want to talk to an AI regardless of how well it performs.
The useful way to think about it is as two separate leaks. One is enquiries that arrive and get lost because nobody picked up. The other is enquiries that arrive, reach your booking page, and hit a system that's slow, misconfigured or down. Fix them with different tools, and test the second one for reliability before you test it for anything else.
