Booking Systems in New Zealand

Try the cheap option first

There are dozens of good booking products, they cost tens of dollars a month, and they are maintained by companies who think about nothing else. If one fits your business, use it. Nobody should spend $40,000 replicating something that already exists for $60 a month.

Custom becomes the right answer at a specific moment: when there is one rule your business runs on that the product cannot express. Most people arrive here having already found that rule the hard way, usually by working around it manually for a year.

Name that rule in your brief. It is the single most useful sentence you can give a developer, because it is what they are actually pricing.

The rules are the project

Booking looks simple from outside — a calendar, some slots, a form. The complexity is in the constraints, and every business has a different set:

• This job needs two staff and a vehicle, all free at once.
• Only three of our eleven technicians are certified on that equipment.
• Travel time between sites depends on where the previous job was.
• The room needs thirty minutes' turnaround, unless it is the last booking of the day.
• This customer's contract entitles them to same-week service.
• Bookings over $500 need a deposit; under that, payment on the day.

Each is small. Together they are the software. Expect to spend real time writing them down precisely, probably for the first time — and expect that process to surface disagreements between your own staff about how things actually work.

Two people, one slot

Ask every developer: what happens when two customers book the last appointment at the same instant?

The correct answer involves the database enforcing it — a constraint or a transaction that makes the second booking impossible rather than unlikely. An answer about checking availability before saving is describing a system that will double-book, rarely, at the worst possible moment, and then require a phone call to a customer who has already arranged their day around it.

This is a good question because it is short, it has a right answer, and the responses separate the developers who have built this before from the ones improvising.

Cancellations are a policy question

Most of the awkward decisions in a booking system are not technical:

• How late can someone cancel free of charge?
• Does a no-show get charged, and who decides?
• If a deposit was taken, what is refundable and when?
• When a customer reschedules twice, is that still one booking?
• Who can override any of this, and is it recorded?

Settle these before development, not during. They change the software materially, and discovering them mid-build is how a fixed price stops being fixed. Writing them down also tends to improve the policy itself, because half of these have never been decided — they have been handled case by case by whoever answered the phone.

Staff will keep using their own calendars

Whatever you build, your team will still look at Outlook or Google Calendar on their phone. Plan for that rather than fighting it.

The usual arrangement is one-way: the booking system writes to staff calendars and remains the single source of truth. Two-way sync is possible and sounds better, but it introduces the question of what happens when someone drags an appointment in Outlook — and the honest answers are all a bit unsatisfying.

What it is worth

The return is easy to calculate and usually larger than expected. Count the hours spent arranging bookings by phone and email, the jobs lost because someone could not book at 9pm, and the cost of the double-bookings and no-shows you currently absorb.

Online self-service booking also shifts when people book. A meaningful share of bookings happen outside business hours, from people who would not have rung — which is new revenue rather than the same revenue arriving differently.

Comparing quotes

• Concurrency. Ask the two-people-one-slot question of everyone.
• Which rules are configurable? Some should be changeable by you; some genuinely need a developer. A clear answer about which is which is a sign of experience.
• Payment failures. What the customer sees when a card declines halfway through, and whether the slot is held or released.
• The off-the-shelf question. Anyone who asks whether you have tried an existing product first is being honest with you.

Describe how bookings work in your business — including the rule that broke the last system you tried. Up to five developers will tell you what it takes to build, and whether it is worth building at all.