How to choose salon software

1. Scope and evidence rules

The software decision starts with the business's controlled requirements, not a vendor's feature vocabulary. Scheduling, payments, client records, reporting, integrations, security, migration, and support are separate workstreams. A long public product page does not show whether the exact plan, staff model, service workflow, region, contract, and data obligations work together for one salon. The matrix in this guide is an editorial synthesis recorded in the ledger; no mapped claim prescribes one universal salon specification. [G12-C01 editorial synthesis; no direct v3 citation]

Use four evidence states consistently:

Every evidence record should contain the direct source, page or contract title, vendor legal entity where known, region, plan, billing period, account type, staff and location assumptions, access date, effective date, exact excerpt or demonstration result, limitations, reviewer, and refresh deadline. Public vendor material is first-party evidence of the vendor's own statement only. It is not independent validation of quality or outcomes. [G12-C02]

The capture age matters. Public subscription fields, plan limits, included items, payment conditions, add-ons, and hardware can change quickly. API, connector, export, privacy, security, BAA, migration, and termination terms have different change cycles and must be captured again at the point where the business signs or transfers data. A redirect, region mismatch, changed effective date, expired promotion, inaccessible page, or materially different quote makes the affected field stale.

Do not convert marketing terms such as included, free, unlimited, secure, compliant, easy migration, or open API into broader conclusions. Preserve the exact conditions and exclusions. A plan label does not establish contract scope; a payment relationship does not establish the merchant's duties; a privacy policy does not establish control effectiveness; and an API page does not establish a complete export. [G12-C06, G12-C09]

2. Define the operating requirements first

Create the requirements document before scheduling a product demonstration. The requirements belong to the business and should remain stable enough that vendor language cannot silently redefine the problem. Interview the people who operate reception, calendars, services, payments, reporting, inventory, client records, management, and any regulated workflow. Record current pain points separately from future operating changes.

Map the operating model

Document:

• legal and operating entities that will use the system;
• number and type of locations, suites, mobile routes, rooms, chairs, stations, devices, and shared resources;
• employees, independent professionals, administrators, managers, contractors, accountants, marketers, clinical personnel, and other access roles;
• appointment, walk-in, wait-list, recurring, class, package, membership, deposit, cancellation, refund, gift-card, and service-recovery workflows that actually apply;
• provider, room, equipment, turnaround, processing, travel, and simultaneous-service constraints;
• channels through which a client discovers, books, changes, pays for, or follows up on a service;
• current systems that must send, receive, retain, reconcile, or delete information;
• business hours, outage tolerance, recovery owner, and manual fallback;
• data that is ordinary business information, data that may be sensitive under other law, and any workflow that may involve protected health information after qualified applicability review; and
• the contract date, desired cutover window, retention obligations, and exit deadline.

The goal is not to reproduce everything the current system does. Mark each workflow as retain, change deliberately, retire, or unresolved. Otherwise a migration can preserve an accidental process or introduce a product behavior without an operating decision.

Define acceptance evidence

For every material requirement, specify what would count as proof. Vendor says available is too broad. A better acceptance record might be: A location-restricted front-desk role creates and moves an eligible appointment without viewing another location's client notes; demonstrated in the intended plan on a dated sandbox; audit event and recovery behavior captured. This is an editorial example, not a claim that any listed product supports that behavior.

Separate these evidence layers:

1. Public statement: a current official page describes a product, plan, price, term, policy, or technical interface.
2. Written proposal or contract: the buyer receives dated terms for its entity, region, plan, staff, locations, payment model, implementation, and exit rights.
3. Demonstration: the exact workflow is performed with the intended roles and constraints.
4. Test artifact: a sample export, reconciliation, security configuration record, accessibility task log, migration result, or support response is retained.
5. Qualified review: the responsible operator and required technical, security, accessibility, payments, privacy, healthcare, or legal reviewer approve the evidence within their scope.

No single layer replaces all the others. [G12-C02, G12-C08, G12-C09]

3. Build the requirements matrix

