Enrutamiento interno de aprobaciones
Una solicitud entra una vez, sigue la ruta de decisión adecuada y regresa con responsable, plazo, motivo y siguiente paso visibles.
Nota del caso
La implementación se trató como un sistema operativo pequeño: primero visibilidad, después ownership y solo entonces automatización.
Caso de uso
Enrutamiento interno de aprobaciones
Una solicitud entra una vez, sigue la ruta de decisión adecuada y regresa con responsable, plazo, motivo y siguiente paso visibles. Un equipo de operaciones en crecimiento gestionaba compras, proveedores, contenido y accesos por correo y chat. Los solicitantes no veían al responsable, los aprobadores recibían poco contexto y los bloqueos solo aparecían cuando ya afectaban a un plazo.
Resultado: La empresa obtiene un sistema ligero de decisiones sin adoptar una plataforma pesada. Las solicitudes siguen la política, el aprobador recibe un resumen listo para decidir y cada resultado vuelve al solicitante con un motivo trazable.
Mapa del flujo
Workflow de solicitud a decision registrada
Cada solicitud recibe owner, estado visible y registro final de decision.
Base de datos principal: Supabase
Todo el workflow usa Supabase como fuente de verdad: guarda cada registro, su estado y los eventos clave para ver que paso, reintentar fallos y depurar sin buscar en cada herramienta.
Iconos de herramientas
Racional del sistema
Un sistema ligero supera las aprobaciones invisibles por chat
El flujo mantiene las aprobaciones sencillas pero inspeccionables: cada solicitud tiene regla, responsable, fecha, recordatorios y decisión final.
El enrutamiento reduce la ambigüedad
El solicitante no necesita conocer el organigrama; el flujo asigna al aprobador según la categoría y la política.
Los recordatorios protegen el ritmo
Los retrasos se ven antes de que una solicitud bloqueada sorprenda a operaciones.
Las decisiones crean historial
Aprobar, rechazar o solicitar cambios queda registrado junto a la solicitud, con motivo y fecha.
Add-ons que encajan encima
El punto de partida
Un equipo de operaciones en crecimiento gestionaba compras, proveedores, contenido y accesos por correo y chat. Los solicitantes no veían al responsable, los aprobadores recibían poco contexto y los bloqueos solo aparecían cuando ya afectaban a un plazo.
El diagnostico se hizo sobre volumen real, herramientas conectadas, puntos de decision y excepciones. La pregunta no era solo que automatizar, sino que prueba demostraria que el proceso habia terminado bien. La prueba operativa importo tanto como la automatizacion.
La implementación
Ductio creó una capa ligera de aprobación: entrada única, reglas por categoría, importe y equipo, asignación de responsable, fechas límite, recordatorios, actualizaciones al solicitante y registro de la decisión.
La implementacion separo reglas, contexto libre, decisiones humanas y efectos externos. Asi el sistema podia mejorar el trabajo diario sin convertir cada excepcion en una caja negra. 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ó Form intake, Supabase, Python/FastAPI, Resend, Log aprobaciones. 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.
Prueba antes/después
Qué cambió en la operación
Antes
Después
Artefactos visibles
- Matriz aprobacion
- Log requests
- Calendario reminders
- Decision record
- Cola overdue
- Ejemplos notificacion requester
Controles
- Reglas de aprobador visibles
- Escalado overdue
- Audit log de decision
- Update al requester
- Reject/revise guarda motivo
Qué cambió después
La empresa obtiene un sistema ligero de decisiones sin adoptar una plataforma pesada. Las solicitudes siguen la política, el aprobador recibe un resumen listo para decidir y cada resultado vuelve al solicitante con un motivo trazable.
El resultado no fue solo ahorrar minutos. El equipo gano una secuencia comun para revisar entradas, entender contexto, decidir, actuar y comprobar que el workflow habia quedado registrado. 50% menos consultas
El workflow en una línea
Cómo se construyó
Un formulario escribe request en Supabase, Python/FastAPI aplica reglas, Resend notifica a aprobadores/requesters, se programan reminders de overdue y la decision final vuelve al approval log.
El stack fue pragmático: Form intake, Supabase, Python/FastAPI, Resend, Log aprobaciones. 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
- Matriz aprobacion
- Asignacion owner
- Reminders por fecha
- Updates requester
- Escalado overdue
- Decision log
- 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.
- Approvers reciben el contexto necesario en un solo mensaje.
- Cada approve/reject/revise queda registrado con motivo y timestamp.
- El mismo patron soporta compras, vendors, contenido y accesos.
- Los responsables distinguen los cuellos de botella de política de los retrasos individuales y mejoran las reglas con datos reales.
