FEATURES
Everything the product actually does
Each item below is behaviour you can read about in the documentation. Features that depend on your own configuration — a calendar connection, a text provider — say so.
01
Approval, not instant booking
The difference that gives the product its name.
A request is not a booking
A submitted request holds the slot but is never a confirmed appointment. It becomes one only when you approve it, and the confirmation number is issued at that moment.
One set of rules, everywhere
The steps a booking can take are defined once and enforced by the system itself, so a request cannot end up confirmed by an unexpected route.
Offer alternatives
Instead of declining, offer other times. The customer accepts one, declines, or proposes a different time back to you.
Requests expire
A request left unanswered expires on a schedule you set, so stale requests do not hold your availability indefinitely.
02
Availability that reflects reality
Business hours, services, staff and resources, with conflicts re-checked at the moment of confirmation.
Services, staff and resources
Define how long each service takes, what buffer follows it, and which staff member or resource can deliver it.
Business hours and holidays
Opening hours per weekday plus dated exceptions, in your own timezone.
Notice and cutoffs
Minimum notice before a slot, and separate cutoffs for customer cancellation and rescheduling.
Re-checked at confirmation
Availability is checked again when you approve, so two requests for the same slot cannot both become bookings.
03
Google Calendar
Read-only where it should be, and nothing personal written out.
Free/busy in, availability out
Busy time on a linked calendar is removed from the slots customers can request.
Events for confirmed bookings only
Pending, declined and expired requests are never written to Google. Soft holds stay internal.
No customer data in the event
The event carries the service, the staff member or resource, and the confirmation number. No name, email, phone or notes, and no attendees are added, so Google never emails your customers.
04
Email and text
Queued and retried, with consent treated as a precondition rather than a setting.
Email that is not simply fired and forgotten
Each message is queued and retried, so a temporary problem with the mail server does not quietly lose it — and a message that fails never changes the booking itself.
Booking texts are opt-in
A customer is texted only if the business turned texts on and the customer ticked an unticked-by-default box. Changing the phone number drops the earlier consent.
STOP and START are automatic
A customer who replies STOP is suppressed immediately; START lifts it. Both are recorded, and suppression is checked again before every text.
A two-way inbox
Where enabled, replies land in an inbox against the booking rather than disappearing into a gateway.
05
Your booking page
Branded, embeddable, and usable without an account.
Branding
Your logo and colours on the booking page and in email.
Embed it in your own site
A framable booking page for your existing website, rather than sending customers elsewhere.
Your own domain
Serve the booking page on a domain you control.
No customer accounts
Customers manage a request from a secret link in their email — no password, no account, nothing to forget.
Add to calendar
A confirmed booking offers the customer a calendar file.
06
Running the business side
The day-to-day screens, and the parts that matter when something goes wrong.
A dashboard you can install
The business dashboard installs to a phone home screen and can show a notification when a new request arrives.
Team access
Invite colleagues to the business by email.
Data handling you can read
What is stored, where, and why is documented rather than summarised in a slogan.