The following matrix is an editorial starting point. Add, remove, or split rows for the real business. It does not establish that every row applies, that a product must implement it in one particular way, or that any vendor has demonstrated it. [G12-C01 editorial synthesis; no direct v3 citation]

Classify requirements without points

Use REQUIRED, CONDITIONAL, or NOT APPLICABLE WITH APPROVAL. Do not turn categories into points or weights. A critical requirement should not disappear inside a combined numeric result. Record whether each requirement is operational, contractual, data, security, accessibility, payments, privacy, healthcare, or exit-related so the correct reviewer sees it.

For a REQUIRED item, define a stop condition. Examples include an unreconciled balance export, inability to limit privileged access, unknown termination retrieval, or inaccessible critical booking path with no approved alternative. These are editorial examples of procurement controls, not statements of law or product quality.

4. Run a business-owned demo

Send the script before the session. Ask the presenter to use the intended region, plan, roles, staff count, location model, payment assumptions, and integrations. Record whether the environment is a production account, sandbox, mock-up, or slide. A promise to follow up remains UNKNOWN - DECISION BLOCKED until the dated evidence arrives. [G12-C02]

Demo preflight

Before sharing any information:

• use fabricated clients and services unless a qualified owner approves a controlled alternative;
• do not expose real client, employee, payment, health, credential, image, or business-confidential records;
• list the account type, plan, region, currency, billing period, user and location assumptions;
• name the vendor presenter, business recorder, operator, technical reviewer, security reviewer, and accessibility reviewer who attended;
• state whether recording is permitted and where the artifact will be retained;
• identify workflows that cannot be demonstrated and the written follow-up deadline; and
• agree that a missing answer remains unknown rather than being inferred.

Core demo script

1. Create the operating structure. Create two fictional roles, two resources with different constraints, one location boundary, service duration rules, buffers, and a deliberate scheduling conflict. Show how the conflict is represented and who can override it.
2. Run client booking. Find a service, choose an eligible time, enter only approved fictional data, review policy text, complete the booking, change it, cancel it, and show every client and staff notification state without sending a real message.
3. Run front-desk handling. Create a walk-in or approved equivalent, assign and reassign a provider, place a client on a wait path if relevant, document arrival, and preserve the event history.
4. Run payment lifecycle. Use the vendor's permitted test method to show a deposit, final payment, tip where applicable, partial or full refund, chargeback information path, payout reconciliation, hardware dependency, and role restrictions. This exercise does not determine PCI DSS scope. [G12-C06; A04, A05]
5. Run package or membership lifecycle. Create a fictional sale, redemption, correction, balance, cancellation, and export. Ask how liabilities and historical events remain traceable.
6. Run client-record permissions. Show what a restricted worker, manager, and administrator can view, edit, export, or delete. Test notes, forms, images, attachments, consent records, and cross-location visibility only with fabricated data.
7. Run reporting reconciliation. Export the raw events for a small fictional day and independently reproduce appointments created, completed, canceled, refunded, and collected. Record time zone, status definition, exclusions, and corrections.
8. Run data retrieval. Export the agreed object set, attachments, identifiers, timestamps, history, and schema information. Open the files outside the product and reconcile record and field counts.
9. Run integration failure. With vendor approval, use a sandbox or narrated controlled case to show delayed delivery, duplicate input, failed authentication, retry, correction, and monitoring ownership. Do not test against production without written authorization.
10. Run privileged access. Demonstrate account invitation, role assignment, MFA where offered, recovery, role removal, session handling, and available logs. The demonstration records a vendor implementation; it is not a certification. [G12-C05; A01] [G12-C09; A02]
11. Run accessibility tasks. Have named evaluators complete the critical client and worker paths with the input and assistive methods relevant to them. Record barriers, workarounds, severity, owner, and retest status. Do not substitute a vendor statement for task evidence.
12. Run the exit. Show how an authorized customer requests final data, which objects and formats are available, what costs and timing apply, what remains retained, how deletion is handled, and what access persists after cancellation.

Demo result log

