Cuando el agente se equivoca: la situación, el problema y qué hacemos
Un caso hipotético, pero completamente habitual — y nuestra respuesta
Un caso hipotético, pero completamente habitual — y nuestra respuesta
La situación
Imaginemos una red de clínicas que puso a nuestro agente a cargo de reservar y confirmar citas. El agente trabaja en WhatsApp y por teléfono, ve la agenda, mueve huecos, cancela citas y devuelve anticipos.
Un viernes por la tarde, la administrativa que normalmente aprueba las devoluciones se marcha y apaga el teléfono. El sábado una paciente pide cancelar y que le devuelvan el dinero. El agente ve que la cancelación está permitida y que la devolución está «dentro de la autorización», y hace ambas cosas. El lunes se descubre que la administrativa había revocado los permisos de devolución el viernes — pero la revocación vivía en otro sistema y el agente no se enteró.
El dinero volvió a la paciente equivocada y por el importe equivocado. La clínica nos hace tres preguntas: quién lo autorizó, por qué el agente no se detuvo y qué podemos mostrar.
El problema
El problema no es que el modelo se equivocara. El problema es que el sistema no tenía respuesta a tres cosas a la vez.
Primera. La autorización vivía separada de la acción: el derecho a devolver se revocaba en un sitio y se ejercía en otro, sin nada que los conectara.
Segunda. Nadie había descrito qué ocurre cuando quien aprueba no está disponible. Por defecto, el sistema se comportó como «permitido» en lugar de «denegado».
Tercera. A la clínica le quedó un registro. Detallado, ordenado e inútil: no permitía saber con qué base se autorizó la acción ni si esa base era válida en ese segundo.
Esto no es exótico. Es el aspecto de casi cualquier revisión de un incidente con agentes: la autorización, la decisión y la ejecución viven en sitios distintos, y la evidencia se reúne después y no responde a la pregunta principal.
Cómo lo resolvemos
No prometemos que el agente nunca se equivoque. Construimos para que un error sea acotado, detenible y verificable.
Autorización con límites y caducidad. El agente actúa dentro de un mandato concedido: qué acciones, hasta qué importe, en qué canales, hasta cuándo. Devoluciones, firmas, publicación — fuera del mandato o mediante confirmación humana.
Una regla para cuando no hay nadie. Describimos de antemano qué está permitido sin el propietario y qué no. Denegado por defecto. Una revocación detiene la siguiente acción, no la siguiente conversación.
Un registro que responde «con qué base». Cada acción significativa deja un rastro: qué autorización, qué decisión, qué se envió, qué ocurrió realmente en el lado receptor — y, por separado, qué no medimos. Esto último importa: un registro que finge ser completo es peor que uno que marca sus lagunas.
Un análisis, no una excusa. Revisamos el incidente contra escenarios definidos de antemano — rechazo en el punto de decisión, evidencia obsoleta, autoridad inaccesible, revocación después del envío — y mostramos cuál se cumplió y cuál no.
El contrato. Qué cuenta como incidente, en cuántas horas lo comunicamos, quién responde de la reversión y con qué límites. Sin esto, los cuatro puntos anteriores son promesas.
Qué obtiene el cliente
En el mismo ejemplo: la devolución no pasa, porque el derecho fue revocado y la revocación se comprueba en el momento de la acción; si la administrativa no está, se aplica una frontera acordada de antemano en lugar de una suposición; y el lunes la clínica tiene, no un «log», sino un análisis — por qué el sistema actuó así, qué está probado y qué quedó fuera de medición.
Qué no hacemos
No vendemos un certificado de conformidad. No afirmamos haber probado que un agente sea seguro en general. No pretendemos probar por nuestra cuenta que el receptor ejecutó exactamente esa acción — parte de la garantía vive en quien ejecuta y en el destino, y lo decimos con claridad.
Si quiere, revisamos su caso: dónde está hoy la frontera de la autorización, qué ocurre si la persona responsable desaparece y cómo será el registro después de un incidente.