Cómo organizar el desarrollo de las reservas de citas
La agenda de una peluquería no cabe en un formulario
Una peluquería en Valencia abre de 10 a 14 y de 17 a 21, cierra los lunes y el sábado solo trabaja por la mañana. Un tinte con mechas ocupa a la estilista casi tres horas, pero mientras actúa el color puede atender un corte rápido. Si la app no entiende el horario partido ni esos huecos, ofrece citas imposibles y la recepción acaba llamando a cada cliente para cambiarla.
Por eso la plantilla dedica sus primeras dos semanas a descubrir y definir. Primero las entrevistas con clientes y con recepción, después las reglas de negocio de horarios, servicios y profesionales, y por último los flujos y wireframes. En América Latina el reto suele ser otro: la gente ya escribe por WhatsApp para pedir turno y espera respuesta en minutos. La reserva en la app tiene que ser más cómoda que eso.
Reglas que conviene cerrar antes de programar
Estas decisiones cambian el modelo de datos o dependen de terceros. Si se dejan para el final, la API de disponibilidad se reescribe a mitad de proyecto.
- Horario partido, día de cierre semanal y jornada de verano de cada local.
- Festivos nacionales, autonómicos y locales, además de los puentes en que el salón cierra.
- Duración de cada servicio, tiempo de limpieza entre citas y servicios que ocupan a dos personas.
- Política de anulación e inasistencias, por ejemplo anular gratis hasta 24 horas antes.
- Cobro de anticipo con tarjeta, Bizum en España o pasarelas locales en México y Colombia.
- Zona horaria por sede: Canarias va una hora por detrás de la Península y México tiene varias zonas.
Tres escenarios donde encaja esta plantilla
La plantilla parte de una app de salón, pero la misma secuencia sirve para otros negocios que viven de la cita previa. Cambia el peso de cada fase.
- Peluquería o barbería en Madrid con muchas inasistencias los viernes, que quiere recordatorio por WhatsApp el día anterior.
- Clínica dental en Ciudad de México que agenda primeras visitas y revisiones, con aviso de privacidad para datos de salud.
- Centro de fisioterapia en Bogotá que vende bonos de diez sesiones y necesita descontar cada cita del bono.
- Taller mecánico en Buenos Aires que reserva turnos para la revisión técnica por franja de horario.
Cómo leer las fases y las dependencias
En cuanto se aprueban las reglas, el trabajo se abre en dos caminos de nueve días hábiles cada uno. Diseño avanza con flujos, wireframes y la UI de las pantallas de agendamiento. Backend modela los datos de agenda, intervalos y servicios y construye la API de disponibilidad y reservas. Los dos caminos se juntan en las pantallas del cliente en la app, así que un retraso en cualquiera de ellos mueve el lanzamiento.
Las notificaciones y recordatorios automáticos y el panel del profesional con la agenda del día dependen solo de la API. Tienen un margen pequeño, unos dos días los recordatorios y uno el panel. Las pruebas y la versión beta con el salón piloto duran cinco días hábiles y arrancan cuando esas tres piezas están listas. En Great Gantt las dependencias ya vienen enlazadas y la ruta crítica muestra qué tareas no pueden retrasarse.
Lanzar sin romper la agenda que ya funciona
La agenda en papel o en WhatsApp, por mala que sea, funciona. Por eso el lanzamiento conviene hacerlo por etapas: primero el salón piloto, después una parte de los clientes con la función activada por una feature flag y al final todos. Si algo falla, se apaga la flag y la recepción sigue dando citas como siempre, sin perder las reservas hechas.
Durante el piloto vale la pena provocar a propósito los fallos típicos. Dos clientes que reservan el mismo hueco a la vez, una cita creada por teléfono que debe aparecer en el panel del profesional, un recordatorio que llega con la hora equivocada por un cambio de horario de verano. Mide también cuántas citas llegan ya por la app y si bajan las inasistencias.