Flujos de reserva que los clientes sí terminan

Un flujo de reserva son los veinte segundos más valiosos de la web de un negocio de servicios. También es donde la mayoría pierde gente sin darse cuenta. Construir interfaces de reserva para barberías, salones, talleres y peluquerías caninas en la biblioteca de demos sacó a la luz el mismo puñado de patrones una y otra vez.

#Empieza por la decisión que el cliente ya ha tomado

Cuando alguien toca Reservar, normalmente ya ha decidido qué quiere. Lo que no ha decidido es cuándo. Muchos flujos empiezan pidiendo nombre, correo y teléfono antes de enseñar una sola franja horaria. Es al revés: pide compromiso antes de dar valor.

Un orden mejor es:

1. Servicio: ya seleccionado si el visitante tocó Reservar en una tarjeta de servicio concreta.
2. Hora: muestra la disponibilidad real lo antes posible.
3. Datos: solo lo que el negocio necesita de verdad para prestar el servicio.
4. Confirmación: un resumen claro, no un «gracias» genérico.

En la demo de barbería, cada tarjeta de servicio tiene su propio enlace de reserva, así que el primer paso ya está hecho cuando se abre el flujo.

#Pide menos

Cada campo de más cuesta reservas terminadas. Para la mayoría de negocios con cita, lo mínimo es un nombre y una forma de contactar con el cliente. Todo lo demás tiene que ganarse su sitio:

• Un taller necesita la matrícula porque determina piezas y tiempos.
• Una peluquería canina necesita el tamaño y la raza del perro porque cambian la duración y el precio.
• Una empresa de limpieza necesita dormitorios y baños porque son el precio.

Fíjate en el patrón: cada pregunta extra cambia directamente lo que va a hacer el negocio. Si un campo no cambia el trabajo, no pinta nada en el flujo.

#Pon el precio y la duración junto al botón

«¿Cuánto cuesta?» y «¿cuánto tarda?» son las dos preguntas que hacen que la gente se detenga a mitad de la reserva. Respóndelas en la tarjeta de servicio y otra vez en el resumen. La demo de limpieza muestra un precio desglosado en vivo que se actualiza al cambiar dormitorios, baños y extras; nadie tiene que adivinar a qué se compromete.

#Diseña para un solo pulgar

La mayoría de búsquedas de servicios locales se hacen en el móvil. Consecuencias prácticas:

• Zonas táctiles de al menos 44×44 px con espacio generoso.
• Campos nativos de fecha y hora donde funcionan bien, y selectores propios grandes donde no.
• Una barra de acciones fija en la parte inferior con Llamar y WhatsApp junto a Reservar, porque siempre habrá clientes que prefieran hablar.

Todas las demos de la biblioteca llevan una barra fija en el móvil precisamente por eso.

#Confirma como un recibo

La pantalla de confirmación debe leerse como un recibo: servicio, fecha, hora, precio, dirección y qué pasa después. Si se puede cambiar o cancelar, explica cómo. La ambigüedad en este punto genera llamadas, justo lo que la reserva online debía reducir.

#Falla con elegancia

Las franjas se ocupan. La red se cae. Un buen flujo conserva lo que el cliente escribió, explica con palabras sencillas qué ha fallado y ofrece la alternativa más cercana. «Algo ha salido mal» con un formulario vacío es la forma más rápida de perder una reserva.

#Qué simulan las demos y qué no

Las interfaces de reserva de la biblioteca de demos son simulaciones: validan los datos y muestran estados de confirmación, pero no se envía ni se guarda nada. Una versión en producción se conectaría a un calendario real, enviaría confirmaciones y gestionaría los cambios de cita. Mantener ese límite explícito forma parte de diseñar con honestidad: un prototipo nunca debe hacerse pasar por un sistema real.

#Una lista breve

• Servicio ya seleccionado desde la tarjeta tocada
• Disponibilidad antes que los datos personales
• Solo campos que cambian el trabajo
• Precio y duración visibles en cada paso
• Acciones fijas en el móvil, incluida una opción humana
• Una confirmación tipo recibo
• Errores que conservan lo escrito y proponen alternativas