Buying software
What to ask a developer before you hand over a booking system
· 6 minute read
Quick answer
Ask how the system stops two people taking the same slot at the same moment, what happens to a booking when a payment half works, and who can change or cancel a booking without calling the developer. Those three answers tell you whether it was built for a busy Saturday or for a demonstration. Everything else on this list matters, but a system that gets those three wrong will lose you money on your best day.
A booking system looks simple from the outside. Somebody picks a time, pays, and turns up. The demonstration always works, because in a demonstration one person books at a time.
The problems all live in the cases nobody demonstrates: two people tapping the same slot in the same second, a payment that neither succeeded nor failed, a customer who wants to move a booking on a Sunday evening. These are the questions that find out whether those cases have been thought about.
Start with the double booking question
Ask it in exactly these words: what stops two customers booking the same slot at the same moment?
There is a right answer and a wrong one. The wrong answer is a description of the screen: the slot disappears once it is taken, the calendar refreshes, the second person sees it is gone. All of that is about what the customer sees, and none of it happens on the server where it matters.
The right answer mentions the database. Something along the lines of: the slot is claimed inside a transaction, and there is a rule in the database itself that refuses a second booking for the same slot, so even if the application logic is wrong the data cannot be. You do not need to follow the details. You need to hear that the last line of defence is the database and not the browser.
This matters most at exactly the moment it hurts most: the busy hour, when two people really are looking at the same slot.
What happens when a payment half works
Payments fail in the middle more often than anyone expects. The customer's bank approves it and the connection dies before your system hears back. Or your system records a booking and the payment never completes.
Ask what the system treats as proof that money moved. The answer should be the payment provider's own notification arriving directly at the server, not what the customer's browser reported on its way back from the checkout page. Anything the browser sends is something a person can edit.
Then ask the two follow-ups:
- What does the customer see while the payment is still uncertain?
- What happens to the slot in the meantime, and for how long is it held?
A system with no answer to the second one either gives away slots it has been paid for or holds slots it has not.
Working on something like this?
Describe the problem in a few lines. We reply with a scope, a timeline and a price, even when the answer is that you do not need us.
Who can change a booking, and from where
Most of the running cost of a booking system is not the software. It is the staff time spent on changes the software would not let anybody make.
Go through this list and ask who can do each one without calling the developer:
- Move a booking to another time.
- Cancel one and decide whether it is refunded.
- Block out a morning because a member of staff is ill.
- Add a booking taken over the phone.
- Change opening hours, or close for a holiday.
- Change a price, or add a service.
Then ask the same list again for a phone, because whoever is doing this on a Saturday is not sitting at a desk.
Cancellations, refunds and no-shows are your policy, not their code
Decide the policy first and hand it over. How late can somebody cancel and still get money back, is a deposit refundable, what happens when a customer simply does not turn up, and who is allowed to make an exception.
Any competent system can implement whatever you decide. None of them can decide it for you, and a policy invented by the developer during the build is a policy your staff will be arguing about with customers for years.
Reminders, and what happens when one fails
Ask what gets sent, on which channel, how long before the appointment, and what the system does when a message does not deliver.
That last part is the one to press on. A reminder that silently fails is worse than no reminder, because everyone has stopped expecting the customer to forget. The answer should be that failures are visible somewhere a person actually looks.
Also ask whether a failed reminder can ever take a booking down with it. It should not. A booking that was made is made, even when the confirmation email bounces.
What it does when something is broken
Two scenarios, both of which happen:
The internet is down at your counter. Can staff still see today's list? A booking system that cannot tell you who is coming today, when the connection is out, is a booking system that sends you back to a paper diary on the worst possible day.
The payment gateway is down. Can you still take a booking and collect money later, or does the whole thing stop? Write down which you prefer before you are asked, because both are defensible and the default is whichever the developer happened to build.
The questions about afterwards
The same ones that apply to any custom software, and they are the ones most often skipped:
- Who owns the code, the customer data and the accounts the domain and hosting sit in?
- Can I export my bookings and my customer list, in a format something else can read?
- What does a small change cost, and how long does it take?
- What am I paying for annually: hosting, the gateway's percentage, messaging?
- Who do I call when it breaks on a Saturday, and what is the answer if they are asleep?
Question two is the one to insist on. A booking system holding several years of customer history that cannot export it has quietly become the most expensive thing in your business to replace.
The broader version of all this, including who owns what and what shows up on the bill after launch, is in what a CMS website costs. What we build into a booking system, and what we leave out on purpose, is on booking systems. If you are choosing between building software and using somebody else's platform, your own learning platform or a marketplace works through that trade-off with a different example.
Questions about this
How does a booking system prevent double bookings?
- Properly, by claiming the slot inside a database transaction with a rule in the database that refuses a second booking for the same slot. Hiding the slot in the browser once it is taken is not prevention, because two people can act in the same second.
What happens if a customer's payment fails halfway?
- The system should trust only the payment provider's own notification to the server, never what the browser reports. Ask what the customer sees while payment is uncertain, and how long the slot is held before it is released again.
Should staff be able to change bookings themselves?
- Yes, and on a phone. Moving, cancelling, refunding, blocking a morning, adding a phone booking and changing opening hours should all be possible without calling the developer. Staff time spent working around the software is the real running cost.
Who decides the cancellation and refund policy?
- You do, before the build starts. Any system can implement whatever you choose, and none can choose for you. A policy invented by the developer mid-build is one your staff will argue about with customers for years.
Can I get my booking data out later?
- Insist on it in writing before you sign. A system holding years of customer history with no export is the most expensive thing in your business to replace. Ask for a format another system can actually read.
What happens if the internet goes down at the counter?
- Ask directly, because the answer is whatever was built rather than whatever is best. At minimum your staff should still be able to see today's list. Decide in advance whether you would rather take bookings without payment or stop entirely.