For every step, capture requirement ID, environment, role, start state, steps, expected result, observed result, evidence link, limitation, follow-up owner, due date, review status, and retest date. A successful demonstration in one environment does not establish the same behavior in another plan, region, role, device, integration, or later product version.

5. Model total cost without invented zeros

The cost register below is an editorial synthesis from the ledger rather than a separately mapped v3 claim. Public commercial pages captured under G12-C02 and G12-C08 are volatile vendor statements; a dated proposal and contract are required for the actual entity and operating model. [G12-C03 editorial synthesis; no direct v3 citation] [G12-C02; V01, V02, V06, V07, V08, V09, V10, V11] [G12-C08; V04, V05]

Bookendo and Salon Guide share common ownership. Bookendo has no pricing evidence in this ledger and requires independent editorial review. Any custom or missing field for any platform is NOT PUBLICLY ESTABLISHED or UNKNOWN - DECISION BLOCKED, not $0. [G12-C10; V03]

Cost register

Record each cost with amount, currency, tax treatment where documented, billing period, volume assumption, staff/location/calendar limit, rate type, source, capture date, contract term, renewal behavior, owner, and uncertainty.

Editorial formulas

evaluation-period software cost = recurring subscription + recurring add-ons and usage + payment costs + acquisition-channel costs + hardware and connectivity + onboarding and configuration + migration + training and change + integration and developer access + qualified review and assurance + support and continuity + termination and retrieval - documented credits

cost per completed eligible appointment = complete evaluation-period software cost / completed eligible appointments in the same period

cost per active authorized worker = complete evaluation-period software cost / active authorized workers in the same period

cost share of collected eligible revenue = complete evaluation-period software cost / collected eligible revenue in the same period

These formulas are editorial modeling choices, not an industry standard or a vendor-endorsed method. Define the period, currency, tax treatment, payment base, acquisition path, refunds, chargebacks, credits, worker status, appointment eligibility, revenue recognition, and duplicated costs before calculation. Do not call any remainder profit or return.

For every division, a missing, zero, or negative denominator makes the output invalid. Display N/A - DENOMINATOR INVALID, preserve the raw inputs, and block division, percentage, trend, or selection output. Never replace the denominator with one and never present the result as zero. If any material cost is missing or custom without a dated quote, display N/A - COST EVIDENCE INCOMPLETE; do not insert $0 and do not calculate a partial total as though it were complete.

6. Validate the cost arithmetic

Every value in this section is an invented EDITORIAL_SCENARIO used only to test the worksheet and arithmetic. No value is a public vendor price, quote, observed Salon Guide result, industry average, recommended budget, forecast, or purchase signal.

EDITORIAL_SCENARIO A - complete fictional annual inputs

A fictional eight-worker business has documented that the following categories are the only applicable categories in its twelve-month exercise. The exercise uses no real product or contract:

The complete fictional cost is:

$3,600 + $960 + $600 + $900 + $500 + $1,200 + $600 + $1,440 + $1,230 + $150 + $350 = $11,530

If the same documented period contains 4,200 completed eligible appointments, then:

$11,530 / 4,200 = $2.745238..., displayed as $2.75 only after the worksheet records its rounding rule.

For 8 active authorized workers:

$11,530 / 8 = $1,441.25 per active authorized worker for the fictional twelve-month period.

These outputs do not establish affordability, business value, product quality, or an appropriate budget. The categories and amounts are artificial. A real business must retain every included source and must block the total if a material category is unresolved.

EDITORIAL_SCENARIO B - missing quote fails closed

A fictional product publishes no price for the required account configuration. The business has documented onboarding, training, hardware, and internal labor assumptions, but it has no dated subscription quote, payment terms, termination retrieval terms, or complete migration scope.

The worksheet displays:

evaluation-period software cost = N/A - COST EVIDENCE INCOMPLETE

It does not enter $0 for the four missing categories, calculate a partial total, or turn the absence of public fields into a favorable conclusion. The next action is a dated written-evidence request.

EDITORIAL_SCENARIO C - invalid denominator fails closed

A fictional business has a complete cost input of $9,600, but its newly defined reporting period has 0 completed eligible appointments because the cutover has not started.

