Custom booking systems for availability rules that get complicated
Booking looks like a calendar problem and turns out to be an availability problem. The calendar is easy. Working out what can genuinely be offered at 2pm on a Thursday is the actual system.
What is booking systems?
Booking Systems are applications that manage availability, take reservations and coordinate the staff, rooms, equipment and payments a booking depends on. They cover scheduling rules, deposits, reminders, rescheduling and cancellation handling. They suit Australian operators whose availability depends on more than one resource being free at the same time.
Get a fixed written quote- Typical timeline
- 9 to 18 weeks
- What drives cost
- The number of resource types that must align, how conditional the rules are, whether payments and deposits are in scope.
- Best for
- Operators coordinating staff, rooms, equipment or vehicles across locations
- You own
- The system, the booking history and the customer records
- Built with
- Resource availability engine, deposits and payments, reminder sequences
Your handover
Why booking projects are really availability projects
The visible part of a booking system is a customer choosing a time. The part that decides whether the project succeeds is the logic underneath, which has to answer a deceptively hard question: can this specific service be delivered at this specific moment. That depends on a qualified staff member being rostered and free, a suitable room or bay being available for the full duration, the equipment being on site rather than at another branch, and enough buffer either side for setup, cleaning or travel between locations.
- 01Documented availability rules including exceptions and buffers
- 02Multi resource scheduling engine with qualification matching
- 03Customer booking flow designed mobile-first
- 04Deposit, prepayment and cancellation policy as configurable rules
- 05Staff console with overrides and a full audit trail
- 06Confirmation, reminder and reschedule messaging your team can edit
- Waitlist with automatic promotion
- Utilisation and cancellation reporting by location and resource
- Calendar and payment gateway integrations
Off-the-shelf tools model one resource well, usually a person with a calendar
Off-the-shelf tools model one resource well, usually a person with a calendar. They start to strain when two or three resources must align, and they break when the rules become conditional. A treatment that requires a specific machine only available on Tuesdays. A trade booking where the travel buffer depends on the previous job's suburb. A class where capacity varies by instructor. We spend the first phase of every booking project writing those rules down precisely, because a rule nobody stated is a double booking waiting to happen.
- Multiple resource types required simultaneously for one booking
- Skill or qualification matching between service and staff member
- Duration and buffers that vary by service, by location or by customer
- Capacity for group sessions with waitlists that promote automatically
- Blackout rules for public holidays that differ by state
The customer sees the terms at the point of booking, not buried in a confirmation email, and agrees to them explicitly.
Deposits, cancellations and the no show problem
No shows are a revenue problem and a morale problem, and deposits are the usual answer. Taking one is straightforward. Taking one in a way that is fair, clearly communicated and holds up under Australian Consumer Law takes more care, and it is worth getting right rather than copying a competitor's terms.
More on deposits, cancellations and the no show problem
We build the deposit and cancellation policy as configurable rules rather than fixed code, because you will want to adjust them once you see real behaviour. Typical patterns include a deposit for first time customers only, full prepayment for high value services, a free cancellation window with a partial retention after it, and an exemption a manager can apply with the reason recorded. The customer sees the terms at the point of booking, not buried in a confirmation email, and agrees to them explicitly. When a cancellation fee is charged, the record shows the policy version in force at the time of booking. The ACCC's guidance on unfair contract terms is a reasonable prompt to keep terms proportionate to the actual loss, and a retention that clearly exceeds it invites disputes you do not want.
How the engagement runs
How a booking build runs
We build the availability engine first and prove it against real scenarios from your operation, including the awkward ones your staff will immediately think of. Getting a booking form on screen early is tempting and usually a mistake, because the interface is quick to build once the rules underneath are settled and slow to rework when they are not.
- 01Rule captureServices, durations, buffers, resources, qualifications and every exception your staff can name
- 02Availability engineBuilt and tested against real historical scenarios before any interface work
- 03Customer booking flowShortest path to a confirmed booking, tested on a phone first
- 04PaymentsDeposits, prepayment, refunds and manager overrides with reasons recorded
- 05Staff consoleCreate, move, split and cancel bookings quickly, with an audit trail
- 06MessagingConfirmation, reminders, reschedule links and waitlist offers, all editable by your team
- 07RolloutOne location or one service line live first, with the old process retired on an agreed date
Two decisions on your side that keep the project moving
Payments, calendar sync and reminders follow, then the staff facing side. The internal view matters more than clients expect. Your front desk needs to override, move, split and merge bookings quickly under pressure, with the changes recorded. A system that is beautiful for customers and awkward for staff will be worked around within a month, and the workaround will be a paper diary.
Reminders, rescheduling and the confirmation chain
The single most effective reduction in no shows is not the deposit, it is the reminder, and specifically a reminder that makes rescheduling easy. A customer who cannot attend Thursday will simply not turn up if the alternative is ringing during business hours. Give them a link that moves the appointment in ten seconds and you recover the slot with enough notice to fill it.
More on reminders, rescheduling and the confirmation chain
So we build the messaging as a sequence rather than a single send: immediate confirmation, a reminder at a lead time you set per service type, and a short notice reminder for high value bookings. Channel matters here. SMS gets read and email does not, but SMS costs money per message and irritates people if overused, so most operators run a mix that we make configurable rather than hard coded. Message content stays editable by your team through SMS and email automation rather than requiring a developer. Waitlists close the loop: when a slot frees up, the system offers it to waiting customers in order with a short window to accept before it moves on.
Multi-location, multi practitioner and the reporting that follows
Once you run more than one site, questions arrive that a single calendar cannot answer. Which location is underutilised on Tuesdays. Which practitioner has the highest rebooking rate. How much revenue was lost to cancellations inside the notice window last quarter. What is the actual utilisation of the room you are considering giving up.
Groups running this way usually pair it with the governance a franchise network needs anyway
We build reporting around utilisation rather than bookings, because a count of bookings hides the important part. A day with fourteen short appointments and a day with four long ones may produce the same revenue with very different resource pressure. Reporting is scoped by role, so a location manager sees their site and a director sees the group. For franchised or multi branch operators this is often the reason to build rather than buy, since consolidated visibility across sites is exactly what per location subscriptions do not give you. Groups running this way usually pair it with the governance a franchise network needs anyway.
When an off-the-shelf booking tool is the better buy
If you are a single location business booking one person at a time for a fixed duration, do not build anything. There are mature hosted products that will have you taking bookings this week for a modest monthly fee, with mobile apps and payment handling included. Building custom for that situation is a poor use of money and we will tell you so on the first call.
The same applies if your industry has a strong specialist product, which several do
The same applies if your industry has a strong specialist product, which several do. Practice management for medical practices and class scheduling for gyms and studios are well served, and those products carry integrations and compliance features that would take a long time to replicate. Custom earns its place when your availability logic genuinely does not fit, when booking must be embedded inside a larger system you already run, or when the data must flow into operations rather than sitting in a separate tool. If the only gap in a good hosted product is that it does not talk to your other systems, workflow automation or a small integration may close it for a fraction of a build.
How we scope it
Four ways to scope your Booking Systems project
We do not publish package prices, because the same brief can be a short build or a long one. These are the shapes the work usually takes. Tell us which one sounds like you and you will get a fixed written quote that spells out exactly what it covers.
Booking Systems Pilot
One team, one process, proven before you commit further
Fixed written quote, agreed before work starts
- Documented availability rules including exceptions and buffers
- Multi resource scheduling engine with qualification matching
- Customer booking flow designed mobile-first
Rollout
The whole department, integrated with what you already run
Fixed written quote, agreed before work starts
- Everything in Booking Systems Pilot
- Deposit, prepayment and cancellation policy as configurable rules
- Staff console with overrides and a full audit trail
- Confirmation, reminder and reschedule messaging your team can edit
Enterprise
Multi site or multi entity, with the governance that needs
Fixed written quote, agreed before work starts
- Everything in Rollout
- Waitlist with automatic promotion
- Utilisation and cancellation reporting by location and resource
- Calendar and payment gateway integrations
Support
Changes, training and support as the business shifts
Rolling monthly, quoted in writing
- Changes and new requirements as the business shifts
- Training for new staff, recorded so it is reusable
- Patching, backups and a restore that has been tested
- Rolling, cancel with 30 days notice
These are shapes, not menus. Most quotes end up somewhere between two of them, and we will say so when the honest answer is the smallest one. Describe the problem and we will tell you which it is.
Questions buyers usually ask
Frequently asked questions
How long does a custom booking system take?
Typically 9 to 18 weeks. The availability engine and rule capture take the first stretch, then the customer flow, payments and messaging. Complexity in the rules drives the timeline far more than the number of screens. If you run several locations, we usually launch one first and roll the rest out afterwards so the process is proven before it is scaled.
What makes one booking system cost more than another?
The number of resource types that must align, how conditional the rules are, whether payments and deposits are in scope, and how many locations and integrations are involved. Rule complexity is the biggest factor by some distance. We capture the rules in a scoping phase and issue a fixed written quote, and any payment gateway or messaging fees are paid by you directly to those providers.
Do we own the booking data and the customer records?
Yes. The database, the code and the cloud accounts are all yours, and customer records can be exported in full at any time. This matters if you are moving off a hosted product, where the customer list is often the hardest thing to get out. We work as collaborators with access you can revoke, and there is no ongoing licence fee to us.
Can it take deposits and refund them automatically?
Yes. Deposits, full prepayment and part payments are supported through your own payment gateway, with the funds going directly to your account. Refunds follow your cancellation rules automatically, and staff can override with a recorded reason. Receipts and tax invoices include the correct GST treatment, and transactions can be pushed into your accounting package so nobody reconciles by hand.
Will it sync with staff calendars?
Yes, two-way sync with Google Calendar and Microsoft 365 is standard. Staff see their bookings where they already look, and personal appointments they mark as busy block availability without exposing the details. We treat the booking system as the source of truth for bookable time, because two systems both believing they own availability is how double bookings happen.
Can customers book across multiple locations?
Yes, and we handle the awkward parts deliberately. Customers can search by location or by earliest availability across sites, travel and setup buffers can differ per location, and public holiday rules follow the correct state rather than a single national calendar. Reporting rolls up across sites while each location manager sees only their own, which is usually the requirement once a group passes three or four sites.
Related services
Describe the booking rule that keeps breaking
The exceptions are the interesting part. Tell us how your availability really works and we will reply within one business day with a fixed written quote.