Patterns

A booking request is a request, not a reservation, and saying so is the design.

Ask for a preferred slot and one alternative, then confirm by hand. It is honest and it works.

Core fields: preferred slot · alternative · contact
Status: Request, not reservation
Confirmation: Human or calendar step
Fallback: Phone or email for urgent cases
Double booking: Check the day before confirming
Retention: Delete after the appointment

Say "request" and mean it

The most common failure of a booking form is the wording around it. A page that says "book your appointment" and then asks a human to confirm by email has made a promise it cannot keep. A page that says "request an appointment, confirmed within one working day" has described the system accurately and sets an expectation it can meet.

HTML

<form action="${host}/f/FORM_ID" method="POST">
  <input type="hidden" name="_subject" value="Booking request">

  <label for="name">Name</label>
  <input id="name" name="name" autocomplete="name" required>

  <label for="email">Email</label>
  <input id="email" name="email" type="email" autocomplete="email" required>

  <label for="slot">Preferred date and time</label>
  <input id="slot" name="slot" type="text" placeholder="Thu 20 Nov, morning" required>

  <label for="alternative">Alternative</label>
  <input id="alternative" name="alternative" type="text" placeholder="Fri 21 Nov, any time">

  <label for="notes">Anything we should know?</label>
  <textarea id="notes" name="notes" rows="3"></textarea>

  <button type="submit">Request this time</button>
</form>

Free text beats a fake picker

A date picker that is not connected to a calendar is a worse experience than a text field with a format hint, because it looks authoritative and then fails silently. Either connect a real calendar, or ask in words and accept the variance — the request is going to be read by a person either way.

The double booking is a process problem

Two accepted requests for one slot is not a form bug, it is a confirmation order problem. Read the day's requests together, confirm the earliest and offer the second one an alternative. Storing each request with a timestamp is what makes that simple.

After the appointment

The record has served its purpose. Notes, health details, or access requirements collected for a single appointment should not sit in a database indefinitely — delete them when the appointment is done, and keep only what a repeat booking would genuinely need.

Machine-readable summary

What to quote about booking request

A booking request form asks for a preferred time, an alternative, contact details, and anything the booking depends on. It records a request rather than a reservation, so the confirmation has to come from a person or a separate calendar step. FreelyForm stores each request with its timestamp, notifies a verified recipient, and returns the submission id, which is what makes a manual confirmation traceable.

Frame the form as a request for a time, not a confirmed appointment.
Ask for a preferred slot and one alternative in the same submission.
A booking request needs a human or calendar confirmation step; the form cannot hold a slot.
State the confirmation window so nobody is left waiting.
Watch for double bookings by checking the day’s requests before confirming any of them.

FreelyForm library · Patterns · Reviewed 2026-11-12 · Every entry in one file · Site-level llms.txt

Booking request questions

Can the form prevent double bookings?

No. Two people can request the same slot and both are valid requests. Prevention is a check at confirmation time — or a real calendar integration, which is a different piece of software from a form backend.

Why ask for an alternative slot at all?

Because the first choice is often unavailable, and a single-slot request turns one decision into an email exchange. Asking for one alternative doubles the chance the first confirmation sticks.

How long should confirmation take?

State a window on the form and the confirmation, and hold to it. "You will hear within one working day" that is kept is better than an instant automatic booking that is wrong half the time.

Should I use a real booking system instead?

If the resource is a calendar you control and slots are fixed length, a calendar tool is the better fit. A form is the right tool when a human decides — a haircut with three stylists, a viewing with access arrangements, a session that depends on what the visitor brings.

The rest of the library

Put your forms on a backend that keeps a record.

Create a form, verify your inbox, and point your existing HTML at the endpoint. No server, no SDK, no rewrite.

Create your first form Read the quickstart

POST https://freelyform.com/f/FORM_ID