// AI & Tools
Build a booking enquiry page
Help customers request a time and keep enquiries organised.
A booking enquiry page lets a customer ask for a service and a preferred time. You confirm availability afterwards. It is a useful starting point when you do not yet need instant bookings.
Make that distinction clear on the page and in its success message.
1. Define the request
For a simple service, the fields might include a name, email, service, preferred date or time and an optional message.
Only collect what you need to handle the enquiry. State what happens after submission and how you will use the information. Decide your service area and available times before building.
2. Plan the two views
The public page explains the service and accepts a request.
The private admin view lets you read requests, set a status and record a next action. Visitors should not be able to read enquiry records. Decide which staff, if any, should have access.
3. Start with this Base44 brief
Build a booking enquiry page for my [service] business. Visitors can request [service options] for a preferred date/time and provide name, email and an optional message. Save valid requests privately. Public users can submit but cannot read enquiry records. Only authorised admins can read and update them. Include a private admin list with New, Contacted, Confirmed and Closed statuses. Include validation, a suitable spam-control approach and clear error/success feedback. The success message must say this is a request and the time is not confirmed until we respond. Do not collect payment or automatically reserve a slot in this first version.
Ask for the implementation's access rules to be explained. Review and test them.
4. Test a normal submission
Use fictional details and send an enquiry. Confirm that it appears once in the admin list with the right values.
Check that refreshing the public page does not submit it again. Change the status as an admin and verify that it persists.
5. Test the failure paths
Try missing fields, an invalid email, a past date where relevant and repeated clicks on Submit.
The page should explain errors and preserve useful input so the person can correct it. A success message should appear only when the request actually saves.
Try reading the enquiry list while signed out or as an ordinary account. The underlying access rules must deny access.
6. Plan the human follow-up
Decide how often you will review requests and how you confirm a time. Until email or calendar connections are configured and tested, do not imply that the app sends messages or reserves appointments.
A calendar integration or instant booking system is a separate step. It needs capacity rules, cancellation handling, time-zone decisions and checks for conflicting requests.
Your next step
Test a complete request-to-confirmation journey with fictional information. Then use a small real pilot only after checking privacy, access and your own business requirements.