Skip to content

Booking, member and customer systems

Bookings, members and payments, built around your rules.

For clinics, studios, training providers, clubs and any organisation that runs on a timetable and a member list. We have built booking, membership and scheduling systems in several sectors; the notes are below. Scoping starts with your rules and the systems you already run, including whether an existing product can meet the need.

The initial call is free. Paid scoping, from $1,500 + GST over 2–4 weeks, starts only after you approve what it covers and what it costs.

When a custom system is worth exploring

Usually one of three situations.

The product you use cannot honour your rules
Booking windows, member allowances or blocked periods are being handled by phone or by a person overriding the system.
You pay per member for records you cannot get out
The member list, booking history and balances live in a platform that charges more as you grow and offers no clean export.
Your systems disagree about the same member
The timetable, the membership database and the till each hold a different version of who has paid and what they are entitled to.

If an existing product can meet the need through configuration or a connection, the scope says so.

Booking, membership and scheduling projects

The parts such a system is made of.

Client names are withheld and the role we took is stated on each note. The pictures are schematics, not screenshots.

All project notes
Schematic: a clinic day sheet with three practitioner columns, deposits paid and one no-show flagged. DAY SHEET PRACTITIONER 1 PRACTITIONER 2 PRACTITIONER 3 8:00 9:00 10:00 11:00 12:00 Booked Booked Booked Booked Booked Booked Booked Booked Booked Booked Booked No-show Deposit paid Deposit paid Deposit paid Deposit paid Deposit paid Deposit paid Deposit paid Deposit paid Deposit paid Deposit paid Self-reschedule Open Open Open

Health clinic · Online booking

Online booking with deposits, and follow-ups that survived a platform change

Built by usIn use
Before
The clinic's booking tool could not pass booking details to other systems, so intake forms and review invitations could not be triggered automatically.
Now
We built booking with deposits and practitioner rosters into the clinic's website, then moved bookings to a product its staff preferred while keeping the connection for follow-ups.
Who decides
Staff mark each appointment attended or missed and collect the remaining payment.
Schematic: a member record with tier, prepaid balance, vouchers, consent and a renewal flag. MEMBER RECORD GOLD TIER RENEWAL DUE PREPAID BALANCE VOUCHERS CONSENT Member A Intro session Gift voucher Email yes · SMS no Unused Redeemed

Wellness retreat · Membership

Tiers, prepaid balances and vouchers on one member record

Built by usIn use
Before
Memberships and vouchers were sold at the counter and online, with no single record of who was a member or what they had prepaid.
Now
One member record holds tiers, balances, vouchers and marketing consent. The system reads upcoming bookings and sends the matching form before each visit.
Who decides
The owner approves every campaign before it goes out.
Schematic: a weekly lesson calendar with a recurring slot, one bookable gap and a credits ledger. TERM VIEW MON TUE WED THU FRI WK 1 WK 2 WK 3 WK 4 CREDITS BALANCE Lesson Lesson Lesson Lesson Click to book + Pack – Lesson – Lesson

Private tuition · Scheduling

Lesson slots, prepaid packs and balances on one calendar

Built by usIn use
Before
Lesson bookings, payments and prepaid balances were tracked separately, so it was hard to see who owed money or who was about to run out of credit.
Now
Lessons are booked into empty calendar slots and repeat weekly. The system tracks credits bought and lessons used for each prepaid pack.
Who decides
The teacher confirms each bank transfer and decides when a late cancellation is charged.
Schematic: a care worker's phone listing available shifts with accept and decline buttons. CARE WORKER APP Shifts available Morning · Site A Afternoon · Site B Night · Site A Accept Decline Accept Decline Accept Decline Unavailable: Sat

Care workforce · Shift platform

Shifts published by providers, claimed by workers on their phones

Product scoping and reviewIn use
Before
Care providers filled vacant shifts by phone and checked compliance documents by hand.
Now
Providers post shifts on a calendar, including recurring ones. Workers accept or decline from a mobile web app, mark when they are unavailable, check in on site and submit timesheets. We defined the requirements and reviewed delivery; the client's own development team built the platform.
Who decides
Providers shortlist and hire, and timesheets pass through named approvers.

