The gap between a brochure and a service
Most pharmacy websites describe services accurately and offer no way to start one. The page explains what a travel clinic does, who it suits and what it involves, and then ends with a telephone number and an invitation to get in touch.
The patient who reads that page has already done the difficult part. They have found the service, understood it and decided to proceed. What happens next determines whether the pharmacy ever hears from them, and a telephone number asks them to convert an intention into a phone call at a time when the pharmacy is open and they are free to make it. A substantial proportion of that intention evaporates in the gap.
Closing it means the website can take the booking and run the clinical assessment, so that a decision made whilst reading becomes an appointment before the reader has moved on. That is the whole subject of this article, and everything else in it follows from one principle, which is that every additional step, page or system between the decision and the booking costs patients.
Three ways to put booking on a website
| Approach | What it is | Trade-off |
|---|---|---|
| Embedded | The booking and assessment run inside your own pages, under your domain and design | Retains the most patients and the most control, requires the embed to be placed properly |
| Hosted link | A button sends the patient to a separate booking page | Quickest to deploy, loses the most people at the handoff, weakest brand continuity |
| Custom integration | Your developers build against an API | Complete control, requires development capability and ongoing maintenance |
For most pharmacies the embedded route is correct, because it gives close to the control of a custom build without the maintenance burden, and because the hosted link's convenience is paid for in exactly the currency the exercise exists to protect.
Why sending patients to a portal loses them
A patient about to enter health information into a website is making a judgement about whether the business is genuine, and that judgement is made largely on signals they cannot articulate. The domain matches the pharmacy they were reading about. The design is continuous. The name in the browser is the name above the door. Sending them to a third-party portal breaks all three at the precise moment they are deciding whether to disclose a medical history, and the effect is worse in pharmacy than in most sectors because the sector's own public problem is that patients cannot tell genuine services from convincing ones. A person who has read your careful page about who your prescriber is, then finds themselves on an unfamiliar domain with different styling, has been given a reason to hesitate that you created. The technical fix is straightforward and the reasoning is not primarily technical. Keep the patient on your domain, in your design, with your name visible, through the whole assessment, because the flow is a trust surface before it is a conversion funnel.
What to decide before you embed anything
Five decisions, all of which are cheaper before the integration than after.
Which services go online. Not everything should. A service requiring in-person assessment belongs as an enquiry rather than a booking, and putting it behind a booking button implies something the service cannot deliver.
The order of the flow. Assessment before payment for anything prescription-only, per the section below. This is an architecture decision and is expensive to reverse.
What you ask, and when. The argument for capturing clinical information at booking rather than at the appointment is set out in the patient data capture guide, and it applies directly here, since the embed is where those questions are asked.
Where the record lands. If the booking tool and the clinical record are different systems, somebody will be reconciling them by hand. Decide deliberately rather than discovering it in month two.
Who handles what happens next. A booking generates work, comprising the assessment to review, the patient to contact, the exception to resolve. An embed which produces bookings nobody has capacity to process is a worse outcome than a telephone number.
How compliance shapes the integration
These requirements are not additions to the build, they determine its shape, which is the point the agency brief makes at length.
Transparency about who provides the service. The inspection framework published in January 2026 expects prescribing service websites to state who provides them, including the prescriber's name, the address of the prescribing service, and whether the prescriber is a doctor or a non-medical prescriber. That is page content adjacent to the embed rather than something inside it, and it must not be lost when a template changes.
No prescription-only promotion. The service page around the embed sells the consultation and the care, not the medicine, which constrains the copy more than most agencies expect.
Health data handled properly. Answers submitted through the embed are special category data and must reach a controlled record rather than an inbox, with no analytics or marketing scripts on pages whose URL reveals a condition, per the security baseline.
Accessible completion. The flow must be operable by keyboard, tolerate enlarged text and preserve answers across interruption, which for a long assessment is not a refinement, as the accessibility article sets out.
Shopify, WordPress and custom sites
The platform matters less than owners expect, and it matters in specific ways.
Shopify is the most common platform for UK pharmacy sites and handles embedded flows well. The two things to get right are where the embed sits within the theme, since a booking buried below the fold on a long page performs poorly, and how the native checkout is used, because Shopify's checkout is built for retail order-then-pay and a prescription service needs assess-then-pay.
WordPress and WooCommerce accommodate embeds straightforwardly, with the recurring risk being plugin sprawl, since every additional plugin touching the page is another party in the data flow and another update which can break the embed.
Custom and headless sites give the most control and place the maintenance obligation on whoever built them, which should be established contractually rather than assumed.
Across all three, the durable rule is that the embed should survive a redesign. A pharmacy which rebuilds its site every few years should not be rebuilding its clinical flow each time, and that is a question about how the integration is structured rather than about the platform.
Where payment sits in the flow
For prescription-only services, after the prescriber's decision. This is the single most consequential ordering decision on a pharmacy website and it is the one most commonly got wrong, because retail instinct says take the money when the customer is willing.
Three reasons it must be the other way. Regulators, certifiers and payment underwriters all treat payment-before-assessment as the primary indicator of a service which is selling rather than prescribing. A patient who pays and is then declined generates a refund and frequently a dispute, which is the exposure the consumer law guide describes. And a flow which has already taken payment applies a quiet pressure toward approval which the whole assessment exists to resist.
Where a service charges separately for the consultation itself, that fee can properly be taken at booking, provided the terms make clear what is being paid for and what happens if treatment is not appropriate. Card details should be captured by the payment provider rather than reaching the pharmacy's own servers, per the payments criteria.
What to test before going live
Eight checks, and the last two are the ones usually skipped.
Complete a booking end to end as a patient on a phone, since most will. Complete one using only the keyboard. Confirm the answers arrive on the clinical record rather than in an email. Confirm a declined patient sees the decline experience you designed rather than an error. Confirm the transparency information is present on the page and survives a theme update. Confirm no analytics or marketing scripts are firing on condition-specific pages. Confirm what happens when the embed fails to load, since the patient should see a route to contact you rather than a blank space. And confirm somebody is watching the resulting queue on day one, because the failure mode of a successful launch is bookings arriving faster than anyone expected.
What to measure afterwards
Stage by stage rather than in aggregate, because an overall conversion figure tells you there is a problem and never where.
Measure page view to booking started, booking started to assessment completed, assessment completed to decision, and decision to payment. The largest single drop is the thing to fix, and it is usually a specific defect rather than general reluctance, comprising a question people abandon at, an upload which fails on mobile, or a step which asks for something they do not have to hand.
Two figures belong on the weekly page described in the reporting guide rather than in a marketing report. Conversion by stage, because it moves for operational reasons. And refusal rate, because a booking flow which is converting better whilst refusing less is not improving.
Key takeaways
- A website which describes services but cannot start one loses patients who have already done the difficult part, and every step between decision and booking costs conversions.
- Three routes exist, comprising embedded, hosted link and custom integration, and embedded is correct for most pharmacies because the hosted link's convenience is paid for in patients.
- The handoff to a third-party portal breaks domain, design and name continuity at the moment a patient is deciding whether to disclose a medical history, which matters more in pharmacy than elsewhere.
- Decide which services go online, the order of the flow, what you ask and when, where the record lands and who processes the result, all before embedding anything.
- Compliance shapes the integration rather than following it, covering prescriber transparency, no POM promotion, health data reaching a controlled record, and accessible completion.
- Payment follows the prescriber's decision for prescription-only services, since payment-first is the primary indicator regulators, certifiers and underwriters all look for.
- Test on a phone and by keyboard, confirm what happens when the embed fails, and make sure somebody is watching the queue on day one.
FAQs
From your website, in one flow.
Send us your service page and we will show the booking and assessment embedded in it. See it working, then bring us your own case and we will run a patient journey end to end on your own site, on a phone, in the correct order.
See pharmacy websites