Routing interno de aprobaciones
Requests internos pasan de inbox/chat a workflow con owner y reminders.
Nota del caso
La implementación se trató como un sistema operativo pequeño: primero visibilidad, después ownership y solo entonces automatización.
El punto de partida
Las aprobaciones internas estaban repartidas entre inbox y chat. Los requesters preguntaban por estado porque nadie veía dónde se atascaba cada request.
La señal importante no era que el equipo trabajara mal. Era que el trabajo dependía de memoria, copiar datos, revisar sistemas en paralelo y decidir prioridades sin una fuente de verdad compartida. El primer valor fue convertir trabajo invisible en un workflow visible.
La implementación
Ductio creó un intake único con reglas de routing, asignación de owner, reminders y updates al requester.
El scope se mantuvo deliberadamente pequeño. Las reglas cubren lo repetible, la IA se usa para resumir o clasificar cuando el texto libre aporta contexto, y las decisiones sensibles quedan en revisión humana. IA como apoyo dentro del proceso, no como piloto automático.
Qué se usó
La selección de herramientas se hizo desde el proceso, no desde una preferencia técnica previa. El criterio fue que cada pieza tuviera un owner claro, integración estable y una forma sencilla de revisar errores.
En la práctica se combinó Tally/Typeform, Airtable, Slack/Teams, Make, Email. Las herramientas visibles para el equipo quedaron cerca de su trabajo diario, mientras la lógica de integración quedó documentada y separada de decisiones comerciales sensibles.
La mejora se vio en el trabajo diario.
En lugar de presentar el resultado como un dashboard, el equipo lo notó en tres escenas concretas: menos preparación manual, menos búsqueda de contexto y menos dudas sobre quién tenía que actuar.
Status checks: Mensajes de seguimiento pasó de Frecuentes a Mitad.
Owner: Requests con aprobador pasó de Bajo a Alto.
Overdue: Requests con aging pasó de Oculto a Visible.
Qué cambió después
El ownership queda visible sin meter a la empresa en una herramienta pesada.
El cambio más valioso fue la calma operativa. El equipo dejó de perseguir datos sueltos y empezó a trabajar desde una secuencia común: entrada, contexto, decisión, acción y evidencia. 50% menos checks
El workflow en una línea
Cómo se construyó
Un form dispara routing por reglas, crea tarea de aprobación, notifica, monitoriza fechas y escribe decisión final en el log.
El stack fue pragmático: Tally/Typeform, Airtable, Slack/Teams, Make, Email. No se eligieron herramientas para impresionar, sino por ownership, integración y mantenimiento. El resultado es un sistema que el equipo puede entender y operar.
Lo que quedó entregado
- Request form
- Reglas aprobación
- Reminders
- Updates requester
- El ownership quedó visible para requester y aprobador.
- Mensajes repetidos de status bajaron alrededor de la mitad.
- Los requests overdue se detectan antes de bloquear trabajo.
