The independent clinic software buyer's checklist

Good clinic software is not the product with the longest feature list. It is the product that can show how a real appointment moves from booking to preparation, care, payment and follow-up - with clear ownership and no invented certainty.

How to use this checklist

Pick two or three journeys that happen in your clinic every week. Use the same examples in every demonstration: a new client booking, an existing client completing a form, a practitioner needing the relevant record, a refund or failed message, and a person leaving the team. Ask the supplier to show the journey rather than answer with "yes".

1. 0 - Not shown: the supplier cannot demonstrate it or the answer depends on future development.
2. 1 - Partly shown: it works with manual steps, additional tools, limits or provider activation.
3. 2 - Clearly shown: it works end to end, with responsibilities, status and costs explained.

Print this page from your browser or save it as a PDF. Write the score and any condition beside each item. A condition such as "available after payment-provider onboarding" is not necessarily a problem; an unclear condition is.

1. Booking and diary

Booking should reflect the way the clinic actually works, not force every service into the same appointment shape. Test it with a real treatment duration, consultation, practitioner schedule and room or location.

• [ ] Can availability vary by practitioner, service, day and location?
• [ ] Can the clinic apply buffers, preparation time or sensible booking windows?
• [ ] Does the public booking journey show only genuinely available choices?
• [ ] Can staff see why a slot is unavailable without exposing private information?
• [ ] Are confirmations, cancellations and change requests clearly distinguished?
• [ ] If a client requests a change, does the original appointment remain clear until the clinic confirms?
• [ ] Can the supplier demonstrate the mobile booking journey and its error states?
• [ ] Are deposits, cancellation terms and booking policies explained before commitment?

Ask to see a double-booking edge case, a practitioner absence and a client request to move an appointment. These reveal more than a clean diary screenshot. See how Rytura describes online booking and the connected clinic journey.

2. Client portal and client experience

A portal earns its place when it removes uncertainty for clients and repeat administration for the clinic. It should not simply put another password in front of information clients cannot use.

• [ ] Can clients securely see upcoming appointments and appropriate client-facing history?
• [ ] Can clients find and complete the forms assigned to them?
• [ ] Are pending, completed, overdue and clinic-confirmation states written plainly?
• [ ] Can the clinic control what is client-facing and what remains inside the clinical workspace?
• [ ] Does the portal work comfortably on a small phone screen and with keyboard navigation?
• [ ] Are sign-in, expired-link and locked-out journeys explained clearly?
• [ ] Can clients request a booking change without the software pretending it is already approved?
• [ ] Can the portal use the clinic's identity without obscuring who provides the underlying service?

Ask the supplier to log in as a sample client during the demonstration. Check the actual experience against its client portal description, including what clients cannot see.

3. Records, forms and consent

A digital form is not the same as valid consent, and a software role is not evidence of competence. The system should support a controlled process while leaving professional judgement and clinic governance with the right people.

• [ ] Are client records structured, searchable and restricted to authorised users?
• [ ] Can the clinic distinguish medical, consent, policy and aftercare forms?
• [ ] Are form versions controlled so the clinic can identify what a client completed?
• [ ] Are authorship, completion time and later changes traceable?
• [ ] Can access be limited by real responsibility rather than a single all-powerful staff login?
• [ ] Does the supplier explain which records are client-facing and which are private?
• [ ] Can the clinic export the record, completed forms and relevant audit information?
• [ ] Does the product avoid claiming that software completion alone proves informed consent?

Review the supplier's detail on patient records and digital consent forms. If professional roles or prescribing are mentioned, ask how credentials are verified. Rytura does not currently perform live register checks or offer in-platform prescribing; those responsibilities cannot be inferred from a software role.

4. Payments and financial ownership

Establish who owns the payment relationship before comparing button designs. Provider onboarding, settlement, refunds, disputes and fees should be visible to the clinic rather than hidden behind a generic "payments included" claim.

• [ ] Is the clinic using its own payment-provider account?
• [ ] Who is merchant of record and where do funds settle?
• [ ] Who controls refunds, disputes and payout settings?
• [ ] Are provider fees separate from the software subscription and stated clearly?
• [ ] Does the product show whether payments are activated, pending or unavailable?
• [ ] Are staff prevented from pasting passwords or secret API keys into ordinary settings screens?
• [ ] Can the clinic reconcile appointments, payments, refunds and payouts?
• [ ] What happens to payment access and records when the contract ends?

Rytura's clinic payments page explains the Stripe setup: the clinic completes onboarding and activation, and saved details alone do not mean payments are live.

5. Security, privacy and access