The worksheet displays:

$9,600 / 0 = N/A - DENOMINATOR INVALID

It preserves $9,600 and 0 as raw values. It does not show $0, infinity, a percentage, or a selection conclusion. A negative appointment, worker, or revenue denominator is also invalid data and requires correction rather than calculation.

7. Test data export and API boundaries

Before selection, identify who controls each business record and how the buyer can retrieve a complete, usable copy during service and at termination. The ledger provides partial public evidence: Fresha describes a Data Connector; Square documents Bookings API concepts; Mindbody describes developer tools; Phorest provides developer documentation; Mangomint publishes data-processing terms; and Booksy publishes a privacy policy. These records do not establish complete, included, self-service, contractually portable exports. The object-and-field inventory is an editorial synthesis. [G12-C04 editorial synthesis; no direct v3 citation] [G12-C08; V02A, V08A, V09A, V10B] [G12-C09; V05A, V07A]

Export object inventory

Require a field and object map for every applicable category:

• clients and stable identifiers;
• appointments, statuses, timestamps, time zones, resources, notes, and status history;
• services, durations, buffers, prices, tax fields, categories, and eligibility rules;
• forms, signatures, consents, images, attachments, and their metadata;
• packages, memberships, gift cards, credits, balances, redemption, expiration, and correction history;
• transactions, deposits, tips, refunds, disputes, payouts, fees, and reconciliation identifiers;
• employees, contractors, roles, schedules, permissions, commissions or compensation fields where lawfully stored;
• locations, rooms, equipment, stations, chairs, and other resources;
• products, inventory quantities, units, adjustments, suppliers, and purchase history where used;
• messages, consent events, delivery states, templates, campaigns, and suppression records where applicable;
• audit history, create/update/delete timestamps, actor identifiers, and reason fields;
• integration IDs, webhook delivery history, mapping tables, and error states; and
• deletion, retention, archive, legal-hold, and post-termination behavior.

For each object, record available, not available, unknown, format, field coverage, attachments, history, stable ID, time zone, encoding, request method, frequency, plan, fee, rate limit, support dependency, and termination availability. A dashboard or report is not automatically a full data export.

Sample-export acceptance test

Create a fabricated dataset with known counts and edge cases. Request the export through the same route the buyer would use. Open it outside the vendor system, verify the schema, reconcile record counts, inspect identifiers and timestamps, and test whether attachments and histories remain connected. Record any field transformation or loss. A file that opens is not necessarily complete or usable for migration.

API and connector questions

Ask:

• who may obtain access and under which plan, agreement, region, approval, or partner program;
• whether access is read, write, event, batch, or report-oriented;
• which objects, fields, attachments, histories, and deletion states are exposed;
• how authentication, authorization, rate limits, versions, deprecation, pagination, retries, duplicates, and errors work;
• what fees, implementation work, middleware, developer, monitoring, and support are required;
• whether the interface remains available during notice and after cancellation;
• how the business retrieves data if the integration or vendor service is unavailable; and
• who owns the mapping, monitoring, incident response, and future maintenance.

Public interface documentation does not guarantee unrestricted entitlement, permanent behavior, full-fidelity portability, included engineering work, or migration compatibility. [G12-C08]

8. Verify security, access, roles, MFA, and logs

Security due diligence should be risk-based and should request evidence across governance, identification, protection, detection, response, and recovery rather than relying on one marketing statement. NIST supports this small-business orientation; it does not provide a salon-specific control list or certify a product. [G12-C09; A02]

CISA supports treating MFA as an important account-security requirement. Require MFA for privileged accounts where the product offers it, then demonstrate the exact enrollment, enforcement, recovery, and removal behavior in the intended plan. The authority does not establish that any listed vendor offers or correctly implements MFA. [G12-C05; A01]

Identity and role evidence

Ask the vendor to demonstrate and document:

