Contexto
Contexto (por qué esto dolía)
Dónde aparecía la fricción antes de ordenar el proceso.
- ¿Quién lo tiene ahora?
- Yo lo aprobé… creo
- No encuentro el último adjunto
- Nadie vio este email
Automatizar aprobaciones internas: de correos sueltos a circuito auditable
En este caso, el problema no era falta de herramientas. Era falta de control en estado, responsable e histórico de decisiones.
Modelo operativo del caso
El caso se lee por control: contexto, riesgo, estados, responsables y evidencia mínima.
Controlaccount_tree
La pieza clave: bajo control = estados + responsables + evidencia
La pieza operativa que necesitaba quedar definida.
- schemaEstados mínimos pero reales
- supervisor_accountResponsables por fase con ownership explícito
- settings_alertReglas y excepciones operativas
- verified_userEvidencias y auditoría para decidir y defender
Señaleshistory
Qué debía quedar visible
Los mínimos que convierten trabajo disperso en proceso gobernable.
- move_to_inboxEntrada única para cada solicitud (sin ambigüedad)
- splitscreenEstados formales (no columnas)
- person_checkResponsable explícito por fase
- history_eduAuditoría completa (quién / cuándo / por qué)
Antes vs Después
El patrón se repite: menos persecución manual, más estado visible, ownership y rastro auditable.
Antes
AntesAntes: cómo funcionaba la aprobación
Cómo funcionaba el proceso antes de ordenar estados, reglas y responsables.
alternate_email
Solicitudes por email sin identificador claro
manage_search
Seguimiento manual (persecución) y recordatorios a mano
person_off
Responsables implícitos según quién leyera el correo
difference
Versiones distintas de la misma solicitud
edit_note
Decisiones sin registro sólido
history_off
Imposible reconstruir el porqué semanas después
Después
DespuésDespués: qué cambió
Qué queda instalado cuando el caso pasa a proceso trazable.
approval
Entrada única registrada para cada solicitud
visibility
Estado visible para Operaciones sin perseguir
badge
Responsable explícito por fase
notification_important
Excepciones definidas (recordatorio / escalado)
manage_history
Histórico auditable con usuario, fecha y motivo
Método CORTE.App por fases
Primero se fija el estándar de control. La automatización entra después, cuando entrada, estados, responsables y excepciones ya tienen forma operativa.
C
Control (baseline y riesgos)
Mapa AS-IS, fricciones y riesgos de datos/roles/excepciones.
Mapa AS-IS y riesgos
O
Orden (estados, responsables, reglas)
Diseño del circuito listo para implementar con ownership claro.
Estados y ownership
R
Resultado (quick win)
Entrada única + estados + responsables + notificaciones básicas.
Circuito mínimo
T
Trazabilidad (audit-ready)
Histórico de decisiones, evidencias y control de cambios.
Histórico auditable
E
Evolución (escala con criterio)
Reporting e integraciones solo cuando la base ya aguanta.
Reporting e integraciones
Qué queda medible o gobernable
Sin publicar cifras inventadas: el caso deja una base para medir estado, ownership, excepciones y evolución.
Resultadosquery_stats
Qué permite decidir ahora (sin reuniones extra)
- tips_and_updatesQué solicitudes están bloqueadas y por qué
- bug_reportQuién tiene la siguiente acción
- monitoringCuánto tarda cada fase
- checkQué excepciones se repiten
Base técnicalayers
KPIs (baseline → objetivo)
No se publican cifras sin evidencia. Se fijan baseline y objetivos en diagnóstico o Workshop ROI.
- app_registrationTiempo de ciclo (lead time)
- notificationsTiempo en En aprobación
- bar_chartNúmero de persecuciones por solicitud
- checkPorcentaje de solicitudes reabiertas o corregidas
Preguntas frecuentes
Objecion 1help
¿Esto aplica solo a compras y gastos?
No. Aparece en compras, gastos, IT, cambios operativos, validaciones y más.
Objecion 2rule
¿Se puede empezar sin integraciones?
Sí. Primero estados/reglas/responsables y entrada única. Integrar sin claridad amplifica el caos.
Objecion 3account_tree
¿Qué necesito para arrancar un diagnóstico?
Un ejemplo real (email/captura/Excel) y alguien que conozca el proceso.
Si te reconoces en este caso
El siguiente paso no es otra herramienta; es definir el flujo y su roadmap por fases.