How to Build a Booking Website With AI (No Double-Booking)

To build a booking website with AI, list your services, durations, opening hours and booking rules, then describe them in one prompt. The builder creates the booking page, stores reservations in a database, blocks slots that are already taken and gives you an admin area. Email confirmations and deposits work once you add your SMTP and Stripe keys.

• Write your availability rules first: durations, buffers, notice, booking window, staff and cancellation policy. A builder can only enforce rules it has been told.
• Double-booking is prevented by a guarded write: a slot is claimed only if it is still free at that instant, so two people booking at once can't both win.
• Your admin area is where you see, move and cancel bookings and block time off; staff can have their own logins and schedules.
• Confirmations and reminders go through your own SMTP account, and reminders run on a 30–60 minute schedule, so they aren't minute-exact.
• Deposits use your own Stripe account, and a booking is confirmed only when Stripe's webhook says the payment succeeded.
• Test with two phones before launch, then move the site to your domain and add the booking link to your Google Business Profile.

What a booking website needs, and the rules to write down first

From the outside, a booking website is simple: pick a service, pick a time, done. The real work is in the rules behind the calendar. Put them on paper before you prompt.

Services, durations and staff

List every bookable service with its duration, price and who can perform it. Take a two-chair salon: a cut is 45 minutes, color is 120 minutes plus 15 minutes of clean-up, a beard trim is 20 minutes. Ana works Tuesday to Saturday, 9:00 to 17:00; Ben works Thursday to Sunday, 10:00 to 18:00; only Ana does color. That paragraph is already most of a booking system.

Tutors, consultants and clinics share that shape: sessions, lengths, people. Classes and rentals differ, because they have capacity. For a 12-place yoga class or a fleet of four kayaks, "booked" means "no places left", not "someone has this hour".

Availability rules checklist

Slot interval

How often a start time is offered, such as every 15 or 30 minutes. Short intervals fill gaps; long ones keep the day tidy.

Buffer

Time blocked after an appointment for cleaning, notes or travel. It belongs to the appointment, not to the next customer.

Minimum notice

How soon someone can book, for example nothing less than two hours ahead.

Booking window

How far ahead the calendar opens, such as eight weeks.

Capacity

How many bookings one slot takes: one per staff member, or a place count for classes and rentals.

Cancellation policy

Until when customers can cancel or reschedule themselves, and what happens to a deposit after that.

Add your time zone, your closing days and whether bookings confirm instantly or wait for your approval. Instant confirmation suits most service businesses; approval suits high-value or unusual requests.

Build it step by step with a prompt template

1. Write your services and rules in a note, using the checklist above.
2. Create a free Community account (no card) and start a new chat on the web or in the mobile app.
3. Attach your price list if you have one, as a PDF, spreadsheet or photo. Reference files of up to 25 MB each are read as context.
4. Paste the template below with your details. If Wisy asks a question, answer it; otherwise the build starts and reports progress in the chat.
5. Read the build's final note. It explains how to sign in to the admin area and which integrations, such as email or Stripe, are waiting for your details.
6. Add those details under Integrations, never in the chat.
7. Run the tests in the next section, then ask for changes in the same chat.

Build a booking website for [business name], a [type of business] in [city]. Time zone: [Europe/London].

Services (name, duration, price, who does it): [Cut, 45 min, $40, Ana or Ben]; [Color, 120 min plus 15 min buffer, $95, Ana only]; [Beard trim, 20 min, $15, Ben only].

Staff hours: [Ana: Tue–Sat 09:00–17:00]; [Ben: Thu–Sun 10:00–18:00]. Customers choose a service, then a staff member or "anyone available", then a free time.

Rules: start times every [15] minutes; book at least [2 hours] and at most [8 weeks] ahead; customers can cancel or reschedule until [24 hours] before. Never let two bookings overlap for the same staff member, buffers included, even if two people book at the same moment. Load available times live when a date is picked.

Booking form: name, phone, email, optional note. Afterwards, show a confirmation with a booking code and a link to cancel or reschedule.

Admin: a private admin area with today's and upcoming bookings per staff member, where I can move or cancel bookings and block days off, holidays and breaks. Staff get their own logins and see only their own schedule.

Email: through my SMTP account, a confirmation when a booking is made and a reminder about 24 hours before.

Deposits: a [$20] Stripe deposit for [Color]. Hold the slot for 30 minutes while the customer pays and release it if payment doesn't complete.

That's a complete system in one message. On the free plan, Wisy keeps each build to a working first version, so expect the booking flow and admin first, with emails and deposits in follow-up builds; paid plans allow fuller builds and less waiting between them. More templates are in our AI website builder prompt templates, and the general flow is in how to build a website with AI.

How double-booking is prevented

Double-booking is a timing problem. Two customers open the page at 10:00 and both see 15:00 as free. Both tap Book in the same second. A naive system checks "is 15:00 free?" for each request, gets "yes" twice and writes two bookings.

WisyLink's data layer has a guarded update for exactly this case. The app claims the slot with one instruction: take it only if it is still free. The check and the write happen as a single step, so one customer gets the booking and the other immediately sees "That time was just taken, please pick another". The same guard stops overselling a class: the place count only goes down while it is above zero.

Two details belong in your prompt, and in your tests:

• Overlaps, not just identical start times. A 45-minute cut at 14:30 and a 120-minute color at 13:00 never share a start time, yet they collide. Ask for "no overlapping bookings, buffers included".
• Live availability. Pages are cached and refresh within about a minute of a data change, so a slot can look free for a moment after it is taken. The guard still blocks the second booking, but customers have a better time when free times load fresh as they pick a date, which is why the template asks for it.