A mobile app built from one codebase on the same records as a web system is shown in the fleet operations note.

What we check with you

The rules are the product.

A booking screen is the easy part. What members and clients notice is whether the rules they already live by are honoured without a phone call. Scoping answers these questions before the build is priced.

  1. Booking windows and the rush when slots open

    How far ahead each category of member or client may book, what happens when many people book the moment slots open, and how groups and waitlists are handled.

  2. Closures, absences and reserved periods

    Who is notified, in what order, and how refunds or credits are handled when a venue closes, a practitioner is away or a period is reserved for an event.

  3. Payments and cancellations

    Deposits and fees are collected through your own payment provider account, where that provider supports it. Cancellation rules and staff approval points are agreed during scoping; automatic refunds depend on those rules and on what the provider supports.

  4. Existing sector, member and till systems

    During scoping we check what access your existing suppliers allow and confirm which connections are feasible. We agree which records are kept in each system.

  5. Migration of member records

    Whether your current supplier allows member details, balances and future bookings to be exported, how they would be moved and checked, and what you sign off on before the old system is switched off.

  6. What stays in a platform you already have

    We agree which functions stay in your existing platform, such as clinical notes, student records or competition scoring. Any connection to them depends on the access its supplier allows.

  7. Whether a mobile app is needed

    We assess whether members need an installed app, with saved payment details and notifications, or whether a mobile website would meet the same needs, usually at a lower ongoing cost. Where an app is justified, we build iOS and Android apps from one codebase, on the same records your front desk uses, under your own developer accounts.

  8. Support after launch

    Who handles day-to-day support, within what hours, and how urgent faults on a busy morning are dealt with. These are agreed before support starts.

What you get from scoping

A written scope before any build is priced.

Most of the scoping time is spent with the people who run the desk, writing down the rules they apply by hand today.

Stage 1 from $1,500 + GST  ·  2–4 weeks

The scope in writing
The rules and known exceptions the system has to honour, agreed with the people who run the desk.
Which systems stay, and which connections are feasible
Checked against the access your current suppliers allow.
Whether an app is justified
With the ongoing cost of store listings and updates set against a mobile website.
A fixed price for the build, where a build is recommended
Against the agreed scope. A change of scope is priced before we start it.
What still depends on others
Anything that depends on a supplier, a payment provider or a decision you have not yet made, listed in the scope.

Launch, support and handover

Launch
The launch plan sets out data checks, staff training and any period of running the old and new systems side by side, with the length of that period agreed before the build.
Support
Support scope, fees, notice periods and handover arrangements are agreed before support starts. Additional work is scoped and priced separately.
Handover
The member list is your asset. The proposal sets out access to the custom code, data and hosting accounts, together with third-party licences, and, if you choose an app, it is published under your own developer accounts. How we handle data and handover.

Short answers

Have you built this kind of system before?
Yes, for health, wellness and education businesses. For the care workforce platform we defined the requirements and reviewed delivery; the client's own team built it.
Have you built one for a golf club?
Not yet. A tee sheet is a timetable with booking windows and reserved periods, and the work above covers the parts it is made of. A club's competition and handicap platform would stay in place, with any connection subject to the access its supplier allows.
Can we keep the platform our sector requires?
That is the default assumption. Whether it can be connected to depends on the access the supplier allows, which scoping confirms.
Do we have to have an app?
No. Scoping assesses whether an installed app is justified or a mobile website meets the same needs.
What do we have before committing to a build?
A written scope, the systems that stay, the feasible connections, a decision on whether an app is needed, a fixed build price, and what still depends on a supplier or a decision of yours.

Contact

Tell us about your systems.

Tell us which booking and membership systems you use, and what you want to change. We usually reply within one business day to arrange the initial call.

The initial call is free. Paid scoping starts only after you approve what it covers and what it costs.