Build a booking website with AI: availability, holds and confirmations

A worked example: where the task becomes difficult

Consider a fictional bicycle workshop with two repair benches and appointments lasting different amounts of time. A customer chooses a service, sees eligible times and receives a booking reference. The difficult part is not drawing a calendar: two visitors can select the same final space. Define the shop timezone, cleanup interval and capacity before generating the interface. Keep the example separate from real customer bookings until concurrent behavior is tested.

Decisions to make before implementation

Represent requested, held, confirmed, cancelled and expired reservations separately. A temporary hold needs an expiry and must not permanently remove availability if the visitor leaves. The backend should decide whether capacity remains at confirmation; a disabled browser button cannot enforce capacity across customers. If a payment is involved, specify what happens when payment succeeds after the hold expires. Start without payments if the business only needs appointment requests.

A practical sequence for the work

Use the sequence below as a task boundary, not as a claim that the example has been executed. Work with approved inputs and the project’s actual architecture. If a required integration or permission is unavailable, keep that stage visibly incomplete rather than generating a plausible substitute result.

• Model service duration, capacity, timezone and blocked dates before creating the calendar.
• Implement the slot query and confirmation operation against controlled appointment records.
• Connect the form to an acknowledgement containing the accepted status and booking reference.
• Add cancellation and expiry handling, then check the same journey on a phone.

A detailed brief you can adapt for your agent

Replace the illustrative context with your approved facts and controlled inputs. Keep the stated boundaries when adapting the brief. The expected deliverable matters more than a particular tool name: ask for an explanation grounded in the inspected material and evidence for the requested outcome.

Implement one repair appointment journey using the existing framework. Inspect the current data layer before edits. Use the shop timezone and two-bench capacity supplied in this brief. Return explicit reservation states, reject conflicting confirmations and preserve customer input on failure. Do not invent a payment integration. Include a concurrent-slot test and explain which files own availability.

Failure modes that an attractive preview can hide

A common generated prototype keeps bookings only in browser storage. It appears to work on one device while another visitor sees the same free slot. Treat local storage as a prototype boundary, not the shared booking source. Also test daylight-saving transitions and appointments crossing closing time. Preserve the requested slot when confirmation fails, but refresh availability before offering a retry.

Technical references: MDN: sending form data

Acceptance checks and the evidence to retain

Keep the reservation state diagram, slot rules, changed files and evidence from two competing requests. The shop operator should be able to cancel a controlled booking and explain when its capacity becomes available again.

Specific answers

Common questions