Does a private-hire operator website need an enquiry form, booking request or online booking?

Why is the booking journey the main website-buying decision?

A private-hire website is not just a brochure with a phone number. Under the Local Government (Miscellaneous Provisions) Act 1976, operating includes making provision in the course of business for inviting or accepting private-hire bookings. GOV.UK also states the customer distinction plainly: a private-hire vehicle must be pre-booked, while a taxi can also be hired at a rank or hailed in the street. The website is therefore part of the operator's real booking process, even when a dispatcher confirms each request by phone.

That makes the wrong feature costly. A generic contact form can leave dispatchers chasing the pickup time and destination. A button saying 'Book now' can make a passenger think a car is coming when the operator has only received an email. A full booking engine can be needless overhead if staff still re-enter every job into another system. Start with the acceptance and dispatch workflow, then choose the website around it.

Should the website use an enquiry, a booking request or instant confirmation?

• Enquiry or quote form: best for account travel, events, school or care contracts, executive work and journeys that need a tailored price or suitability check. Ask enough to assess the work, but do not present the response as a reserved vehicle.
• Booking request: often the cleanest route for a small fleet. The passenger supplies the journey details, then a person or dispatch system checks availability and sends an explicit acceptance or rejection.
• Instant confirmed booking: appropriate only when the website can obtain real availability, calculate the intended price, take any required payment and write the accepted job into the operator's working booking or dispatch system.
• Phone booking: still important for urgent journeys, people who cannot use the form, accessibility questions and edge cases. Publish the real staffed hours and say what happens out of hours.

When does the operator become responsible for the booking?

Section 56 of the 1976 Act says the hire contract is deemed to be made with the operator that accepted the booking, whether or not that operator ultimately provides the vehicle. The same section requires the licensed operator to keep records in the form prescribed by its council and to enter the council-prescribed particulars for every booking invited or accepted before the journey begins.

There is no safe nationwide field list to copy into every website. The Department for Transport recommends a minimum booking record for English licensing authorities, including passenger, request time, pickup, destination, driver, vehicle and the people responding to and dispatching the booking. It suggests retaining records for at least six months. But those are recommendations; the binding format, fields and retention rules come from the operator's own licensing authority and licence conditions. Welsh Government model conditions also contain detailed booking fields and six-month retention, but local authorities decide what they adopt.

Which fields belong in a useful booking request?

The form should help the operator decide availability, vehicle suitability and price without turning the first screen into a dispatch database. Mark what is required, explain unusual fields, and reveal specialist questions only when the journey needs them.

• Passenger or booker name, mobile number and an email address when confirmations are sent by email.
• Requested pickup date and time, pickup address or named place, destination, and whether the time is fixed or flexible.
• Number of passengers plus luggage or equipment details only where they affect the vehicle required.
• A functional prompt for every passenger: 'Do you need any assistance for this journey?' followed by the practical detail the operator needs.
• Journey type, such as one-way, return, airport transfer, regular booking or account enquiry.
• Flight number and planned landing time for an airport pickup, plus a clear explanation of meet-and-greet, flight monitoring, waiting time, parking and terminal arrangements.
• Payment or account method only when it changes how the booking is handled; never collect full card data through an ordinary contact form.
• An optional note for access, pickup landmarks or other operational detail, with a warning not to include unnecessary sensitive information.

How should airport, local and account journeys differ?

One long form makes every passenger answer irrelevant questions. Use short routes that match the work. An airport transfer needs terminal, flight, luggage, pickup-sign and waiting information. A local journey needs the requested time, addresses, passenger count and any vehicle or assistance needs. An account or contract enquiry needs the organisation, travel pattern, invoicing needs and a conversation - not a pretend instant fare for work that has not been scoped.

Price copy should be equally specific. Say whether the figure is a fixed quote, an estimate or subject to confirmation, and explain the charges that actually apply: parking, tolls, waiting, extra stops, cancellation, no-show or a change of vehicle. Do not hide operational rules in a PDF that the passenger sees only after requesting the journey.

What must the website do for disabled passengers?

Department for Transport guidance on disabled passengers recommends asking every passenger at booking whether assistance is required and what help is needed. It specifically says booking websites and apps should collect the information, with examples such as help locating the vehicle or remaining in a wheelchair. Ask about the function, not a diagnosis: 'Do you need step-free access, space to remain in a wheelchair, help locating the vehicle or another adjustment?'