• unique accounts rather than shared privileged credentials;
• role creation, least-access assignment, location and object restrictions, temporary access, and approval ownership;
• invitation, verification, session behavior, device or location controls where stated, deactivation, and access review;
• MFA methods, enforcement scope, exceptions, recovery, reset, backup method, and support identity checks;
• separation of ordinary administration from the highest-risk actions;
• export, deletion, payment, refund, configuration, integration, impersonation, and support-access permissions;
• failed access, role change, export, deletion, payment, configuration, and recovery logs where available; and
• retention, retrieval, time zone, actor identity, tamper limitations, and customer access for each log.

Roles available is incomplete evidence. The business must see the permissions relevant to its own data and duties. MFA offered is also incomplete if privileged users can bypass it, recovery is undefined, or the buyer cannot enforce it.

Written security evidence request

Request current scoped information for:

• encryption claims and the data, transport, storage, key, backup, and exception scope actually covered;
• data centers, subprocessors, support access, geographic processing, and change notification;
• backup frequency, restoration responsibility, customer testing, recovery dependencies, and data-loss boundaries;
• incident detection, customer notification, cooperation, contact route, and contractual allocation;
• vulnerability intake, remediation, testing, assurance reports, report scope, date, exclusions, and buyer access;
• retention, deletion, archive, residual copies, legal exceptions, and termination behavior; and
• availability commitments, maintenance communication, status information, remedies, and the buyer's manual fallback.

A privacy policy, DPA, security page, assurance label, or vendor statement is not a penetration test, proof that controls work, evidence that no incident occurred, or a customer compliance determination. [G12-C09; V05A, V07A, V10A]

9. Separate privacy, DPA, BAA, and payment duties

Privacy and data-processing terms

Map the parties and purposes before accepting a document title as sufficient. Identify the vendor entity, customer entity, region, categories of people and data, controller/processor or other stated roles, instructions, subprocessors, cross-border treatment, security terms, incident duties, assistance, retention, deletion, audit evidence, amendments, and termination. Save the effective contract version and linked documents.

Mangomint's DPA and Booksy's privacy policy support only the practices and terms each document expressly states. They do not establish independent security effectiveness, complete customer-data retrieval, deletion in every legal circumstance, absence of incidents, or suitability for a particular workflow. [G12-C09; V05A, V07A]

The ledger does not map U.S. state privacy, biometric, consumer-health-data, breach-notification, professional-board, or record-retention requirements. Any workflow involving those areas remains blocked for jurisdiction-specific review and additional authoritative evidence.

HIPAA and BAA boundary

Do not assume that every salon, spa, or medspa is a HIPAA covered entity or business associate, and do not assume ordinary salon client data is automatically protected health information. Determine the parties, services, data, and applicability with qualified review first. When a covered entity or business associate uses a cloud service for electronic protected health information, HHS guidance supports evaluating safeguards and, where applicable, a BAA. A BAA statement or signed BAA does not by itself make the customer compliant. [G12-C07; A06, A07]

Mangomint's captured pricing page included a scoped vendor statement about BAA availability for specified plans. That record does not establish that a particular buyer needs a BAA, that every plan or workflow is covered, or that the customer or product satisfies every applicable duty. [V05]

For any potentially clinical workflow, separate:

• professional and entity status;
• exact data elements and whether electronic protected health information is involved;
• permitted collection, access, disclosure, amendment, retention, and deletion;
• vendor and subprocessor roles;
• contract and BAA scope where applicable;
• authentication, logging, backup, incident, and termination evidence; and
• state and professional obligations not addressed by this ledger.

Payment and PCI DSS boundary

Using a software or payment provider does not by itself establish that the merchant has met PCI DSS responsibilities. The business must work with its acquirer and payment relationships to determine its environment, responsibility split, validation path, and current questionnaire eligibility. This guide does not select an SAQ, define scope reduction, certify a vendor, or provide a compliance conclusion. [G12-C06; A04, A05]

Document card-present, keyed, online, stored-credential, deposit, recurring, terminal, reader, virtual, refund, chargeback, payout, and third-party integration paths that actually apply. Record which party provides each component and who manages accounts, devices, updates, staff access, support, incident handling, and evidence. Do not broaden a vendor's payment statement to every channel or merchant category.

10. Test accessibility with real tasks