Ask for specific controls and specific boundaries. "GDPR compliant" on its own does not explain how access is granted, reviewed, removed or investigated.

• [ ] Is multi-factor authentication available or required for sensitive staff access?
• [ ] Can owners separate owner, management, reception and clinical permissions?
• [ ] Is access removed promptly when someone leaves or changes responsibility?
• [ ] Are important changes and sensitive actions recorded in an audit trail?
• [ ] Are data encrypted in transit and protected appropriately at rest?
• [ ] Does the supplier explain hosting regions, subprocessors and international transfers?
• [ ] Is there a clear data-processing agreement, retention policy and incident process?
• [ ] Can the clinic test restore, continuity and support arrangements rather than assuming them?
• [ ] Does the system avoid treating a role label as proof of a qualification or registration?

Use the supplier's security and privacy information as the start of due diligence, not the end. Your own legal, information-governance and clinical advisers should assess the arrangement for your clinic.

6. Provider activation and operational status

Email, SMS, payments and other connected services often depend on third-party checks. The software should distinguish configuration saved, verification pending, connected and ready to use.

• [ ] Which features depend on a separate provider account or approval?
• [ ] Who completes identity, business, sender or banking verification?
• [ ] Does the screen show real provider status rather than an optimistic local toggle?
• [ ] What happens if onboarding is rejected, delayed or expires?
• [ ] For SMS, are sender names, dedicated numbers, replies and country rules explained separately?
• [ ] Are message credits, number rental and carrier fees included or charged separately?
• [ ] Can the clinic continue safely when a provider is unavailable?
• [ ] Is support ownership clear when the issue sits with the third-party provider?

Rytura describes SMS as available on paid plans after approval, UK messaging setup and the purchase of separate credits. Ask every supplier to be equally precise about dependencies.

7. Costs, plan limits and contract

Compare the normal monthly cost for your likely clinic in twelve months, not only the entry headline. Include team growth, locations, client volume, messages, payments and any onboarding or migration work.

• [ ] Is the subscription price clear, including VAT treatment?
• [ ] What are the limits for practitioners, locations, clients, storage and forms?
• [ ] Which useful capabilities sit in a higher plan or paid add-on?
• [ ] Are SMS credits, dedicated phone numbers, email volume and provider fees separate?
• [ ] Is onboarding, migration, training or priority support charged separately?
• [ ] How and when can prices, plan inclusions or usage rates change?
• [ ] What is the initial term, renewal cycle, cancellation notice and refund position?
• [ ] Is a trial genuinely usable, and which features are unavailable until activation?

Put every recurring and usage-based cost on one page. Then compare it with the supplier's current published pricing and plan inclusions and the contract you are actually offered.

8. Data export, migration and exit

The easiest time to discuss leaving is before joining. A clinic should know what can be taken out, in what format, how long it takes and what remains after termination.

• [ ] Can clients, appointments, records, forms and financial references be exported?
• [ ] Are structured formats available, not only screenshots or one large PDF?
• [ ] How are documents and attachments linked to the exported record?
• [ ] Is relevant authorship, version and audit context preserved?
• [ ] Who performs migration in, and how are imported records checked?
• [ ] What export assistance, time limits and charges apply?
• [ ] What data must be retained after termination, for how long and on what basis?
• [ ] How does the supplier confirm deletion when retention is no longer required?

Demonstration questions that expose weak answers

1. Show me a new client moving from booking to assigned form to the clinic record and client portal.
2. Show me what a receptionist can see, then what a clinical user can see.
3. Show me a payment integration that is configured but not yet activated.
4. Show me a failed SMS or email and who is told what to do next.
5. Show me what happens when a practitioner leaves the clinic today.
6. Show me the export we would receive if we ended the contract.
7. Tell me which parts of that journey are not live, depend on another provider or require manual support.

Red flags

• A saved setting is described as "connected" without a verified provider response.
• Everyone shares one login or every staff member receives the same access.
• A role such as doctor, nurse, practitioner or prescriber is treated as proof of authority.
• The supplier cannot show the client portal from the client's side.
• Core costs are hidden until after a long sales process.
• Consent, compliance or governance is promised as an automatic result of using software.
• Export answers focus on "you own your data" but omit formats, timing, attachments and cost.
• Features planned for later are mixed into the description of what works today.

Three final questions before signing

1. Can our team complete a real journey? Test it with realistic information and the people who will use it.
2. Do we understand every dependency? List provider onboarding, clinic governance, manual setup and additional charges.
3. Can we leave responsibly? Put export scope, assistance, retention and deletion terms in writing.

Frequently asked questions