Privacy and data handling
What customer data is stored, why, what is never stored, and what is not loaded into the page.
The principle is to store what is needed to run bookings and nothing else. There are no advertising trackers, no analytics SDKs and no profiling, and the application loads no third-party scripts, fonts or pixels.
What is stored about a customer
| Data | Why |
|---|---|
| Name and email | To identify the request and send status email. |
| Phone number | So the business can contact the customer about the appointment. Optional unless the business requires it. |
| The note and any answers to the business's own questions | Information the business asked for in order to do the job. |
| Messages exchanged while agreeing a time | The record of what was agreed. |
| Requested and confirmed times, service, staff or resource, references | The booking itself. |
| A management link | So a customer can manage their request without creating an account. Stored hashed. |
| A delivery log | To prove and diagnose delivery. Records the kind of message, the address and the outcome — never the message body. |
What is never stored
- Payment details. Customers do not pay through the booking flow.
- Customer accounts or passwords — a customer never creates one.
- Device fingerprints, or IP addresses against sessions.
- Marketing consents, because there is no marketing send.
Texts and consent
A text is sent only to a customer who ticked an unticked-by-default box, and a reply of STOP suppresses the number at once. See Booking texts, STOP and START for the full set of conditions.
Note on scope
This page describes how the software handles data. It is documentation, not a contract: the business taking the booking is the data controller for its own customers and is responsible for its own privacy notice.