Request forms and booking systems are different tools
Clinics use two kinds of online booking. A booking system shows live availability and lets a patient choose a slot. A request form collects details so the clinic can call or email back and arrange the appointment. Both have a place.
A booking system suits appointments that are simple to schedule, such as a standard physiotherapy session or a routine test. A request form suits appointments that need a conversation first, such as a consultant referral, an aesthetic consultation or anything where reception needs to check suitability. Many clinics use both: online booking for some services, a request form for the rest. We build the request forms and connect your site to the booking system you already use.
What our request forms collect
The default form asks for:
- Name.
- Phone number and email address, and which the patient prefers.
- The service they are asking about, from a list.
- Preferred days and times.
- Whether they are self-paying or using insurance, if that affects how reception responds.
- A short optional message, with a note asking them not to include details of their health.
It does not ask for date of birth, symptoms, medication, medical history or NHS number. Reception rarely needs those to make a first call, and leaving them out keeps sensitive data out of inboxes and form logs.
Why less data is safer
A website form adds a new route for patient data, often through email and plugins that were never part of the clinic's data protection planning. Keeping health details out of the form avoids most of that risk. Where a clinic does need clinical information before an appointment, such as a pre-assessment questionnaire, we point it to the clinic's practice management system or a dedicated secure portal instead. The legal background, including how UK GDPR treats health information, is in our guide on health data and online forms.
How the forms are built
- Security. Submissions are sent over HTTPS, protected against cross-site request forgery, and filtered for spam with a hidden field and timing checks rather than puzzles that block real people.
- Delivery. Messages are sent to a mailbox your clinic controls, using authenticated sending so they arrive reliably.
- Limits. Repeated submissions from the same source are slowed down so a script cannot flood your inbox.
- Accessibility. Every field has a visible label, errors are listed in words at the top of the form, and the form works with a keyboard and screen reader, in line with WCAG 2.2[1].
- Clear confirmation. After sending, the patient sees what happens next and when the clinic will respond.
The privacy notice has to match the form
People have the right to be told what is done with their data at the point it is collected[2]. We write the privacy notice section for the form at the same time as the form, so the two always match: what is collected, why, where it goes, how long it is kept and who to contact. If you later add a field, the checklist we hand over includes updating that section.
Connecting to your existing systems
If your clinic uses a practice management or booking platform, we can link the form or the booking pages to it. We will not copy submissions into extra spreadsheets or marketing tools unless you ask, and if you do, we list those tools in the privacy notice. Recall emails and newsletters are a separate matter with their own consent rules, so a request form does not sign anyone up to marketing.
Spam protection without puzzles
Image puzzles and "click all the traffic lights" tests stop some bots, but they also stop real people, especially those using screen readers, magnification or a phone with shaky hands. Our forms rely on checks the patient never sees: a hidden field that only automated scripts fill in, a signed time stamp that rejects forms submitted faster than a person could type, a token that ties each submission to a real visit, and limits on how many messages one connection can send in an hour and a day. Together they keep the inbox clean without putting a test between a patient and an appointment.
What reception receives
Each request arrives as a plain email with a consistent subject line, so it can be filtered into the right folder. The reply-to address is the patient's, so reception can answer with one click. The email contains only what the form collected. We agree with you who receives requests, how quickly someone should respond, and what the patient is told on the confirmation screen, so the promise on the website matches what happens in practice.
Testing before launch
Before the site goes live, we send test requests for every service and location, check they reach the right inbox, check the confirmation screen, and check that error messages appear in words when a field is missing. After launch, we repeat the test on the live site, because mail settings that work on a staging server do not always work on the live domain.
Questions clinics ask
Can patients upload referral letters through the form?
We advise against file uploads on a general website form, because referral letters usually contain health information. A secure portal or your practice management system is the better route, and reception can explain how to use it on the first call.
Do we need a cookie banner for the form?
The form uses one strictly necessary cookie to protect against forged submissions, which does not need consent. Analytics and marketing tools are a separate question, covered in our cookies guidance.
Can the form go to different people depending on the service chosen?
Yes. Requests for different services or sites can be routed to different inboxes, which is common for groups with several locations.
Sources
Checked on 29 October 2026.
- W3C: Web Content Accessibility Guidelines (WCAG) 2.2 (standard)
- Information Commissioner's Office: The right to be informed (regulator)
