La Diferencia entre Deflectar y Resolver
Un chatbot de deflexión ahorra minutos. Un agente autónomo elimina el caso. La diferencia se ve en el estado final del pedido, no en la transcripción de la conversación.
Cuando el cliente escribe "quiero cancelar mi pedido", el bot de deflexión responde con la política de cancelación y un enlace. El agente autónomo verifica que el pedido no haya salido, ejecuta la cancelación en el OMS, dispara la nota de crédito si el pago ya se capturó, confirma la ventana de reembolso y cierra el ticket con el número de transacción. El primero contesta. El segundo resuelve.
Esa distinción es la que decide si la automatización aparece como ahorro o como costo. McKinsey estima un aumento de productividad de 30% a 45% al aplicar IA generativa a atención al cliente (The economic potential of generative AI, 2023), pero ese rango se captura cuando el agente ejecuta la acción, no cuando solo redacta una respuesta más rápida.
Por Qué la Mayoría de los Agentes se Retira en Producción
El problema casi nunca es el modelo. Es el gobierno.
Sinch reporta que 74% de las empresas retiró un agente de IA de atención al cliente en producción, y en Latinoamérica la cifra llega a 82%, con un 41% de las fallas relacionadas con datos personales. Lo cubrimos en detalle en por qué se retiran los agentes de IA de atención al cliente: el agente que funciona en la demo falla cuando toca datos reales, cuando el cliente cambia una política o cuando alguien le pide algo que no estaba en el guion.
En un centro de contacto el riesgo se multiplica porque la operación trabaja para varias marcas a la vez. El mismo agente atiende tres políticas de devolución distintas, cuatro sistemas distintos y dos niveles de tolerancia al error. Un prompt gigante con todo mezclado no es un perímetro: es una bomba de tiempo.
Lo que se Puede Resolver Hoy sin Heroísmo
No hace falta automatizar la relación completa. Hay un conjunto de transacciones de alto volumen y bajo juicio que se resuelven con reglas claras y trazabilidad:
- Estado del pedido (WISMO): consultar el OMS y el transportista, dar la fecha real y, si hay retraso, reagendar o abrir la incidencia.
- Cambio de dirección antes del despacho: validar la ventana, actualizar el pedido, confirmar por el mismo canal.
- Cancelación dentro de la ventana: verificar estado, ejecutar, emitir crédito si aplica.
- Reembolso bajo umbral: procesar el abono y confirmar el plazo real, no el plazo del folleto.
- Reagendamiento de visita o instalación: consultar disponibilidad y mover la cita sin intervención.
- Reposición por daño o faltante: abrir el caso, pedir la evidencia mínima y disparar el reemplazo.
- Actualización de datos de cuenta: correo, teléfono, dirección, método de pago, con verificación de identidad.
- Desbloqueo y recuperación de acceso: con reglas de verificación y registro de cada intento.
Todo lo demás —negociación comercial, quejas formales, casos con riesgo regulatorio, clientes vulnerables, excepciones que un supervisor tendría que firmar— se queda en manos del humano. El agente puede preparar el caso, pero no decide.
El Perímetro de Escritura: la Pieza que Nadie Diseña
La conversación sobre agentes suele centrarse en el modelo y en el prompt. En una operación multi-cliente, la pieza que decide si el agente sobrevive es el perímetro de escritura.
Se define por cuenta y por herramienta: qué sistemas puede leer, en cuáles puede escribir, con qué límites de monto, qué campos están prohibidos y qué acciones requieren aprobación. Un agente de una marca de retail puede cancelar pedidos de hasta 150 dólares y emitir un crédito de hasta 50; el de una aseguradora puede consultar la póliza y agendar la inspección, pero no tocar el monto del siniestro. Esa configuración vive en el código y en la base de datos de la plataforma, no en el texto del prompt, y queda registrada con fecha y responsable.
Sobre ese perímetro se construyen las aprobaciones. Un reembolso por encima del umbral, una excepción de política o un caso marcado como vulnerable genera una tarea para un humano con la acción propuesta, el monto, la regla aplicable y el historial. El aprobador decide en segundos. La decisión queda registrada con su nombre.
Evaluación: Cómo se Sabe que el Agente Sigue Sirviendo
Un agente en producción cambia de comportamiento cuando cambia el modelo, el prompt, una herramienta o la política del cliente. Sin un arnés de evaluación, ese cambio se descubre en la queja del cliente.
Nosotros trabajamos con tres capas:
Modo sombra. El agente corre en paralelo durante dos a cuatro semanas y se compara su decisión contra la del humano en cientos de casos reales. No escribe nada en producción. Las diferencias se revisan una por una y se convierten en reglas o en casos de prueba.
Arnés de regresión. Un conjunto de casos pass/fail por cuenta y por tipo de tarea que corre antes de cada despliegue. Si un cambio de modelo rompe una cancelación que ya funcionaba, el despliegue se bloquea. La lógica es la misma que aplicamos a cualquier agente dentro del flujo: sin evaluación, no hay producción.
Canario por cuenta y por canal. La expansión es gradual: primero una cuenta, un canal, un tipo de tarea. Se mide tasa de resolución sin reapertura en siete días, acciones revertidas y escalaciones incorrectas. Solo cuando el desempeño se sostiene se amplía el perímetro.
Qué Medimos
- Tasa de resolución sin reapertura en siete días, por tipo de tarea y por cuenta. Es la métrica principal; todo lo demás la explica.
- Acciones revertidas o corregidas por un humano, con motivo. Un agente que resuelve rápido pero se equivoca no es un ahorro.
- Escalaciones correctas e incorrectas: cuántas veces el agente debió escalar y no lo hizo, y cuántas escaló sin necesidad.
- Tiempo de ciclo del caso, desde el primer mensaje hasta el cierre, no solo el tiempo de la conversación.
- Costo por tarea resuelta, incluyendo tokens, herramientas, aprobaciones y reversiones.
- Adherencia al SLA por cuenta y por canal, con el reloj corriendo desde el primer contacto.
- Cobertura del perímetro: qué porcentaje del volumen cae dentro de las tareas habilitadas y qué porcentaje queda fuera por política.
Cómo lo Implementamos
Semana 1-2 — Extracción de políticas y mapa de sistemas. Revisamos los procedimientos de cada cuenta, los límites de aprobación y los sistemas donde vive la transacción. De ahí sale el perímetro de escritura y la lista de tareas habilitadas.
Semana 3-4 — Herramientas y ejecución. Construimos las herramientas acotadas contra OMS, pasarela, facturación, CRM y ticketing. Cada herramienta tiene validación de entrada, límite de monto y registro de ejecución.
Semana 5-6 — Modo sombra y arnés de evaluación. El agente corre en paralelo, se compara contra el humano y se arma el set de regresión. Se definen las aprobaciones y el handoff con SLA.
Semana 7-8 — Canario y expansión. Una cuenta, un canal, dos o tres tipos de tarea. Medición diaria, revisión semanal y ampliación del perímetro solo con desempeño sostenido.
Semana 9 en adelante — Nuevas tareas por valor. Cada tarea nueva se prioriza por volumen, costo y riesgo. El agente crece por perímetro aprobado, no por promesa de plataforma.
Si la operación todavía no tiene la base —clasificación de intenciones, base de conocimiento por cuenta y traspaso con contexto—, el punto de partida es automatización y chatbots para BPO y centros de contacto. Automatizar la ejecución sin esa base es construir el techo antes de la pared.
Una Pregunta Antes de Invertir
Toma los últimos 1,000 tickets cerrados y sepáralos en dos montones: los que se resolvieron con una acción en un sistema —cancelar, abonar, cambiar, reagendar— y los que se resolvieron solo con información.
Si menos del 30% requirió una acción, un chatbot de deflexión bien hecho es suficiente y un agente autónomo es sobreingeniería. Si más del 50% requirió una acción, ahí está el dinero: cada una de esas acciones es un caso que hoy ocupa a un humano y que puede ejecutarse dentro de un perímetro aprobado, con bitácora y evaluación.
¿Cuántos de tus casos se resuelven con una acción y no con una explicación? Escríbenos con esa proporción y los tres tipos de tarea de mayor volumen, sin datos de clientes finales, y te decimos qué parte del perímetro conviene abrir primero.