A booking system with n8n: forms, clients and availability

The initial aim is to connect a website to a workflow receiving requests, recognising clients and handling time slots. Reviews and client reactivation are planned for another part; they are not a complete implementation demonstrated in this recording.

The figure in the original title expresses the commercial positioning of a broader solution. It is not a verified sale of this prototype or a rate applicable to every company. Here, the focus is the technical journey and its limits.

One early problem is that the form simulates a successful submission without being connected to the workflow. I discover it by checking that n8n receives no request. I then connect the test webhook and submit fictional data again.

To repeat the lesson, open the execution and find the arriving fields: contact, service, date and time. Compare that input with the next step's requirements. If a value is missing, correct its origin before trying to compensate later.

During the demonstration, I create clients and link their information to requests. I also decide between creating a record and using an existing one. These are different operations: recognising the person does not mean their appointment is saved.

A useful outline separates three elements: who is requesting, what they request and which slot is assigned. Keep clear references between them. When reviewing the outcome, check all three records, not just the user-facing message.

Much of the video involves debugging date and time formats, identifiers, lists and required fields. A value can look correct on screen while lacking the structure the destination expects. Reading the error and that step's input provides more information than regenerating the entire workflow.

The test ends with a recorded appointment and a slot marked as reserved. Reaching that point requires rerunning and inspecting tables because earlier attempts saved some parts but not others. That difference is precisely what to observe in an integration.

At the end, I say that overlapping bookings still need checking. That is an important limit: one successful execution does not demonstrate what happens when two people book simultaneously.

As an editorial extension, prepare tests for an occupied slot, a repeated submission, a save failure and two simultaneous requests. Add a clear policy for data and access, and decide how to handle a partially completed operation. Until those checks are complete, treat the result as a learning prototype.