
What to take into the next team meeting
- Convert the service menu into resource and sequence requirements before comparing products.
- Ask every shortlisted supplier to run the same difficult scenarios using real spa services and policies.
- Evaluate guest booking, daily operations, disruption and reporting as one connected system.
- Treat accessibility, price transparency, data exit, security evidence and implementation effort as buying criteria.
Most spa software comparisons begin with features. That is too late.
First decide what a valid spa visit requires. Then ask software to prove it can protect that model through booking, preparation, delivery, payment, change and reporting.
This guide is deliberately supplier-neutral. It sits between the operational spa scheduling guide and a commercial product comparison: use it to prepare a test pack before speaking to vendors.
Define the spa you are buying for
Write a one-page operating profile:
| Dimension | Questions to answer |
|---|---|
| Services | Are they single treatments, consultations, courses, packages or facility access? |
| People | Which qualifications, skills, gender preferences or language needs affect assignment? |
| Rooms | Are rooms interchangeable, treatment-specific, accessible, wet, double or capacity-limited? |
| Equipment | Which devices, tables or facilities are shared and scarce? |
| Guests | Do you serve individuals, couples, groups, hotel guests, members or day visitors? |
| Money | Are there deposits, prepayments, vouchers, packages, memberships, tips or room charges? |
| Channels | Website, reception, phone, hotel concierge, WhatsApp, marketplace or API? |
| Locations | One spa, several spas, hotel properties or a shared client record? |
Avoid buying for an imaginary average spa. A simple massage studio and a hotel spa with thermal facilities, couples rooms and room charging need different evidence.
Convert services into requirements
For ten representative services, document:
- advertised duration;
- therapist occupancy;
- room occupancy;
- preparation and turnaround;
- required skill or approval;
- required room and equipment;
- booking lead time;
- guest preparation;
- price, tax and unavoidable charges;
- deposit and change rules;
- consultation or form dependency;
- appropriate next step after attendance.
This becomes the supplier’s test data. If the system cannot model the inputs, a feature tick beside “resource scheduling” is meaningless.
Use a 12-scenario demonstration
Ask every supplier to run the same scenarios live. Do not accept slides or “the implementation team can configure that later” as evidence.
| Scenario | What the software must prove |
|---|---|
| 1. Simple repeat visit | A guest can rebook the right service without re-entering unnecessary data |
| 2. Skill-dependent treatment | Only suitably assigned therapists appear |
| 3. Room-dependent service | Therapist and correct room are reserved together |
| 4. Shared device | Two rooms cannot promise the same equipment simultaneously |
| 5. Couples treatment | Two guests, suitable therapists and one double room align |
| 6. Multi-service package | Sequence, transitions and separate resource footprints remain valid |
| 7. Group spa day | Organiser, attendees, capacity and payment responsibilities stay clear |
| 8. Late client | Staff can see the effect on later services and choose a controlled response |
| 9. Therapist sickness | Affected visits, alternatives and communications become visible |
| 10. Room closure | Availability changes without deleting historical context |
| 11. Cancellation and refill | Terms, money, released resources and wait list stay connected |
| 12. Data exit | Representative records export in an understandable, reusable form |
Record each result as:
- Demonstrated: completed live with the intended outcome.
- Partial: completed with a documented limitation.
- Workaround: depends on a manual process with an owner and time cost.
- Unproven: described but not shown.
Do not convert those states into a complicated weighted score. A single unproven safety, payment or data-exit requirement may matter more than twenty convenient features.
Test the mobile guest journey
Use an ordinary phone, not the supplier’s presentation screen.
Start from a service page and observe whether a first-time guest can:
- understand the treatment and suitability boundary;
- see the total price and duration;
- choose a valid person or “any suitable therapist”;
- understand location and arrival time;
- complete only necessary fields;
- use a clear payment method;
- review details before committing;
- receive a useful confirmation;
- change or request help without starting again.
Current CMA price-transparency guidance says mandatory fees and charges should normally be included in the total price shown to consumers rather than added later. Review the CMA’s January 2026 price-transparency summary against the exact booking journey.
Ask the supplier to demonstrate a failed payment, a back-button journey, an expired session and a guest who does not create an account. The happy path is rarely where software costs the spa time.
Check accessibility as a complete process
An attractive booking widget is not automatically usable.
Test keyboard navigation, zoom, focus visibility, date and time selection, error messages, screen-reader names and whether the guest can review and correct information before payment. WCAG 2.2 requires labels or instructions when content needs user input and text identification when errors are detected. The W3C provides current explanations for labels and instructions and error identification.
Include real users where possible. Automated checks cannot tell you whether service language, time selection or a multi-guest flow is understandable.
Test packages as sequences, not products
A package may combine treatments, therapists, rooms, facility access, breaks and food or beverage. Ask the system to:
- find a valid complete sequence;
- show the guest one coherent arrival plan;
- reserve each resource for its real footprint;
- allow one component to change without corrupting the rest;
- price inclusions and optional extras clearly;
- record partial use, expiry and remaining entitlement;
- report revenue and delivery accurately.
Then remove the middle treatment. Watch which rooms, people and entitlements are released. A system that can only delete and rebuild the package may create errors during a busy reception shift.
Put disruption on the demo agenda
Ask the supplier to begin with a full Saturday and then introduce:
- one therapist calling in sick;
- a couples room closing;
- a 30-minute overrun;
- a guest arriving late;
- a package component becoming unavailable;
- a duplicate client record;
- a refund requiring manager approval.
Observe:
- what becomes invalid;
- who is notified;
- whether the original context remains visible;
- which resources are released;
- how the guest is contacted;
- whether the report distinguishes salon and guest changes.
The important question is not “can reception edit an appointment?” It is “can the team understand the consequence before saving the edit?”
Review deposits, cancellations and refunds
The system should show the relevant terms before commitment, apply them consistently and still allow an authorised human exception.
UK government guidance says cancellation terms and retained payments must be fair, and charges should reflect the business’s direct loss rather than act as excessive penalties. Use the current guidance for writing fair customer contracts as a review prompt, not as a substitute for advice.
Test:
- partial and full deposits;
- rescheduling inside and outside the policy window;
- cancellation by the spa;
- package and multi-guest refunds;
- expired or failed cards;
- charge reconciliation;
- reason codes and approval history.
Do not accept a refund feature that disconnects the payment record from the appointment outcome.
Inspect client data and privacy controls
Map each field to a purpose. Spa records may include ordinary contact data, preferences, consultation information and potentially more sensitive information depending on the service.
The ICO’s current data-protection-by-design guidance says organisations should decide what personal information is needed before use and limit processing to the purpose. Ask the supplier to show:
- role-based access;
- change and access history;
- configurable forms and field visibility;
- consent and communication-purpose records;
- retention and deletion controls;
- subject-access and correction workflow;
- supplier locations and subprocessors;
- attachments and special-category data handling where relevant;
- complete export and contract-end deletion.
Avoid a single “GDPR compliant” badge. Compliance depends on how the spa configures and uses the service as well as what the supplier provides.
Ask for security evidence, not adjectives
“Secure”, “encrypted” and “cloud-based” are claims, not a due-diligence response.
The UK National Cyber Security Centre recommends assessing how a cloud provider meets security goals and what evidence supports those claims. Its choosing-a-cloud-provider guidance provides a proportionate starting point.
Request evidence relevant to:
- identity, multi-factor authentication and privileged access;
- encryption and key management;
- backups, recovery objectives and restoration tests;
- incident detection and notification;
- independent assurance and scope;
- service administration and supplier personnel;
- business continuity;
- vulnerability handling;
- data location, portability and deletion.
Scale the review to risk. A small day spa does not need to imitate a bank, but it should understand what it is trusting.
Calculate the complete operating cost
Use a three-year model:
Total operating cost = subscription + locations + users + messages + payments + marketplace fees + integrations + devices + setup + migration + training + support + manual workaround time − credible savings
Model at least three booking-volume scenarios. Payment and messaging charges often move with usage; team and location pricing moves with growth.
Separate:
- contracted fees;
- variable supplier fees;
- third-party fees;
- internal implementation time;
- ongoing reception work;
- cost of a failed or delayed migration.
Ask what happens at renewal, cancellation and export. A low first-year price is not a complete commercial model.
Test integrations by event
Do not ask only whether two products “integrate”. Choose events:
- booking created, changed and cancelled;
- deposit paid and refunded;
- consultation completed;
- guest checked in and attended;
- package entitlement used;
- feedback received;
- client merged or deleted.
For each event, record direction, delay, ownership, duplicate handling and failure recovery. An integration logo without those answers can create silent data gaps.
Plan migration before signing
Request a sample export from the current system and a sample import template from the new one. Reconcile:
- active clients and duplicates;
- future appointments;
- historical appointments;
- balances, deposits and vouchers;
- packages and memberships;
- notes, forms and attachments;
- permissions and marketing preferences;
- staff and resource mappings;
- financial and operational reports.
Run the old and new views against a controlled sample. Define the cutover point, rollback decision and who can approve discrepancies.
Use a 30-day evidence plan
Days 1–5 — model: build the service requirements table and select twelve scenarios.
Days 6–12 — demonstrate: run the same script with shortlisted suppliers and capture limitations in writing.
Days 13–18 — verify: review cost, contract, data, security, accessibility, integrations and support.
Days 19–25 — pilot: configure representative services and let reception and therapists complete real tasks.
Days 26–30 — decide: compare demonstrated outcomes, unresolved risks, implementation effort and exit options.
The result should be a decision record, not a feature spreadsheet. Good spa management software must support the actual spa scheduling model, but it should also make the guest journey, money, data and daily exceptions easier to understand.
Sources and standards checked for this 2026 guide
- CMA: clear and accurate price information
- GOV.UK: fair contracts, deposits and cancellation charges
- ICO: data protection by design and by default
- NCSC: choosing a cloud provider
- W3C: Web Content Accessibility Guidelines 2.2
These sources support the legal, privacy, security and accessibility checkpoints. The scenario pack and buying framework are original operational guidance; adapt them to the spa’s services and obtain specialist advice where the risk requires it.