This ledger contains no accessibility authority, conformance report, independent audit, or vendor-specific accessibility result. Accessibility therefore remains an evidence gap and requires a named accessibility reviewer plus additional authoritative sources before publication. The process below is an editorial procurement test design, not a conformance standard or claim about any platform.

Test the critical client and worker tasks with the people, devices, input methods, assistive technology, languages, environments, and support paths relevant to the business. Include, where applicable:

• finding a service and understanding eligibility, duration, price, provider, location, and policy;
• selecting a date and time, resolving an unavailable slot, and recognizing a conflict;
• entering and correcting information, understanding required fields, and recovering from an error;
• reviewing consent or policy information without losing progress;
• completing, changing, and canceling a booking;
• completing the permitted payment path and understanding the result;
• receiving and acting on confirmation, reminder, change, failure, and recovery information;
• signing in, using MFA, recovering an account, and ending a session;
• navigating staff calendars, client records, reports, and role-restricted tasks;
• using keyboard or other required input, screen-reader or magnification workflows where relevant, and high-zoom or small-screen layouts; and
• obtaining human assistance without surrendering unnecessary credentials or sensitive information.

Record the exact task, environment, user role, access method, expected result, observed barrier, workaround, business impact, evidence, owner, target fix, retest, and residual risk. A vendor statement, automated result, or successful task by one user does not establish that all users and workflows are accessible. Do not transfer real client data during testing.

If a critical task fails, do not silently make telephone or staff intervention the permanent fallback. Determine whether the alternative is available, understandable, timely, privacy-preserving, secure, and operationally owned, then obtain qualified review. Otherwise the affected workflow remains blocked.

11. Plan migration, rollback, termination, and retrieval

A migration plan should define field mapping, test import, reconciliation, cutover, rollback, client communication, record retention, and post-cutover validation before the prior system is canceled. This sequence is an editorial synthesis. The sources do not establish one universal procedure, completion time, or vendor-specific success. [G12-C08; V02A, V04, V05, V08A, V09A, V10B]

Phase 1 - authority and inventory

Name the executive owner, operations owner, data owner, technical owner, security owner, privacy owner, accessibility owner, payments owner, vendor contacts, and rollback decision-maker. Inventory systems, interfaces, devices, merchant relationships, domains, phone numbers, messages, forms, policies, reports, and manual workarounds. Define the authoritative source for each object.

Phase 2 - extraction and mapping

Obtain a buyer-controlled sample export. Create a field map from source object and field to destination object and field, transformation rule, default prohibition, owner, evidence, and reconciliation test. Never invent a missing consent, status, balance, timestamp, identifier, or policy acceptance. Place unsupported fields in an exception queue.

Phase 3 - trial import

Use fabricated or properly controlled data and an approved non-production environment where available. Test ordinary cases plus duplicates, missing identifiers, overlapping appointments, time zones, recurring events, shared resources, attachments, images, forms, balances, partially redeemed value, refunds, inactive workers, archived clients, and deleted or retained states. Record every rejected, changed, truncated, merged, or unsupported field.

Phase 4 - reconciliation and operating rehearsal

Reconcile counts and values at object, status, date, location, and balance level. Have the intended roles run booking, change, cancellation, payment, refund, reporting, export, access recovery, and fallback tasks. Complete accessibility and security reviews. Resolve whether each exception is corrected, manually handled, retained in an archive, or blocks cutover.

Phase 5 - cutover and rollback controls

Define:

• final source-system change window and who may enter updates;
• final extraction, checksum or other integrity record, and storage protection;
• destination import sequence and reconciliation owners;
• payment, device, domain, booking-link, messaging, integration, and staff-access changes;
• approved client and staff communication, with separate consent and legal review where needed;
• go/no-go checkpoints, maximum unresolved variance, stop authority, and evidence location;
• manual continuity procedures and status communication; and
• rollback trigger, decision deadline, source-system readiness, reverse-entry plan, and reconciliation after rollback.

Do not define an acceptable variance merely to fit a result. A qualified operator and data reviewer must approve thresholds for the actual records and obligations.

