booking-path

---
name: booking-path
description: Counts every screen, tap and question between a stranger finding you and being booked, marks which of those steps exist for the customer and which exist for you, and returns the shortened path with the exact fields to delete, the questions to move, the error wording to fix and the payment wording the law requires on any deposit button. Use when the site gets visitors and the diary stays empty, before you change booking platform, or when you have never once booked your own table on a phone.
---

# Count the taps between finding you and being booked, then delete half of them

You give this the live booking route on your own site, a screen recording of yourself completing a real booking on a phone, and the list of fields your booking system asks for. You get back every screen and every question numbered in order, each one marked as needed by the customer, needed by you or needed by nobody, the shortened path with the deletions named field by field, the error messages rewritten, and the wording the law requires wherever money changes hands. It does not build you a booking system, it does not choose a platform, and it will not delete a field you are legally or operationally required to collect.

## What it does

1. **Walk the path yourself, as a stranger, on a phone, and count.** Start where a real person starts, from a search result or a link on social media, not from the booking page you have bookmarked. Record the screen. Then count three things separately: screens loaded, taps made, and questions answered. Write each one down in order with what it asked and what you typed. Most owners believe their booking is three steps and discover it is eleven, because the count includes the cookie banner, the menu that has to be opened to find the booking link, the platform's own landing page, the date picker that opens on the wrong month, and the account that has to be created before a table can be held.

2. **Mark every step as needed by the customer, needed by you, or needed by nobody.** A date is needed by the customer. A dietary requirement is needed by you, at the point you are cooking, not at the point they are deciding. A marketing consent tickbox is needed by nobody at that moment. The GOV.UK Service Manual calls the discipline a question protocol and sets the test: only add a question if you know "that you need the information to deliver the service", "why you need the information", "what you'll do with it", "which users need to give you the information" and "how you'll check the information is accurate". Run every field through those five. A field that fails any of them is a candidate for deletion, not for a shorter label.

3. **Reorder what survives so the disqualifying questions come first.** The Service Manual is explicit: "Start with questions that will let users know if they're not eligible for the service, so you do not waste people's time." For a venue that means date, time and party size before anything else, because they are the questions that can end the conversation. Asking for a name, an email address and a phone number and then revealing there is no table at seven is the single most annoying thing a booking form does, and it is the version most platforms ship with. If a party of twelve needs a different process, say so before the form starts, not in an email two days later.

4. **Split what is left across pages so each page asks one thing.** The Service Manual's default is to start "by splitting the form across multiple pages with each page containing just one thing", and it lists what that buys: it helps people "focus on the specific question and its answer", "use the service on a mobile device" and "recover easily from form errors". On a phone this is not a preference. A single long form on a small screen puts the error at the top, the field at the bottom and the keyboard over both. Merge pages back together only where you have watched real people use it and seen them want it merged.

5. **Never ask for the same thing twice, and never make anyone retype what you already hold.** The GOV.UK Design System says to "make sure to only ask for a piece of information once within a single journey. Whenever possible, do not ask a user to re-enter information they've already provided", and where the same information is genuinely needed again, to make it reusable by "pre-populating the relevant fields" or "showing carried-forward responses as an option for the user to select". This is also an accessibility requirement rather than a nicety. WCAG 2.2 success criterion 3.3.7 Redundant Entry, Level A, requires that information previously entered "that is required to be entered again in the same process is either: auto-populated, or available for the user to select".

6. **Fix the fields themselves, which is where most of the abandoned bookings actually happen.** Nielsen Norman Group's form guidance is blunt about the basics: "Keep it short", "Present fields in a single column layout", "Labels should be close to the fields they describe", "Avoid placeholder text", "Match fields to the type and size of the input", "Explain any input or formatting requirements", and "Avoid Reset and Clear buttons". Two of those matter more than the rest on a booking form. Placeholder text inside a box disappears the moment someone types, so half your guests will not remember what the box wanted. And a phone number field that rejects spaces without saying so is a booking you never received and never knew about.

