Reemplazo de un formulario de registro de horas por un bot conversacional

Contexto

Empresa de tecnología B2B del grupo, con unos 60 ingenieros consultores más sus managers, que requiere que cada ingeniero registre las horas trabajadas por proyecto. El sistema existente era un formulario web de 12 campos, con el proyecto a seleccionar manualmente entre cientos de opciones.

Problema

Según el relevamiento del proyecto, cada carga llevaba de 2 a 3 minutos y menos de la mitad de las horas se registraba dentro de las 24 horas; el resto se reconstruía al final de la semana, y el equipo de gestión de proyectos completaba datos a mano. El registro tardío degrada la calidad del dato: una hora reconstruida días después es una estimación, no un registro, y esa base afecta el costeo de proyectos y la asignación de equipos. El criterio de diseño derivado del relevamiento fue reducir la fricción de registro hasta que cargar una hora cueste menos que postergarla.

Solución

Se construyó un bot conversacional con un asistente de IA de código, sobre un plan escrito como guion de agente, con puntos de decisión humana marcados. El bot resuelve la carga con un flujo guiado por botones y deja en revisión, sin frenar al ingeniero, cualquier proyecto que no figure en la lista.

• Flujo guiado de ocho pasos (cliente, proyecto, fecha, actividad, tipo de hora, horas, descripción, confirmación).
• Modelo de datos de 18 tablas que espejan el formulario existente, previsto para sincronizar con el sistema de gestión sin migración posterior.
• Arquitectura que separa el canal de comunicación de la lógica de negocio, de forma que sumar un canal nuevo no requiere reescribir el sistema.
• Pruebas automatizadas y despliegue empaquetado incluidos en el proyecto.

Resultados

• Primera fase desplegada en producción, con verificación funcional documentada, a los diez días de iniciado el desarrollo.
• El smoke test previo al lanzamiento detectó una pausa por inactividad en el servicio de base de datos, reactivada antes de habilitar el canal.
• Tras el despliegue se constató que el equipo no usa el canal elegido de forma habitual, lo que llevó a especificar una fase nueva sobre otro canal; la separación de arquitectura entre canal y lógica de negocio permitió resolverlo con una especificación nueva en vez de una reescritura.
• Se abrió además un piloto de ejecución delegada a agentes de IA sobre este proyecto; se pausó antes de producir cambios en producción y el proyecto pasó a otro equipo.
• El caso documenta el diseño y el despliegue de la primera fase; el canal de mayor alcance y el tablero de gestión de proyectos no se habían iniciado al cierre de este registro.

Arquitectura y decisiones

La arquitectura separa el canal de comunicación de la lógica de dominio: una aplicación central con una fachada distinta por cada canal, de modo que agregar un canal nuevo implica escribir una fachada adicional y no reescribir el sistema. El primer canal construido resuelve la carga con un conjunto acotado de comandos y un flujo guiado por botones; si el proyecto no figura en la lista, la opción de excepción deja el registro en revisión sin frenar al ingeniero.

El modelo de datos comprende 18 tablas que espejan el formulario de gestión de proyectos existente, pensadas para sincronizar más adelante con el sistema de gestión sin requerir una migración posterior.

El desarrollo del núcleo del sistema se resolvió en menos de dos horas de trabajo efectivo. La puesta en producción demandó ajustes adicionales de infraestructura de despliegue —resolución de nombres dentro del entorno de ejecución y empaquetado de dependencias— hechos antes del lanzamiento, sin los cuales el canal no hubiera podido publicarse.