What can you configure in the Bookings module?
The Bookings module is configured across four layers: services, availability, patient communications and payments. Services define what patients can book, with duration, price and category per offering. Availability defines when, set per service and location, and it is the configuration patients actually experience, because the slots on your website are generated from it. Communications run automatically once configured: booking confirmations go out on booking and reminders ahead of the appointment, which is what drives no-shows down. And payment is part of the booking flow itself, with patients choosing a service, picking a time and paying upfront in one journey, supported across multiple payment providers.
| Layer | What it defines | Where it is set | Why it matters |
|---|---|---|---|
| Services | What patients can book: name, category, duration, price | Services section, per offering | Shapes everything downstream, from calendar slots to checkout |
| Availability | When each service is bookable | Per service and per location | Generates the slots patients see on your website |
| Communications | Confirmations on booking, reminders ahead of appointments | Configured once, runs automatically | The proven mechanism that drives no-shows down |
| Payments | Upfront payment inside the booking journey | In the booking flow, multiple providers supported | Diary and takings reconcile by design; paid patients attend |
Everything sits on the foundations from initial setup: locations and team. Each pharmacy, clinic or virtual consultation room exists as a location with its own services, staff and calendar, and the module presents all of them in one calendar view, so a multi-site operation manages its whole diary from a single screen. If you have not yet added locations and users, start with our getting started guide and return here for the service layer.
Creating a service: duration, price, category and location
A service is created in the Services section with the four decisions that shape everything downstream: what it is, how long it takes, what it costs and where it runs. The name and category determine how the service is presented and grouped, both in your dashboard and on your website, so categories are worth planning before you create ten services with inconsistent labels. Duration determines the slots the calendar generates, and it should be the honest clinical time including the record keeping, not the optimistic consultation-only figure, because a diary built on optimistic durations runs late by mid-morning and late diaries create the cancellations the module exists to prevent.
Price is set per service and is what the patient pays in the booking flow, so it must match what your website advertises to the penny; a mismatch between a service page and the checkout is the fastest way to lose a booking at the final step. Location assignment decides where the service is offered, and one service can run at a single branch, at several, or in a virtual consultation room for remote delivery, with video calling built into the platform so a remote consultation happens inside the booking rather than on a separate tool.
Setting availability: what patients actually see
Availability is set per service and location, and it is worth treating as the module's most important configuration, because it is the only part of your setup every patient interacts with. The calendar you configure generates the bookable slots shown on your website, so the working pattern you set is a public promise: if Tuesday afternoons are open in the configuration, patients will book Tuesday afternoons, and the pharmacist who is actually at the wholesaler on Tuesday afternoons becomes a rescheduling problem of your own making.
"The working pattern you set is a public promise: if Tuesday afternoons are open in the configuration, patients will book Tuesday afternoons."
The practical discipline is to configure availability from the real week, not the ideal one. Map when the consultation room genuinely has both a free clinician and a free space, leave the difficult slots closed until the service has bedded in, and expand availability as demand proves itself rather than opening the whole week on day one. For multi-location operations, remember each location carries its own availability for each service, so a service launched at a second branch needs its calendar configured there deliberately; it does not inherit the first branch's hours.
Confirmations, reminders and patient self-service
Once configured, patient communications run without staff involvement: bookings are confirmed automatically at the moment of booking, and reminders go out ahead of appointments. This is the feature with the most direct revenue effect in the module, because no-shows are the silent tax on a private service, an empty slot that was paid for in staff time, and automated reminders are the proven mechanism that reduces them. Configure them and leave them on; the pharmacies that turn communications off to reduce message volume are economising on the exact feature that protects their diary.
Self-service handles the other half of diary churn. Patients can reschedule or cancel their own bookings without phoning the pharmacy, which converts what would have been a silent no-show into a freed slot another patient can take, and removes the phone-tag workload from your team. The combination, automatic reminders plus self-service rescheduling, is what makes a private diary run without a member of staff administering it.
Payments in the booking flow
Payment is taken upfront as part of the booking journey: the patient picks the service, chooses the time and pays in one flow, with multiple payment providers supported. Upfront payment does two jobs for a private service. Commercially, it converts a booking into revenue at the moment of intent rather than at the counter, and a patient who has paid attends at a far higher rate than one who has merely booked. Operationally, it means the diary and the takings reconcile by design, because every appointment in the calendar carries its payment with it rather than depending on someone remembering to charge on the day.
The configuration discipline here is consistency: the price in the service configuration, the price on your website's service page and the amount taken at checkout are the same number from the same source, which is exactly what the integration provides when booking runs natively on your site rather than being retyped into a separate tool.
Around the booking: assessments, notes and documents
A booking in Dataforge PMR is not just a diary entry; it is the front end of a clinical record. Where a service requires clinical information, the patient completes a clinical assessment capturing patient data and structured information gathering, and the responses sit on the case alongside the booking. During and after the consultation, clinicians add free-type notes to the record, and documents can be uploaded against the patient, so referral letters, identity evidence or prior results live with the case rather than in an inbox. Where the consultation leads to treatment, prescription generation and drug label generation follow in the same system, which is the journey the getting started guide walks end to end.
For configuration purposes, the point is sequencing: decide per service whether an assessment is part of the journey, and build that in before launch rather than after the first patient arrives with no information attached. The detail of how assessments and clinical flags work belongs to the Clinical Decision module and is covered in its own wiki article.
Putting booking on your website
The Bookings module is built to run on your own website rather than on a separate booking page: Dataforge PMR connects to any site, with native Shopify support out of the box and integrations for WooCommerce and custom builds. Patients move from your service page into slot selection and payment without leaving your domain, which matters for conversion, every redirect loses a percentage, and for trust, since a patient booking a clinical service should never wonder whose website they have landed on.
- Configure one service completely: availability, price, reminders, and the assessment if the service needs one.
- Place it on the website, running natively on your own pages rather than a separate booking tool.
- Run test bookings end to end yourself, including a reschedule and a cancellation, before pointing patients at it.
Shopify-specific embedding, including assessments in the storefront journey, has its own wiki guide.
Common configuration mistakes
Five mistakes account for most Bookings support conversations, and all five are avoidable in setup. Optimistic durations: services configured at consultation time only, with no room for records, running the diary late and stacking pressure on the team. Aspirational availability: the whole week opened on day one, then repeatedly blocked out, teaching patients that slots at this pharmacy get cancelled. Price mismatches between the website and the service configuration, which end bookings at the payment step. Reminders left unconfigured, which quietly raises no-shows and gets blamed on the patients. And launching ten rough services instead of one complete one, so every service has a gap and none has a clean end-to-end journey.
The module rewards configuring the service you actually run, at the pace you actually run it. Start narrow, complete and honest, then expand.
Key takeaways
- The Bookings module is configured in four layers: services, availability per service and location, automated communications and in-flow payment.
- Duration should be the honest clinical time including records, because the calendar generates slots from it and optimistic durations run the diary late.
- Availability is a public promise: configure the real week, keep difficult slots closed until demand proves itself, and remember each location carries its own calendar.
- Automated confirmations and reminders plus patient self-service rescheduling are what let a private diary run without staff administering it.
- Patients pay upfront in the booking flow across multiple supported payment providers, so the diary and takings reconcile by design.
- Where a service needs clinical information, attach the assessment before launch; notes, document upload, prescriptions and labels follow on the same record.
- Launch one service configured completely and tested end to end, then expand, rather than ten services configured roughly.
FAQs
Your first service, built live.
If you want your first service configured with us rather than from documentation, book a 30-minute demo and we will build it live against your real diary, prices and locations.
Book a demo