What a booking system actually needs to do
A booking system earns its keep by removing admin, not by taking bookings. Taking the booking is the easy part and every tool does it. The hours are saved afterwards, in reminders, changes, cancellations, payments and a register your staff can actually read at a poolside or in a van. Judge any system on what happens when a customer changes their mind, because that is where the time goes.
Taking the booking is the easy part
Every booking tool on the market can show a calendar and accept a slot. That is the demonstration, and it is why demonstrations are misleading.
Watch where your team's time actually goes for a week. It is almost never the booking. It is the parent who needs to move a lesson, the customer who wants a different collection day, the card that failed, the person who did not turn up and now wants a credit, and the register that had to be printed because the system cannot show it usefully on a phone.
So when you are looking at options, skip the booking screen. Ask what happens in each of those five situations, and ask to see it rather than hear it.
The five jobs that save real hours
Reminders that go out on their own. The single biggest reduction in no-shows, and the easiest thing to get right. It should need nobody to press anything.
Customers changing their own bookings. Within rules you set: how much notice, how many changes, which slots. Every change a customer makes themselves is a phone call your team does not take.
Cancellations and credits, handled by the rules. This is where most off-the-shelf tools give up, because credit rules are specific to each business. A missed swimming lesson with 24 hours' notice might earn a credit valid for a term. That logic is yours, and it either lives in the software or it lives in somebody's head.
Payments that recur without chasing. Subscriptions, renewals, failed card retries, and a clear view of who has actually paid.
A register the staff can use. On a phone, at the poolside or in the cab, ideally without a signal. If a member of staff has to print it, the system has not finished the job.
Where off-the-shelf tools stop
Generic booking products are built for the common case: one person, one slot, one price, pay now. They are good value when that is genuinely your business, and plenty of businesses should buy one and stop reading.
They start to strain when your rules are specific. Pricing that depends on more than one variable, such as postcode, size and access. A term of lessons booked as one thing but attended weekly. Siblings on one account at different levels. Waiting lists that promote automatically when somebody drops out. A collection round where the order of stops matters.
The tell is the workaround. When your team keeps a spreadsheet alongside the booking system, the spreadsheet is where your actual business rules live, and the software is doing about half the job you are paying it for.
Buying one or building one
Most businesses should start by buying. The question is what to do when you have outgrown it.
| Off the shelf | Bespoke | |
|---|---|---|
| Time to running | Days | Weeks to months |
| Your specific rules | Approximate them, or work around them | Built in, including the awkward ones |
| Cost shape | Monthly, often per user or per booking | Up front, then hosting and support |
| Cost as you grow | Rises with volume or staff | Broadly flat |
| Fitting your other systems | Whatever integrations exist | Built to fit what you already run |
| Staff-facing register | Generic, sometimes printable only | Designed around how the job is actually done |
| Best for | Standard bookings, getting started | Rules nobody else has, or volume that makes fees hurt |
Payments, and the awkward cases
Taking a card is solved. Stripe and its equivalents handle the hard parts, and any system worth considering will use one of them rather than touching card details itself.
The awkward cases are where systems differ. What happens when a subscription payment fails on a Sunday night? Does it retry, does it tell the customer, does it tell you, and does the child still get into the lesson on Monday? Can you take a deposit now and the balance later? Can you refund part of something? Can a parent with three children pay once?
Ask about failed payments specifically. Every provider demonstrates the successful path. The money you lose is on the other one, and it is lost quietly.
The register nobody thinks about
Booking systems are sold to owners and used by staff, and those are different jobs with different needs.
The person at the poolside needs today's list, who is new, who has a medical note, and a way to mark attendance with wet hands in about two seconds. The driver needs the round in order, the access notes, and the ability to record that a bin was blocked. Neither of them needs a dashboard.
When we built the software behind Mini Dolphins Swim School in Harlow, the parent app and the booking flow were the visible parts, but the register was the part that changed the working week. It is the screen most likely to be an afterthought, and it is the one your team will open a hundred times more often than you open the reports.
Work this out before you buy or build
Half an hour with the person who currently does the admin will tell you more than a fortnight of demonstrations.
- Write down your awkward case. The booking your business always trips over. Take it to every demonstration and ask them to do it live.
- Time the admin. How many hours a week go on changes, chasing and registers. That number is your budget.
- Write your cancellation rules as sentences. If you cannot, no software can enforce them, and that is worth knowing first.
- Decide who needs a login. Customers, staff, both. Per-user pricing turns this into a real cost as you grow.
- Ask what leaving looks like. Can you export your customers, their history and their bookings, in a form you could actually use?
If a product handles your awkward case, buy it. If two do not, the rules are probably specific enough to be worth building around, and that is the point at which it is worth having the conversation.
Common questions
The parts that save time all happen after the booking: automatic reminders, letting customers reschedule within your rules, handling cancellations and credits, taking recurring payments and retrying failed ones, and giving staff a register they can use on a phone. Taking the booking is the easy part and every tool does it, so it is the wrong thing to judge on.
Buy first if your bookings are standard: one person, one slot, one price. Consider building when your rules are specific enough that your team keeps a spreadsheet alongside the software, when per-user or per-booking fees are growing faster than the business, or when the register your staff actually use is the part no product gets right.
That logic is specific to your business, which is exactly why generic tools struggle with it. Write the rule down as a sentence first, for example that a lesson cancelled with 24 hours' notice earns a credit valid for the current term. If you can state it plainly, it can be built and enforced automatically. If you cannot, it currently lives in somebody's head and it will keep costing you time.
Yes, and it should, through an established provider such as Stripe rather than handling card details itself. The thing to check is what happens when a payment fails: whether it retries, who is told, and whether the customer keeps their place in the meantime. Every provider demonstrates the successful path, and the money is lost on the other one.
It depends on how many of your rules are unusual and what it has to connect to. A focused system doing one job well can be a matter of weeks; a full platform with a customer app, payments and staff tools is typically a few months. We scope it, put a fixed price in writing, and start with the part that removes the most admin.
Where to go next
If you want a straight answer about your own situation, tell us what you are trying to do and we will say what we would do, including when the answer is that you do not need us. Start a conversation.