7. **Make everything you expect a thumb to hit big enough for a thumb.** WCAG 2.2 success criterion 2.5.8 Target Size (Minimum), Level AA, requires that "the size of the target for pointer inputs is at least 24 by 24 CSS pixels", with an exception where undersized targets are spaced so that a 24 pixel circle centred on each does not touch another. Date pickers are the usual offender: thirty-one numbers crammed into a grid, with yesterday next to today next to tomorrow, and a mis-tap that silently books the wrong night. Label the optional fields as optional rather than starring the required ones, because the Design System is explicit that you should "never mark mandatory fields with asterisks".

8. **Rewrite every error message, and stop the form throwing away what was typed.** The GOV.UK Design System sets the standard: "In the error message explain what went wrong and how to fix it", put the message "in red after the question text and hint text", and "do not clear any form fields when showing the Error message component. Keep both passing and failing answers", because keeping them helps users "see what went wrong", "edit their previous answer" and "avoid re-entering information". It also names the wrong use: "Do not use error messages to tell a user that they are not eligible or do not have permission to do something", which is what a booking form does when it says "invalid" because the restaurant is full.

9. **Where money is taken, put the legally required words on the button, then count the path again.** Regulation 14 of the Consumer Contracts (Information, Cancellation and Additional Charges) Regulations 2013 applies to distance contracts concluded by electronic means. It requires that "the trader must ensure that the consumer, when placing the order, explicitly acknowledges that the order implies an obligation to pay", and that where placing an order means pressing a button, that button must be "labelled in an easily legible manner only with the words 'order with obligation to pay' or a corresponding unambiguous formulation". The consequence of getting it wrong is in regulation 14(5): "the consumer is not bound by the contract or order". Then rerun step 1 and record the new count beside the old one.

## Then it checks

1. The count in step 1 came from a recorded walkthrough on a named phone handset from a cold start, with screens, taps and questions counted separately, and the same walkthrough was repeated after the changes with both counts recorded.
2. Every question on the path carries a verdict of customer, business or nobody, and every question kept answers all five of the question protocol tests in writing.
3. The disqualifying questions of date, time and party size appear before any question that collects a name or contact detail, or the reason they do not is stated.
4. No piece of information is asked for twice on the path, and where it genuinely must be, the row records whether it is pre-populated or offered as a selection.
5. Every error message on the path says what went wrong and how to fix it, no error message tells the customer they are ineligible, and the form is confirmed to retain entered values after an error.
6. Where any payment, deposit or card guarantee is taken, the exact label on the paying button is recorded verbatim and checked against regulation 14(4), and the total amount, what it is for and whether it is refundable are all present before that button.

Any check fails: name it, redo that step once. Failed twice: say what is wrong and stop.

## Rules
- Public information only.
- Never invent a fact, a number or a quote.
- Anything sent in someone's name says whose name it is.
- Never state an abandonment rate, a conversion rate or a benchmark for this venue. No published figure exists for a single independent UK hospitality business, the figures that circulate are published by companies selling booking software, and an owner who compares their diary against a borrowed number will change a system that was working.
- Never delete a field because it is annoying. A field goes only when it has failed the question protocol in writing, and allergen, accessibility, age verification and payment fields are never removed by this skill under any circumstances.
- Never write the words on a payment button yourself. Regulation 14(4) permits "order with obligation to pay" or a corresponding unambiguous formulation, and which formulation a particular venue uses is a question for its solicitor, so the skill records the current wording, flags it if it does not acknowledge an obligation to pay, and stops.
- Never count a booking path from a desktop browser. The path being audited is the one on a phone, held in one hand, with a keyboard covering the bottom half of the screen, and every count taken any other way is a different number about a different thing.
- Never test the path while logged in to your own booking system. A logged-in owner skips the account creation, the confirmation and the wait, which is exactly the part where customers stop.
- This output is a working document prepared for the owner to check against their own booking system, their deposit terms and their cancellation policy before anything is changed, and for their solicitor to check the payment wording, the cancellation terms and the consent wording. It applies published guidance and published regulations to a path as it stands. It is not legal advice and it is not a ruling that the booking process complies.

