Qué debe significar la decisión
Una aprobación debe permitir reconstruir una decisión, además de enviar recordatorios. Defina qué se aprueba, qué versión ve la persona y qué efecto produce. Una modificación posterior puede exigir nueva autorización; de lo contrario, el historial describe algo que nadie aprobó.
Roles y alternativas
Empiece por roles y límites. Un equipo pequeño puede usar una cola compartida con decisiones registradas. Otro proceso necesitará delegación, escalado y separación entre solicitante y aprobador. Establezca qué ocurre con ausencias y solicitudes vencidas. El silencio no debe convertirse en aprobación sin una regla acordada.
Recorrer el cambio
En una compra ficticia, el empleado presenta proveedor, importe y motivo. El responsable aprueba esa versión. Si compras cambia el proveedor, vuelve a revisión. Si el responsable está ausente, la recibe un delegado identificado y queda constancia. Distinga estados pendiente, aprobado, rechazado y sustituido.
Comprobar los fallos
Un correo entregado no demuestra autorización. Repetir un clic tampoco debe crear varias órdenes. Conserve la decisión y permita reintentar la acción final sin duplicarla. Pruebe rechazo, retirada, pestañas antiguas y revisores simultáneos. Corregir una decisión anterior debe dejar explicación, no borrarla.
Guardar una decisión que se pueda reconstruir
Separe solicitud, decisión y orden de compra resultante. Cada una necesita identidad; conserve la versión revisada. Registre quién actuó, con qué autoridad, cuándo y por qué cuando corresponda. El historial debe permitir reconstruir lo sucedido sin consultar buzones ajenos ni adivinar el adjunto vigente.
Revise acciones simultáneas con operaciones. Dos personas pueden abrir la misma versión y la primera decisión dejar obsoleta la segunda pantalla. La segunda acción debe explicar el resultado sin sobrescribir. Retirar una solicitud durante la revisión tampoco debe permitir una compra por clic tardío. Aclare si hacen falta todas las aprobaciones, si un rechazo termina el flujo y qué cambios reinician lo aprobado.
Separe fallo de política y de transmisión. Una compra aprobada que no llega al sistema de compras sigue aprobada, con ejecución pendiente o fallida. Repetir la decisión gerencial confunde autorización y transporte. Reintente solo lo pendiente con un identificador que evite duplicados. Dé al operador una reparación controlada, registre su historia y compruebe la orden resultante. Revise excepciones para detectar reglas faltantes.
Una matriz de aceptación breve
| Caso | Prueba que revisar |
|---|---|
| Proveedor cambiado tras aprobar | La nueva versión exige revisión; la decisión anterior no autoriza el reemplazo. |
| Dos revisores simultáneos | Ambos reciben resultados claros, sin sobrescritura ni orden extra. |
| Fallo de aviso después de aprobar | La decisión persiste y el envío se reintenta sin reabrir ni duplicar la compra. |
| Delegación vencida | La acción siguiente verifica autoridad actual y rechaza la delegación expirada, conservando actuaciones legítimas anteriores. |
Acordar estas reglas
¿Quién solicita, decide, delega y anula? ¿Qué cambios invalidan la aprobación? ¿Qué ocurre al vencer el plazo? Lleve una solicitud habitual y una excepción discutida a la conversación sobre automatización. Aclare la política antes de diseñar pantallas.