Task de aprobación de refund
El workflow de refund llega al umbral. Un task aterriza en la cola del supervisor con el caso, la recomendación del agente, la política aplicada. Dos clicks, el workflow resume.
Cada task es un checkpoint humano con contexto, evidencia y SLA. Un workflow pausa para un task cuando se requiere juicio; un humano lo trabaja; el workflow resume con la decisión registrada.
Un task no es una notificación. Es un contrato. Cuando un workflow llega a un momento que necesita juicio humano, crea un task — con la asignación, la cola, la prioridad, el SLA y la evidencia ya adjuntos. El trabajo no vive en la bandeja de alguien; vive en la capa cognitiva, esperando que un humano commita una decisión.
Los tasks se crean de tres formas. Los workflows pausan para ellos cuando se llega a un gate HITL. Los agentes escalan a ellos cuando algo no encaja en sus restricciones. Los operadores los crean manualmente desde Command Center cuando quieren rutear una pieza de juicio a un compañero.
Dónde los trabajan los humanos: dentro de las Apps Operacionales (el workspace para la decisión), despachados y rastreados desde Command Center (el cockpit), y encontrados a través de Omnisearch (la búsqueda cross-cutting). Cuando el humano commita, el task cierra; el workflow resume; la cadena de evidencia captura quién decidió, con qué contexto, aplicando qué regla.
El workflow de refund llega al umbral. Un task aterriza en la cola del supervisor con el caso, la recomendación del agente, la política aplicada. Dos clicks, el workflow resume.
Un agente extrae campos de una factura; abre un task para que un humano verifique desviaciones de las cláusulas estándar. El revisor se enfoca en juicio; el data entry ya está hecho.
Un workflow encuentra un caso inesperado. Un task aterriza en la cola del equipo correcto con el contexto completo, el input original y la regla que lo marcó. El equipo decide; el workflow continúa.