## Built from
- GOV.UK Service Manual, "Structuring forms", https://www.gov.uk/service-manual/design/form-structure, published 7 December 2016, last updated 7 August 2018, read 16 September 2026: the five-part question protocol in step 2, the eligibility-questions-first ordering in step 3, and the one thing per page default in step 4.
- GOV.UK Design System, "Question pages", https://design-system.service.gov.uk/patterns/question-pages/, no publication date shown on the page, read 16 September 2026: the ask-once rule and the two named reuse methods in step 5, and the prohibition on asterisks for mandatory fields in step 7.
- GOV.UK Design System, "Error message", https://design-system.service.gov.uk/components/error-message/, no publication date shown on the page, read 16 September 2026: the wording standard, the instruction not to clear fields and the named wrong use, which is the whole of step 8.
- Kathryn Whitenton, Nielsen Norman Group, "Website Forms Usability: Top 10 Recommendations", https://www.nngroup.com/articles/web-form-design/, published 1 May 2016, read 16 September 2026: the field-level rules in step 6, including the single column layout, the placeholder text warning and the instruction to avoid Reset and Clear buttons.
- World Wide Web Consortium, "Web Content Accessibility Guidelines (WCAG) 2.2", W3C Recommendation 12 December 2024, https://www.w3.org/TR/WCAG22/, read 16 September 2026: success criterion 3.3.7 Redundant Entry in step 5 and success criterion 2.5.8 Target Size (Minimum) in step 7.
- The Consumer Contracts (Information, Cancellation and Additional Charges) Regulations 2013, SI 2013/3134, regulation 14, https://www.legislation.gov.uk/uksi/2013/3134/regulation/14/made, read 16 September 2026: the explicit acknowledgement requirement, the button labelling requirement and the unenforceability consequence, in step 9.

# booking-path

## You are given
A screen recording, or an ordered set of timestamped screenshots, of one complete booking made on a named phone handset from a cold start, beginning at a search result or social link and ending at the confirmation screen, with the date and handset recorded, plus a second recording taken after changes where one exists. A numbered transcript of the journey already written by Claude: every screen loaded, every tap made and every question asked, in order, with the exact on-screen wording of each question, hint and button. Claude's verdict for each question, one of customer, business or nobody, with the five question protocol answers written out for every question kept, and Claude's verdict on ordering, duplicated questions and target sizes. The exact text of every error message encountered, and whether the form retained the entered values after each error. The exact label of any button that takes a payment, deposit or card guarantee, with the amount, what it covers and the refund terms as displayed. The fields the booking system requires, marked by the owner as legally or operationally mandatory where they are.

## Produce
Write into a `./booking-path-output/` folder:

1. `journey-steps.csv` with these columns in this order: `step_no`, `screen_ref`, `step_type`, `on_screen_text_verbatim`, `taps_required`, `is_new_screen`, `belongs_to`, `owner_of_step`, `removable`. `step_no` is 1 upward in the order they occurred. `step_type` is exactly one of `navigation`, `consent banner`, `question`, `selection`, `confirmation`, `payment`, `account creation`, `wait or load`, `error`. `belongs_to` is exactly one of `own site` or `booking platform`. `owner_of_step` is exactly one of `customer`, `business`, `nobody`, `no verdict supplied`. `removable` is `yes`, `no` or `mandatory - do not remove`.
2. `question-protocol.csv` with columns: `question_ref`, `question_text_verbatim`, `field_type`, `needed_to_deliver_service`, `why_needed`, `what_is_done_with_it`, `which_users_must_answer`, `how_accuracy_is_checked`, `passes_all_five`, `verdict`. `question_ref` is Q001 upward. `field_type` is exactly one of `date`, `time`, `party size`, `name`, `email`, `phone`, `allergen or dietary`, `accessibility need`, `age`, `marketing consent`, `payment detail`, `free text`, `other`. `passes_all_five` is `yes` or `no`, and any question with `verdict` of `keep` and `passes_all_five` of `no` is listed in `gaps.md`.
3. `ordering-and-duplication.csv` with columns: `question_ref`, `position_in_journey`, `is_disqualifying_question`, `asked_before_contact_details`, `asked_more_than_once`, `first_position`, `repeat_positions`, `reuse_method`. `reuse_method` is exactly one of `auto-populated`, `offered as selection`, `neither`, `not applicable`. Every row with `asked_more_than_once` of `yes` and `reuse_method` of `neither` cites WCAG 2.2 success criterion 3.3.7 in the row.
4. `field-mechanics.csv` with columns: `question_ref`, `label_present`, `label_position`, `uses_placeholder_as_label`, `single_column`, `optional_marked_as_optional`, `asterisk_used`, `input_format_explained`, `reset_or_clear_button_present`, `target_width_css_px`, `target_height_css_px`, `meets_24_by_24`. `label_position` is exactly one of `above`, `beside`, `inside the field`, `none`. `meets_24_by_24` is `yes`, `no` or `not measured`, and measurements are read from the supplied evidence, never estimated.
5. `error-messages.csv` with columns: `error_ref`, `question_ref`, `trigger_that_caused_it`, `message_text_verbatim`, `says_what_went_wrong`, `says_how_to_fix_it`, `tells_user_they_are_ineligible`, `fields_cleared_after_error`, `replacement_wording_supplied`. Replacement wording is copied verbatim from the input and is never written by Codex.
6. `payment-wording.csv` with columns: `button_label_verbatim`, `amount_displayed`, `what_the_amount_covers_verbatim`, `refundable_terms_verbatim`, `acknowledges_obligation_to_pay`, `total_shown_before_button`, `payment_methods_stated`, `regulation_cited`. `acknowledges_obligation_to_pay` is `yes`, `no` or `no payment taken on this path`. Written as a single row, or as one row per paying button where there is more than one.
7. `before-and-after.csv` with columns: `measure`, `before`, `after`, `difference`. Rows: `screens loaded`, `taps to confirmation`, `questions asked`, `questions asked twice`, `fields below 24 by 24`, `errors encountered`. `after` is left empty where no second recording was supplied.
8. `gaps.md` - a numbered list of: any step with no verdict; any question kept that fails the question protocol; any contact detail collected before date, time or party size; any repeated question with no reuse method; any error message that clears the form; any error message that reports ineligibility; any paying button that does not acknowledge an obligation to pay; any field flagged mandatory by the owner that appears marked removable; and whether an after recording exists.

