Bot de registro de horas, de cero a producción

Contexto

Una empresa de servicios de consultoría —unos 60 consultores más sus managers— requiere que cada consultor registre las horas trabajadas por proyecto. El sistema existente era un formulario web legacy de 12 campos, con el proyecto a seleccionar manualmente entre cientos de opciones. 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 o el día del cierre, y el PMO completaba datos a mano. A escala de la operación, unos 2.640 registros mensuales estimados.

Problema

El relevamiento identificó la causa raíz de la baja adherencia: el registro constituía trabajo adicional impuesto al consultor, con un costo por carga superior al de postergarla. El registro tardío degrada la calidad del dato: una hora reconstruida días después es una estimación, no un registro. Con más de la mitad de la operación cargando fuera de las 24 horas, el costeo de proyectos y la asignación de equipos se calculaban sobre datos reconstruidos. 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 de Telegram con Claude Code, sobre un plan escrito como guion de agente: tareas redactadas para ejecución por el agente, con puntos de decisión humana marcados. El bot resuelve la carga con 5 comandos y un flujo guiado por botones —cliente, proyecto, fecha, actividad, tipo de hora, horas, descripción, confirmación—. Si el proyecto no figura en la lista, la opción “Otros” deja el registro en revisión sin frenar al consultor. El modelo de datos comprende 18 tablas que espejan el formulario del PMO, previstas para sincronizar con el ERP sin migración posterior. El paquete incluye 28 tests y despliegue con Docker.

La arquitectura separa el canal de la lógica de dominio: una aplicación, con el canal como fachada. Agregar un canal nuevo implica escribir una fachada adicional, no reescribir el sistema.

El desarrollo del core llevó unos 76 minutos. La puesta en producción demandó ajustes adicionales de infraestructura: el DNS de Alpine no resolvía las direcciones de Supabase dentro del contenedor —la imagen se migró a Debian slim—, pnpm 10 rompió el build y las dependencias del monorepo se empaquetaron manualmente.

Resultados

La primera fase —el bot de Telegram— está desplegada en producción, con smoke test documentado; del primer commit al despliegue pasaron unos diez días de calendario. Durante el smoke test se detectó que el free tier de Supabase se había pausado por inactividad y debió reactivarse. El costo marginal estimado del sistema completo —incluida la futura fase de WhatsApp con carga por voz— es de entre 5 y 10 dólares mensuales; lo desplegado actualmente no agrega gasto significativo.

Tras el despliegue se constató que el equipo no utiliza Telegram como canal habitual. La fase masiva quedó especificada sobre WhatsApp —spec cerrada, aún sin construir—, con carga por audio, y Telegram quedó como canal de administración. Por la separación canal/dominio, el cambio requirió una especificación nueva, no una reescritura.