Caso de proyecto
Un proyecto acotado, armado alrededor de decisiones concretas y restricciones reales de una agencia en Buenos Aires que trabaja con picos fuertes entre diciembre y marzo.
La agencia venía manejando la temporada alta con planillas paralelas, correos y llamadas. La idea no era reemplazar todo de golpe, sino ordenar el circuito de reservas para que el equipo pudiera sostener el volumen sin sumar errores ni horas extra.
Durante los meses fuertes, la agencia recibía pedidos por mostrador, WhatsApp y correo al mismo tiempo. Cada vendedor anotaba lo que podía y después alguien reconstruía la reserva. Cuando el proveedor devolvía un error, no quedaba claro quién lo estaba siguiendo.
El problema no era la falta de herramientas, sino que cada una vivía por separado. Nadie tenía una vista única del estado de una reserva, y eso se notaba más justo cuando había más volumen.
Antes de tocar cualquier integración, mapeamos el recorrido real de una reserva: desde que entra el pedido hasta que se confirma. Eso dejó a la vista tres puntos donde se perdía información y dos pasos que se podían unificar sin riesgo.
Decidimos no automatizar todo. Los pedidos corporativos con reglas propias siguieron pasando por revisión humana, y el resto se apoyó en un flujo con estados claros y avisos automáticos cuando algo se trababa.
Cada reserva pasa por los mismos estados, sin importar el canal por el que entró. Se terminó el "¿esto ya se confirmó?".
Datos del pasajero y del pago se revisan antes de enviar al proveedor. Menos rechazos, menos reintentos manuales.
Solo se notifica cuando algo se sale del flujo esperado. El equipo deja de mirar pantallas que no dicen nada.
Queda anotado quién modificó qué y cuándo. Útil cuando hay que reconstruir una reserva con el cliente al teléfono.
Arrancamos con un solo tipo de reserva y un vendedor. Recién después se abrió al resto del equipo.
Cada paso quedó escrito en un documento breve. No es glamoroso, pero evita que todo dependa de una sola persona.
Después de dos temporadas usando el flujo, la agencia dejó de perder reservas por datos mal cargados y redujo bastante el ida y vuelta con el proveedor. No desaparecieron los problemas: siguen apareciendo casos raros, sobre todo con pedidos corporativos.
Lo que cambió es que ahora esos casos se detectan antes y hay un lugar donde mirar. El equipo dejó de improvisar y empezó a trabajar con un criterio común, incluso cuando la temporada aprieta.
Tres proyectos que muestran cómo encaramos la conexión de sistemas turísticos: desde el alta de una agencia nueva hasta el flujo de temporada alta y el panel que usa el equipo de soporte todos los días. Cada uno tiene su propio punto de partida y sus propias restricciones.
Alta de agencias con credenciales y entornos separados
Este caso parte de una situación concreta: una agencia que recién arranca con la API y no puede frenar la atención al mostrador. El portal ordena la entrega de credenciales, separa pruebas de producción y deja registro de quién modificó cada configuración. La idea es que el equipo entienda qué puede resolver solo y en qué momento conviene pedir acompañamiento.
Ver el caso completoFlujo de reservas para temporada alta
Acá el foco está en las decisiones prácticas: qué tareas se automatizan, cuáles necesitan validación humana y cómo se manejan los reintentos cuando el proveedor responde lento. El caso repasa los cuellos de botella que aparecen en enero y julio, y muestra controles simples para detectarlos antes de que afecten al pasajero. No hay promesas grandilocuentes, solo un flujo probado con volumen real.
Ver el caso completoPanel interno para el equipo de soporte
El tercer caso toma otro ángulo: el panel que usa el equipo para seguir incidencias de integración. Se reorganizaron los registros de eventos, se agruparon los errores por proveedor y se dejó a mano el historial de cambios de cada conexión. El resultado es un tablero que se lee en segundos, incluso en medio de un reclamo.
Ver el caso completo