## Rules
- Codex measures, records and counts. It never invents, never rewords the owner's copy, and never makes the judgement that was supplied to it. Whether a question is needed, what should be deleted and what an error message should say are all decisions that arrive with the input.
- Never write a new question, a new label, a new hint or a new error message. Where replacement wording is missing, the cell is left empty and the fact is listed in `gaps.md`.
- Never write the words for a payment button. Record the existing label verbatim, mark whether it acknowledges an obligation to pay, cite regulation 14(4) of the Consumer Contracts (Information, Cancellation and Additional Charges) Regulations 2013, and stop there.
- Never mark a field removable where the owner has flagged it mandatory, and never mark an allergen, dietary, accessibility, age verification or payment field removable under any circumstances, whatever the verdict supplied.
- Never write an abandonment rate, a conversion rate, a drop-off percentage, an industry average or any benchmark figure into any file. No such figure exists for a single independent UK venue and none is to be recorded.
- Counts are counted from the supplied recording, never estimated, and the count is taken from the cold start including consent banners, menus that must be opened, platform landing pages and account creation screens. Nothing on the path is excluded because it belongs to a third party platform.
- Pixel measurements are recorded only where the evidence supports them. Where it does not, `meets_24_by_24` is `not measured` and the row is listed in `gaps.md` rather than guessed.
- Every quoted string is copied exactly, including punctuation, capitalisation, currency symbols and any emoji.
- Use British English, GBP and DD Month YYYY dates. No em dashes in any file you write, and any supplied text containing one is recorded verbatim and flagged in `gaps.md`.
- Every file ends with this line: this is a working document prepared for the owner to check against their own booking system, deposit terms and cancellation policy, and for their solicitor to check the payment, cancellation and consent wording. It applies supplied guidance to a path as it stands and is not a ruling that the process complies.

## Return
The absolute path of each file written and the row count of each CSV. The handset, date and start point of each recording. The before count and, where a second recording exists, the after count of screens, taps and questions, with the difference. How many questions carry each verdict of customer, business and nobody, and how many kept questions fail the question protocol. Whether any contact detail is collected before date, time and party size, and at which step. Every question asked more than once with no reuse method. Every field measured below 24 by 24 CSS pixels, and every field that could not be measured. Every error message that clears the form or reports ineligibility. The paying button label exactly as recorded and whether it acknowledges an obligation to pay. And the `gaps.md` item count.