La tarea
El encargo llegó desde un equipo que gestiona visitas guiadas a un conjunto de edificios históricos en Mendoza. Durante los meses de mayor afluencia, la demanda se multiplicaba por cuatro y el sistema anterior —una planilla compartida y confirmaciones por correo— empezaba a fallar. Se perdían reservas, se duplicaban cupos y el personal administrativo dedicaba más tiempo a corregir errores que a atender al público.
El objetivo no era construir una plataforma ambiciosa, sino ordenar el flujo de reservas estacionales sin alterar la forma de trabajo del equipo. La restricción principal era clara: el sistema debía funcionar con conexión intermitente, porque dos de las sedes están en zonas con señal inestable.
El enfoque
Antes de escribir una línea de código, pasamos tres semanas observando cómo se tomaban las decisiones reales. Descubrimos que el cuello de botella no estaba en la reserva inicial, sino en las cancelaciones y reprogramaciones de última hora. La mayoría de los conflictos surgían cuando alguien intentaba mover una visita ya confirmada.
Decidimos entonces priorizar la gestión de cambios por encima de la captación. Un formulario simple, con validación local y sincronización diferida, resolvía más problemas que cualquier panel de control sofisticado. También acordamos mantener un canal telefónico para casos excepcionales, porque hay situaciones que ningún formulario cubre bien.
La implementación
El flujo quedó dividido en tres momentos: solicitud, confirmación y reprogramación. Cada uno con su propio registro de responsables y marcas de tiempo. Las reservas se guardan primero en el dispositivo y se sincronizan cuando hay conexión, con un indicador visible del estado de cada operación.
Para las reprogramaciones, incorporamos un margen mínimo de antelación y un límite de cambios por reserva. No es una solución elegante desde lo técnico, pero refleja cómo trabaja el equipo en la práctica: con reglas claras y pocas excepciones.
El resultado
Tras la primera temporada completa, las reservas duplicadas desaparecieron y el tiempo dedicado a corregir errores se redujo a la mitad. El equipo sigue usando la planilla para consultas históricas, pero ya no depende de ella para operar.
Lo más útil del proyecto no fue la herramienta en sí, sino el ejercicio de documentar cómo se toman las decisiones cuando hay presión de tiempo. Ese registro quedó como referencia para futuras temporadas y para otras sedes con problemas parecidos.
Si te interesa cómo abordamos proyectos similares, podés ver el caso anterior o escribirnos desde la página de contacto.