Phase 6 - post-cutover validation

Validate booking, resources, roles, client records, balances, payments, payouts, refunds, reports, messages, integrations, exports, logs, support access, accessibility, and fallback procedures. Track exceptions to closure. Preserve the source snapshot and required records under approved retention and access controls.

Phase 7 - termination and final retrieval

Do not cancel the prior service until the authorized owner confirms the final export, attachments, histories, balances, audit information, retention plan, operational validation, and rollback decision. Save the cancellation notice, effective date, final invoice, service-end behavior, export method and cost, support route, deletion or retention statement, and any post-termination access.

Termination evidence must answer:

• how and when the customer requests data;
• what objects, fields, attachments, metadata, formats, and history are included;
• whether professional services, developer access, fees, or active subscription are required;
• how long retrieval remains available;
• what the vendor retains, deletes, archives, or cannot delete and why;
• what happens to integrations, client booking links, payments, messages, domains, and devices; and
• how the business proves that final records reconcile.

12. Use the procurement worksheet

Copy this worksheet into the controlled project record. Keep evidence links restricted if they contain confidential, security, contractual, payment, employee, or client information.

Business and decision record

Requirement record

Cost record

If the amount is custom, missing, stale, or inaccessible, enter UNKNOWN - DECISION BLOCKED; never enter $0 unless a dated applicable contract expressly establishes a zero charge for the exact field and a reviewer confirms its conditions.

Demo and evidence request

Decision gate

The responsible reviewers should record each required item as PASSED WITH EVIDENCE, CONDITIONALLY ACCEPTED WITH NAMED OWNER, or BLOCKED. A condition must state the exact limitation, owner, deadline, fallback, and authority to stop. Do not collapse blocked requirements into a combined number. The final approval must reference the immutable evidence bundle and signed contract version reviewed.

13. Read the eleven-platform evidence inventory

This inventory reports only what types of public first-party evidence were captured on 2026-07-12 and the minimum missing evidence recorded in the G12 ledger. It does not establish current terms, quality, fit, implementation results, or a purchasing conclusion. Each field requires live recapture and human review before publication or procurement use. [G12-C02]

Material relationship disclosure: Bookendo and Salon Guide share common ownership. Bookendo receives the same evidence burden as every other platform, plus an independent named reviewer who must confirm equal treatment. Its related-party source cannot support preferential placement or a purchase conclusion. [G12-C10; V03, A03]

The row order carries no editorial meaning. A larger public evidence set does not establish stronger product capability or suitability; it only shows which source types were captured in this ledger. Absence from a public source is UNKNOWN, not evidence that a capability, fee, control, or right does not exist.

14. Adapt the process by business type

The core evidence method stays the same, but workflows, capacity constraints, records, access, and review needs change. These paths identify questions; they do not state that a platform supports them or define professional, privacy, health, safety, payment, employment, or recordkeeping duties.

Hair salon

Test provider and assistant handoffs, chair and bowl constraints, processing blocks, multi-service appointments, consultations, formula or service notes where lawfully stored, corrections, deposits, retail, and provider/location reporting. Determine which notes and images are actually necessary, who may access them, how they export, and how a complex appointment survives migration.

Barbershop

Test walk-in, wait-path, appointment, chair/provider assignment, reassignment, no-show/cancellation, tips, cash and card reconciliation, recurring clients, and busy-period fallback. Do not assume an appointment calendar represents queue events or that one worker model applies to every shop.

Nail salon

Test station and pedicure-resource constraints, simultaneous or sequential service components, recurring maintenance timing, deposits, packages, retail, product or service notes, role restrictions, and multi-language client paths where relevant. Keep sanitation, ventilation, licensing, and safety obligations in their qualified workstreams; a software field does not establish compliance.

Nonmedical spa

Test room, equipment, provider, turnover, intake, package, membership, gift-card, cancellation, privacy, and service-recovery workflows. Determine whether forms, notes, contraindication prompts, images, and attachments are necessary and how they are restricted and exported. Do not turn a form template into clinical authority.

Medspa or mixed clinical setting