England's licensing best-practice guidance recommends that authorities require digital booking platforms to meet WCAG 2.1 Level AA and the principles of the public-sector accessibility rules as a minimum. That is a recommendation to licensing authorities, not a claim that the public-sector regulations directly apply to every private operator. In practice, the website should work with a keyboard, use visible labels and focus, announce validation and confirmation messages, maintain readable contrast, and keep a usable phone or email route available. Operators also have Equality Act duties that should be checked against the real service and fleet.

How much passenger data should the form collect?

The ICO's data-minimisation guidance says personal data must be adequate, relevant and limited to what is necessary for the stated purpose. Collect what is needed to assess and fulfil the journey, not dates of birth, diagnoses, identification documents or months of travel history 'just in case'. Some assistance detail can reveal health or disability information and receive extra protection, so minimise it, restrict access and document the appropriate processing basis for the real workflow.

• Place concise privacy information at the point of collection and link to the full privacy notice.
• Explain who operates the form, why the data is needed, relevant recipients or booking-system providers, and the applicable retention logic.
• Keep booking and marketing separate. A passenger must not have to join a mailing list to request a car.
• Do not keep all raw form submissions indefinitely just because the licence requires a particular booking record for a minimum period.
• Use a suitable payment provider or booking platform for card payments rather than emailing card details to the office.

What should happen after the passenger presses Submit?

• Acknowledge receipt immediately and repeat whether this is an enquiry, an unconfirmed request or a confirmed booking.
• Give a realistic response time and a phone route for journeys that are too urgent to wait for email.
• Check availability, service area, vehicle capacity, accessibility needs, price and any account or payment condition.
• Send an explicit confirmation or rejection. A confirmation should repeat the core journey, operator identity, price status and any important pickup or cancellation terms.
• Create or complete the booking record required by the licensing authority before the journey, including the later driver, vehicle and dispatch details.
• Notify the passenger if the vehicle, pickup plan or operator changes, using the process and disclosures required by the local licence conditions.
• Handle failed submissions and out-of-hours requests visibly; never leave a passenger looking at a spinner with no safe next step.

What should the rest of the operator website show?

• The real licensed operator name, issuing authority, operator licence details where required or useful for verification, and consistent contact information.
• The actual pickup area and the journey types the fleet accepts, rather than dozens of copied town pages.
• Fleet capacities and accessibility features described precisely, without promising that every vehicle has every feature.
• Separate airport, local, executive, event and account pages only when each reflects a real offer and booking process.
• Phone and dispatch hours, advance-notice expectations, urgent-booking instructions and what happens outside those hours.
• Pricing method, payment options, cancellation, waiting and complaint information that matches the operator's terms and local conditions.
• A Google Business Profile aligned with the real premises: Google says a service-area business that does not receive customers at its address should hide that address, while a staffed customer-facing location can show it.

What should you give a website provider before the first draft?

• Your current operator licence, issuing council's current policy and conditions, plus any required website or complaint wording.
• The exact point at which staff or the system accepts a booking and the confirmation messages already in use.
• The booking or dispatch system name, available integration method and which record remains authoritative.
• Service area, fleet, passenger capacities, accessible vehicle details, operating hours and journey types you genuinely offer.
• Your fare, quote, airport waiting, parking, cancellation, no-show, payment and account rules.
• The privacy information, payment provider, complaint route and person responsible for approving changes.
• Real photographs of vehicles, office or drivers that you have permission to publish; no invented partnerships or authority logos.

How would LESTO build a private-hire operator website?

LESTO would start with the operator's real booking workflow, not a generic app mock-up. The first screen would show the service area, staffed contact route and honest action: get a quote, request a journey or book online. Airport, local and account work would collect different facts. Request receipts and confirmations would use different wording, accessibility needs would have a usable route, and the website would direct accepted jobs into the operator's existing process rather than pretending an email inbox is a dispatch system.

Send LESTO your current website, licence details and local conditions, service area, fleet, booking method, fare rules, accessibility arrangements, privacy information and real photos. LESTO creates the first draft free within 24 hours. If it fits, the done-for-you website costs 190 euros per month, with no setup fee and monthly cancellation. Later website changes can be sent by WhatsApp or email. Any booking-system integration or legal review should be scoped separately and confirmed before it is promised.

The takeaway

The right private-hire operator website is not the one with the most app-like features. It is the one that makes the passenger's status clear and feeds the operator's actual process. Choose enquiry, request or confirmation deliberately; collect the right journey and assistance details; check the issuing authority's conditions; and close the gap between the website, dispatcher and booking record. That gives passengers confidence and gives the office fewer incomplete or misunderstood requests.