Sistema de reservas con n8n: formulario, clientes y disponibilidad

El objetivo inicial es conectar una web con un flujo que recibe solicitudes, reconoce clientes y trabaja con horarios. Las opiniones y la recuperación de clientes se plantean para otra parte; no forman parte de una implementación completa demostrada en esta grabación.

La cifra del título original expresa el posicionamiento comercial de una solución más amplia. No es una venta verificada de este prototipo ni una tarifa aplicable a cualquier empresa. Aquí nos interesa entender el recorrido técnico y sus límites.

Uno de los primeros problemas es que el formulario simula un envío correcto sin estar conectado al flujo. Lo detecto al comprobar que n8n no recibe la solicitud. Después conecto el webhook de prueba y vuelvo a enviar datos ficticios.

Para repetir este aprendizaje, abre la ejecución y localiza los campos que llegan: contacto, servicio, fecha y hora. Compara esa entrada con lo que necesita el siguiente paso. Si falta un dato, corrige su origen antes de intentar compensarlo más adelante.

Durante la demostración doy de alta clientes y vinculo la información con las solicitudes. También aparece la decisión entre crear un registro o utilizar uno existente. Son operaciones distintas: reconocer a la persona no implica que su cita esté guardada.

Un esquema útil para seguir la prueba separa tres elementos: quién solicita, qué solicita y qué franja se asigna. Mantén una referencia clara entre ellos. Al revisar el resultado, comprueba los tres registros y no únicamente el mensaje que ve el usuario.

Buena parte del vídeo consiste en depurar formatos de fecha y hora, identificadores, listas y campos requeridos. Un valor puede parecer correcto en pantalla y no tener la estructura que espera el destino. Leer el error y la entrada de ese paso aporta más información que regenerar todo el flujo.

La prueba termina mostrando una cita registrada y una franja marcada como reservada. Llegar a ese punto exige volver a ejecutar y revisar las tablas, porque en intentos anteriores unas partes se guardaban y otras no. Esa diferencia es precisamente lo que hay que observar en una integración.

Al final de la grabación indico que queda comprobar que los horarios no se pisan. Es un límite importante del ejemplo: una ejecución correcta no demuestra qué sucede cuando dos personas intentan reservar a la vez.

Como ampliación editorial, prepara pruebas de horario ocupado, reenvío de una solicitud, fallo al guardar y dos peticiones simultáneas. Añade una política clara para datos y accesos, y decide cómo resolver una operación que se quede a medias. Hasta completar esas comprobaciones, trata el resultado como un prototipo de aprendizaje.