Un robot que deriva cualquier problema a una bandeja de correo no ha resuelto la gestión de excepciones. Ha cambiado el lugar donde se acumula el trabajo. La automatización queda incompleta si la persona recibe un aviso sin saber qué ocurrió, qué se ha ejecutado y qué puede hacer a continuación.
Una cola de revisión debe convertir un fallo en una decisión concreta. Para diseñarla conviene empezar por los casos que requieren criterio humano y distinguirlos de las incidencias técnicas que admiten una recuperación controlada.
Tres situaciones que no deben compartir el mismo tratamiento
Supongamos un proceso ilustrativo que recibe pedidos y los registra en un sistema de gestión. Aparecen tres incidencias: el proveedor de la API no responde, el código de cliente no existe y la confirmación del registro se pierde por un corte de conexión.
| Situación | Primera actuación | Información que necesita la persona |
|---|---|---|
| Servicio temporalmente indisponible | Reintentar de forma limitada y con espera | Intentos realizados y próxima acción prevista |
| Cliente desconocido | Detener ese pedido y asignar revisión | Identificador recibido, fuente y posibles coincidencias |
| Registro con resultado incierto | Consultar el destino antes de repetir | Identificador de operación y evidencia de ejecución |
Reintentar el cliente desconocido no corregirá un dato maestro. Volver a registrar el pedido cuyo resultado se desconoce puede duplicarlo. El código de error, por sí solo, no describe la decisión operativa.
El equipo debe mantener un catálogo pequeño de causas conocidas. Cada causa tendrá responsable, acción permitida y condición de cierre. Los casos no clasificados también necesitan una salida: investigación con seguimiento, sin convertirse en un depósito permanente de incidencias.
La ficha de excepción debe ahorrar investigación
La ficha propuesta para este ejemplo contiene el identificador del pedido, la versión del proceso, el paso alcanzado, la causa normalizada y una cronología breve. Añade la acción que ya se confirmó en el destino y la que quedó pendiente.
Evita copiar indiscriminadamente documentos completos o datos personales. El revisor necesita referencias estables a la evidencia y acceso autorizado a ella. Un enlace que caduca antes de la revisión obliga a repetir la investigación; una captura sin contexto puede llevar a decidir sobre información antigua.
Conviene separar el dato original de la corrección propuesta. Si alguien sustituye el código de cliente, conserva el valor recibido, el nuevo valor, quién realizó el cambio y su motivo. Así se puede explicar por qué la operación finalmente registrada difiere de la solicitud inicial.
Estados que describen trabajo real
Una secuencia útil puede ser: pendiente, asignada, esperando información, lista para reanudar y resuelta. Añade descartada cuando el proceso admite una cancelación justificada.
Estas etiquetas solo ayudan si las transiciones tienen reglas. Una excepción no debe quedar resuelta porque alguien la abrió. Tampoco debe volver automáticamente al robot mientras sigue pendiente una aprobación.
En el pedido con cliente desconocido, la persona selecciona una correspondencia validada. El sistema registra la corrección y pasa a lista para reanudar. El robot retoma el proceso desde el paso previsto y confirma el resultado antes de cerrar la excepción. Si falla otra vez, se conserva la relación con el caso original.
Las colas de trabajo de Power Automate ofrecen un mecanismo para desacoplar etapas y priorizar elementos de proceso. La herramienta aporta soporte operativo; el significado de cada estado y la responsabilidad de resolverlo siguen siendo decisiones del proceso.
Evitar que dos revisores ejecuten la misma acción
Asignar un caso visualmente no basta si dos personas pueden aprobarlo al mismo tiempo. La aplicación debe comprobar que el estado y la versión siguen siendo los que vio quien revisa. Si otro usuario ya actuó, se muestra el estado actual y se impide repetir la transición.
Aplica el mismo criterio al retorno al robot. La orden de reanudar debe tener una identidad estable y comprobar el resultado anterior, aplicando el mismo principio de idempotencia que protege una carga de datos. En nuestro ejemplo, aprobar una corrección dos veces no debe producir dos pedidos.
También hace falta una política para casos abandonados: cuándo caduca una asignación, quién puede reasignarla y cómo se detecta que una persona ha dejado el puesto. El vencimiento de una asignación no debería borrar lo trabajado ni autorizar por sí solo una operación de negocio.
Qué medir para mejorar el proceso
Además del número de excepciones, observa su antigüedad, la espera hasta la primera intervención, las reaperturas y los motivos recurrentes. Separa el tiempo en manos del equipo del tiempo esperando información externa.
Un descenso en la cola puede significar que se resolvió trabajo o que se cerraron casos incorrectamente. Contrasta los cierres con el resultado del sistema de destino. Revisa una muestra de expedientes y comprueba si otra persona podría reconstruir la decisión sin preguntar al operador original.
Antes de desplegar, ensaya una doble aprobación, una asignación abandonada y una reanudación que falla después de escribir. Esas pruebas revelan si la cola controla el proceso o solo muestra sus incidencias.
En un proyecto de automatización de procesos y RPA, diseñar estas excepciones forma parte del alcance operativo. Si necesitas definir la frontera entre robot y revisión humana, plantea el proceso a Nexeus Big Data con ejemplos de incidencias y las acciones que hoy requieren intervención.