The test takes two minutes. Open the booking page on two phones, choose the same service, staff member and time, and tap Book on both together: exactly one should succeed. Then try a booking that overlaps an existing one by 15 minutes, and one inside a blocked break. If anything slips through, describe what happened in the chat and ask for a fix.

Your admin area: see, move and cancel bookings

Your site runs its own accounts for you and your staff, with hashed passwords, session cookies and roles. That's what makes a proper admin area possible:

• Day view: each staff member's bookings with customer name, service, phone and notes.
• Move: pick a new time for a booking. Moving uses the same guard as booking, so you can't drop a client into a taken slot by mistake.
• Cancel: frees the slot for other customers at once.
• Block time: days off, holidays, lunch breaks or a week of vacation, removed from the public calendar.
• Staff logins: each person manages only their own schedule, and the admin role sees everyone's.
• Export: a CSV of bookings for your accountant or your records.

Blocking a day doesn't cancel the bookings already on it. Ask for a warning that lists them when you block a busy day, and contact those customers yourself. The admin area is a web page, so it works in your phone's browser; add it to your home screen and it behaves like an app at the front desk.

Confirmation and reminder emails

Email goes through your own SMTP account, the sending login from your business mailbox or an email-sending service. When the build adds email, Integrations shows an "Email (SMTP)" entry with host, port, username, password and from address. Fill it in once; the values are encrypted and never shown again.

Until then, no email is sent. Bookings still work, and customers still see their confirmation and booking code on screen. That's enough for a quiet soft launch, but don't open bookings to the public without confirmations: people who hear nothing may book again, or forget the time.

Reminders need something to wake up and send them while nobody is on the site. WisyLink sites can run scheduled jobs for that, at a fixed interval of 30 to 60 minutes. So "24 hours before" really means "within about an hour of the 24-hour mark": an appointment at 15:00 on Thursday gets its reminder within an hour or so of 15:00 on Wednesday. That's fine for reminders and wrong for anything that must happen to the minute. Two safeguards are worth asking for: mark each booking once its reminder is sent, so a repeated run never sends it twice, and skip cancelled bookings.

Text-message reminders are possible through an SMS provider's API, with your own account and keys; request them as their own feature and test them. Calendars work the same way. Customers can get an "add to calendar" file with their confirmation, but a two-way sync with your Google Calendar isn't built in. It can be connected through an integration that uses your own Google credentials, so ask for it explicitly and test it before you rely on it.

Deposits or full payment with your Stripe account

Can customers pay a deposit when they book? Yes. WisyLink doesn't process payments itself: your site calls Stripe, or another provider with an API, using your own account, and the money goes to you. First check that Stripe supports businesses in your country.

A correct deposit flow has five steps. Knowing them lets you test each one:

1. The customer picks a time. The site saves the booking as pending and holds the slot.
2. The customer goes to a Stripe checkout page for the deposit.
3. Stripe sends your site a signed webhook when the payment succeeds. Only then is the booking confirmed and the confirmation email sent.
4. If the customer abandons the payment, the hold expires and the slot opens again. Thirty minutes is a sensible hold, and it is also the shortest expiry Stripe allows for a checkout session.
5. Cancellations inside your policy are refunded from your Stripe dashboard, or from a refund button in the admin if you ask for one.

Step 3 is the one that matters. The page a customer lands on after paying proves nothing: anyone can open that address, and some customers close the tab before it loads. Stripe's own fulfillment guide says webhooks are required for this reason, and WisyLink builds payments that way: the booking is written first and confirmed only by the verified webhook.

Under Integrations, start with Stripe's test keys, run a few bookings with Stripe's test cards, then swap in your live keys. Until keys are there, payments stay inactive, so don't advertise deposits before that. Stripe charges a fee on each payment; factor it into the deposit amount.

Custom booking site vs booking-software subscription

Booking software is a mature category, and for many businesses a subscription is the right answer. An honest comparison:

Choose a subscription if you need two-way calendar sync, text reminders and a point-of-sale connection on day one and your rules are standard. Choose a custom site if your rules don't fit a template (mixed durations, capacities, approvals, packages), if per-staff pricing adds up for your team, or if you want booking to be part of your own website rather than a link to someone else's.

Launch: domain, Google Business Profile and SEO

Before customers see it, run the double-booking test, make a booking from start to finish on a phone, cancel it with the customer link and check that every email arrives. WisyLink's terms make reviewing and testing AI-built output your job, and a booking system is where an untested edge case costs real appointments. Our essay on evaluating what is generated explains why a repeatable test list beats a quick look.

1. Move it to your domain. Free links last 30 days, so a live booking system belongs on a paid plan. Connect a domain such as book.yoursalon.com before you print anything; our guide to connecting a custom domain covers the DNS steps.
2. Add the booking link to Google. In your Google Business Profile you can add an appointment link, so people book straight from Search and Maps.
3. Use the link everywhere. Social bios, email signatures, receipts and the sign at the front desk.
4. Help search engines. Every WisyLink site serves readable HTML, titles and descriptions, a sitemap and robots.txt. Ask for a page per service with a real description and price, and for local business structured data with your address, phone and opening hours.

Build your booking site

Describe your services and rules in one message and get a live booking page: start free on Community, no card needed. Test it with two phones, add your SMTP and Stripe keys, then move it to your own domain (any plan works) and pick a paid plan to keep it live. For other things you can build the same way, see the use cases.