First determine legal entity, professional scope, supervision, covered-entity/business-associate status, exact data, and applicable federal and state duties with qualified reviewers. Then test clinical/nonclinical separation, privileged access, logging, forms, images, attachments, ePHI handling where applicable, BAA and DPA scope, integrations, retention, export, incident responsibilities, and termination. No platform record in this ledger establishes clinical suitability or customer compliance. [G12-C07; A06, A07]

PMU, brow, or lash studio

Test appointment duration and follow-up, setup and room resources, deposits, forms, consent records, before/after images, product or lot information where required by the approved workflow, healing or follow-up messages, role access, export, withdrawal, retention, and deletion. Qualified review must decide what may be collected and communicated.

Independent or mobile professional

Test owner-only and delegated access, service area, travel buffers, changing locations, mobile connectivity, small-device tasks, offline or outage fallback, payment hardware, account recovery, data export, and termination without a separate IT team. Do not accept shared credentials as a substitute for a defined helper role.

Salon suite and multi-entity environment

Determine which entity owns the client relationship, merchant account, booking page, domain, messages, records, reviews, balances, and contract. Test tenant and landlord boundaries, location-limited roles, administrator visibility, departure export, client authorization, shared resources, and what happens when one professional leaves. A shared physical address does not establish shared authority over data.

Multi-location group

Test location-specific schedules, services, prices, taxes where documented, staff transfers, resources, inventory, packages, gift cards, reports, merchant relationships, roles, data visibility, and location closure. Record whether central and local owners can retrieve the required data without exposing another location unnecessarily.

15. Avoid common procurement failures

1. Starting with a product tour before the business has written requirements.
2. Treating the longest public feature page as evidence of operational fit.
3. Assuming an unlisted, custom, or unanswered cost is $0.
4. Copying a promotional field without its expiration, region, plan, billing period, or eligibility.
5. Mixing subscription, processing, acquisition, hardware, migration, training, integration, and exit costs into one unexplained amount.
6. Accepting a dashboard when raw records, stable identifiers, attachments, or history are required.
7. Treating API or connector documentation as proof of complete, included, permanent access.
8. Migrating clients and appointments while omitting balances, value instruments, forms, images, consent events, corrections, and audit history.
9. Canceling the prior service before final retrieval, reconciliation, operational validation, and rollback closure.
10. Accepting roles without testing exact permissions, location boundaries, export, deletion, payment, support, and recovery access.
11. Accepting MFA without testing enforcement, exception, recovery, reset, and removal behavior.
12. Treating a security page, privacy policy, DPA, BAA, or assurance label as proof that controls work or the customer has met its duties.
13. Assuming every beauty-business record is subject to HIPAA, or assuming no other privacy duties can apply.
14. Letting real client or employee data enter a sales demonstration without approved controls.
15. Substituting an automated accessibility result or vendor statement for real critical-task testing.
16. Allowing a material ownership relationship to change evidence burden or editorial treatment.
17. Combining unresolved critical requirements into a numeric result that hides the failure.
18. Publishing volatile vendor statements without field-level recapture and named human review.

16. Continue with related Salon Guide resources

• Salon business plan - define the operating model, responsibilities, costs, milestones, and evidence before procurement.
• Salon inventory - define item, unit, location, adjustment, permission, and export requirements.
• Reduce salon no-shows - map booking, policy, consent, outcome, and measurement workflows before requesting automation.
• Salon client retention - define client, cohort, event, return window, raw counts, and data limitations.
• Monthly KPI worksheet - retain versioned inputs, denominators, definitions, exclusions, and evidence owners.
• Editorial standards - review evidence, conflicts, corrections, and approval expectations.
• How we make money - Bookendo and Salon Guide share common ownership; review that relationship and the separation among Salon Guide, Bookendo, and SalonSoftwareGuide.com.
• Accessibility - review the site's current accessibility commitment and contact path.

These links do not authorize publication of G12 or endorse a product. Software provider reviews and current commercial vendor-versus-vendor research belong to SalonSoftwareGuide.com under its own methods and disclosures, not to this educational guide.