Un proyecto acotado, con decisiones y límites que se reconocen al trabajar con temporadas reales.
La idea surgió al revisar cómo se organizaban las reservas cuando la demanda cambia de golpe. No era un problema de falta de herramientas, sino de orden: cada temporada arrastraba una lógica distinta y el equipo acababa improvisando reglas nuevas sobre las viejas. El encargo fue poner eso por escrito antes de tocar nada más.
El trabajo se dividió en tres frentes. Primero, mapear el recorrido real de una reserva desde que entra hasta que se cierra, incluyendo los puntos donde se atasca. Segundo, separar lo que depende de la temporada de lo que debería ser estable todo el año. Y tercero, dejar un flujo mínimo que cualquiera pudiera seguir sin consultar a quien lo diseñó.
Hubo concesiones. Automatizar ciertos avisos habría ahorrado tiempo, pero también habría escondido señales que el equipo usaba para detectar problemas antes de que crecieran. Se optó por mantener esos avisos manuales y documentar por qué. Esa decisión, incómoda al principio, terminó siendo la parte más útil del proyecto.
Punto de partida
Reglas heredadas de temporadas anteriores, sin criterio común y con excepciones que nadie recordaba por qué existían.
Restricción clave
No se podía ampliar el equipo ni añadir herramientas nuevas durante la temporada alta.
Qué se cambió
Un único documento de flujo, con las variantes de temporada marcadas y separadas del tronco común.
Resultado
Menos consultas cruzadas y una base clara para revisar el flujo al cerrar cada temporada.
Este proyecto se apoya en el mismo criterio documental que aplicamos en
Client Onboarding Portal
y en las notas de método que publicamos en
Proyectos.