Cuando una automatización no puede completar un caso, una alerta aislada suele trasladar el problema a una persona sin darle los medios para resolverlo. El resultado puede ser una búsqueda de contexto entre sistemas, decisiones inconsistentes o casos que quedan pendientes sin responsable. Una bandeja de trabajo bien diseñada convierte esa interrupción en un flujo operativo: presenta el caso, indica qué se necesita y permite decidir qué ocurre después.
El objetivo no es crear otra lista de tareas. Es facilitar una intervención humana concreta y acotada, integrada con el proceso automatizado. Para ello, el diseño debe definir cuándo abrir un caso, qué mostrar, qué acciones permitir, quién se hace cargo y cómo se confirma el cierre.
Cuándo hace falta una bandeja y cuándo basta una alerta
Una alerta puede ser suficiente si solo se necesita informar de un evento y no hay que investigar, decidir ni actualizar datos. En cambio, conviene crear un caso en una bandeja cuando alguien debe revisar evidencia, elegir entre alternativas, corregir información o completar una etapa que la automatización no puede ejecutar con seguridad.
Antes de construir la interfaz, identifica el motivo de intervención y el resultado esperado. Por ejemplo, no es lo mismo pedir que una persona confirme un dato dudoso que solicitar que autorice una operación o solicite información adicional. Cada motivo debe tener una regla de entrada comprensible y una salida definida.
- Usa una alerta si el aviso no requiere seguimiento individual ni una decisión.
- Usa una bandeja si hay trabajo pendiente, responsable, estado y una condición de cierre.
- Revisa el proceso si la mayoría de casos termina en una operación manual repetitiva: quizá la automatización o sus reglas necesitan ajustes.
La bandeja tampoco debe convertirse en un contenedor de cualquier error técnico. Las fallas de infraestructura o integración pueden requerir herramientas y responsables distintos. Separa los problemas operativos que una persona usuaria puede resolver de los incidentes que necesitan atención técnica.
Qué contexto necesita quien revisa
La persona debe poder entender el caso sin reconstruirlo desde cero. Muestra primero la información que explica por qué llegó a revisión y qué decisión se necesita. El contexto mínimo suele incluir el origen, el motivo, el impacto potencial, el historial relevante y el siguiente paso esperado. Evita presentar campos sin relación con la decisión.
Haz explícita la diferencia entre un dato confirmado y uno inferido o pendiente de validar. Si el sistema detectó una discrepancia, presenta los valores comparados y su procedencia cuando esa información esté disponible. Si existe un límite de tiempo o una consecuencia por demora, muéstralo con claridad y sin convertir cada caso en una falsa urgencia.
- Origen: qué proceso o evento creó el caso.
- Motivo: qué condición impidió completar la automatización.
- Impacto: qué parte del proceso espera una resolución.
- Historial: intentos anteriores, cambios y decisiones relevantes.
- Siguiente paso: qué puede hacer la persona y qué ocurrirá después.
Permite acceder al detalle adicional cuando haga falta, pero no obligues a abrir varias pantallas para realizar una revisión habitual. La privacidad también forma parte del diseño: muestra solo los datos necesarios para la tarea y controla el acceso según las responsabilidades del equipo.
Estados y acciones que expresan decisiones distintas
Los estados describen dónde está el caso; las acciones registran lo que alguien hizo. No los confundas. Un estado como “pendiente” no explica si el caso espera una persona, información externa o una revisión posterior. Define estados que indiquen una condición operativa y que tengan una transición válida.
Un flujo sencillo puede distinguir casos nuevos, en revisión, a la espera de información, escalados y resueltos. No todas las organizaciones necesitan los mismos nombres, pero cada estado debe responder a dos preguntas: quién tiene que actuar ahora y qué condición permite avanzar.
Separa también las acciones de revisar, corregir, aprobar y devolver. La interfaz debe explicar el efecto de cada una. Corregir puede modificar un dato; aprobar puede autorizar la continuación; devolver puede pedir información o enviar el caso a otro equipo. Si una acción es irreversible o tiene consecuencias relevantes, solicita una confirmación proporcionada y presenta el destino del caso.
Evita botones ambiguos como “Listo” si no aclaran qué se completó. Después de una acción, confirma el resultado y actualiza el estado visible. Si la operación falla, conserva el trabajo realizado y comunica cómo continuar, en vez de dejar a la persona sin saber si el cambio se guardó.
Asignación, prioridad y vencimientos sin casos olvidados
La bandeja necesita una regla de propiedad. Puede asignar casos a una persona, a un equipo o a una cola compartida, pero debe quedar claro quién es responsable del siguiente paso. En una cola compartida, define cómo se reclama un caso y qué ocurre si otra persona ya lo está atendiendo. Así reduces duplicados y decisiones simultáneas.
La prioridad debe corresponder a criterios observables, como el impacto operativo o un plazo real. No la uses como sustituto de una política de capacidad. Si todo aparece como urgente, deja de ayudar a decidir. Los vencimientos deben tener un significado acordado: indicar una fecha de seguimiento, activar una escalada o señalar un compromiso. Muestra cuál de esas consecuencias aplica.
- Define qué eventos asignan, liberan o reasignan un caso.
- Haz visibles el responsable actual y el tiempo o condición de espera.
- Prevé qué hacer ante ausencias, cambios de turno o falta de capacidad.
- Establece una vía para detectar casos sin propietario y duplicados.
Registro de decisiones, escalado y cierre
La trazabilidad debe explicar qué se decidió, quién lo hizo, cuándo y con qué información relevante. Registra la acción y los cambios de datos necesarios para reconstruir el recorrido; no dependas únicamente de comentarios libres. Un comentario puede aportar contexto, pero no debería sustituir un motivo estructurado cuando el proceso necesita clasificar decisiones.
Si la persona no puede resolver el caso, ofrece una ruta de escalado con destino y motivo claros. Escalar no debe equivaler a abandonar la responsabilidad: el sistema debe indicar quién recibe el caso y mantener visible su estado. Si falta información, registra qué se solicitó y a quién corresponde el siguiente paso.
Define el cierre como una condición verificable, no como un botón aislado. Un caso podría cerrarse cuando la decisión se registra y el proceso automatizado recibe el resultado, o cuando se documenta que no puede continuar. Si el sistema no puede confirmar que la automatización retomó el trabajo, presenta esa situación como pendiente de confirmación en vez de mostrar un éxito supuesto.
Indicadores para encontrar fricción en la revisión
El volumen de casos por sí solo no permite saber si la bandeja funciona bien. Combínalo con señales que expliquen la carga y la calidad del flujo: cuánto tiempo permanecen los casos en cada estado, cuántas veces se reasignan, con qué frecuencia se devuelven y qué proporción se resuelve en la primera revisión.
Interpreta esos datos junto con el motivo de entrada. Una espera prolongada puede deberse a falta de capacidad, información incompleta o una dependencia externa. Muchas correcciones repetidas pueden señalar que la automatización captura mal un dato o que las instrucciones no son claras. Las métricas deben orientar una investigación, no atribuir automáticamente el problema a quien revisa.
Lista de comprobación antes de ponerla en uso
Valida la bandeja con personas que realizan el trabajo y con escenarios representativos, incluidos los que no se resuelven a la primera. Comprueba si pueden explicar por qué apareció el caso, elegir la acción adecuada y anticipar qué ocurrirá tras ejecutarla.
- ¿Cada motivo de excepción tiene una respuesta y una condición de cierre?
- ¿El contexto permite decidir sin buscar información innecesaria en otros sistemas?
- ¿Los estados identifican quién debe actuar y qué falta?
- ¿Las acciones distinguen revisar, corregir, aprobar y devolver?
- ¿La asignación evita casos sin responsable y trabajo duplicado?
- ¿Se conserva un registro útil de decisiones y cambios?
- ¿El escalado y la espera de información tienen responsables visibles?
- ¿Las métricas permiten localizar fricción sin reducir la evaluación al volumen?
Una bandeja eficaz hace legible el trabajo que la automatización no pudo completar. Si cada caso explica su motivo, ofrece una acción adecuada y conserva el resultado de la decisión, la intervención humana deja de ser una interrupción opaca y pasa a formar parte del proceso.