RPA para call centers: qué automatiza y dónde falla

Qué es realmente el RPA de call center

He pasado los últimos años construyendo agentes de IA que operan sobre colas de soporte en vivo, y lo primero que diré es que el RPA se ganó su reputación de forma honesta. Hace algo real.

La automatización robótica de procesos es, en palabras de los propios proveedores, robots de software que imitan acciones humanas en sistemas digitales para realizar "tareas repetitivas y basadas en reglas como introducir datos, mover archivos o procesar transacciones". El bot literalmente hace lo que haría un agente con un ratón y un teclado, haciendo clic en las mismas pantallas, pero más rápido y sin aburrirse. Automation Anywhere lo plantea de la misma manera: el RPA es los "brazos y piernas" de la automatización, la ejecución fiable de pasos estructurados y repetibles.

La razón por la que encaja en un call center es que una gran parte del trabajo de un contact center realmente es codificable y repetitivo. Cuando un jefe de turno pasa la mañana copiando campos de tickets en una herramienta de facturación, eso es una regla que se puede escribir, y cualquier cosa que se pueda escribir como regla, un bot la puede ejecutar.

Hay dos variantes que vale la pena conocer, porque corresponden a trabajos distintos en el día a día:

• El RPA desatendido funciona por su cuenta, con un horario o un disparador, sin que nadie lo supervise. Automation Anywhere lo orienta hacia procesos de back-office como la entrada masiva de datos y las integraciones de sistemas. Piensa en trabajo por lotes durante la noche.
• El RPA asistido acompaña a un agente en vivo, entrando en acción a mitad de llamada para rellenar un formulario o extraer un registro. El proveedor nombra explícitamente esta categoría para el trabajo de servicio al cliente y helpdesk de TI, con un humano en el proceso. Este es el clásico bot de "escritorio del agente".

Ninguno de los dos entiende nada. Eso no es una crítica, es el diseño. El RPA es determinista por naturaleza, precisamente por eso es fiable y auditable, y precisamente por eso se derrumba en el momento en que el trabajo deja de ser determinista.

Lo que el RPA de call center automatiza bien

Aquí es donde el RPA realmente demuestra su valor. La mayoría son tareas poco glamurosas que se comen silenciosamente el día de un agente, y delegarlas en un bot es una victoria real.

Automation Anywhere enumera exactamente esto en sus casos de uso de servicio al cliente: gestión automatizada de consultas, tickets y enrutamiento, y entrada de datos de incorporación. Y los resultados, cuando el proceso es estable, son reales. Su caso de estudio de la ciudad de Seattle es concreto y bueno: la ciudad eliminó un atraso de más de 6.000 solicitudes de programas de servicios públicos, automatizó 700 solicitudes diarias de desbloqueo de contraseñas y ahorró más de 30 horas al mes, todo con RPA basado en reglas antes de añadir siquiera una capa de IA.

Si tu call center tiene un montón de estas tareas repetitivas de back-office, el RPA es una respuesta legítima, y encaja junto al resto de tu flujo de trabajo de servicio al cliente sin mucho drama. Esta es la parte de la historia que los proveedores de RPA cuentan bien, y no se equivocan.

Dónde falla el RPA de call center

Ahora la parte que el folleto se salta. Todo el modelo del RPA, un bot que finge ser un humano haciendo clic en una pantalla, es también su línea de fractura. He visto a equipos intentar que cargue con la cola de soporte real, y tiende a romperse de tres maneras predecibles.

Es frágil. El bot apunta a botones y campos específicos de una página. Cambia el diseño, renombra un campo o lanza una actualización de la interfaz, y la automatización se rompe. Los profesionales en r/rpa lo dicen sin rodeos:

"UI automation is brittle, so we built an AI-based solution... that makes UI-based automation on websites extremely easy."

r/rpa, on constant UI changes breaking automations

El mantenimiento te devora vivo. Cada bot frágil es un bot que alguien tiene que cuidar. Esta es la factura oculta, y los números lo confirman: en la encuesta global de Deloitte, solo las organizaciones con 51 o más automatizaciones en producción cuentan como "escaladoras", y la mayoría de los programas se quedan muy por debajo de eso. Un tercio de los equipos que usan automatización como servicio subcontratan específicamente la gestión y el mantenimiento de sus bots, porque mantenerlos vivos es un trabajo en sí mismo. Como dijo un hilo de r/automation, sin una ingeniería seria detrás, "la carga de mantenimiento te devorará vivo a medio y largo plazo".

No puede manejar el lenguaje, las excepciones ni el criterio. Este es el gran problema para un call center, porque eso es el trabajo real. En el momento en que un cliente reformula una pregunta, adjunta un documento inesperado o se topa con un caso límite sin regla, el bot no tiene nada que hacer. Incluso los propios proveedores de RPA lo admiten: sin IA, el RPA "solo puede operar eficazmente con datos estructurados... esto limita la eficacia del RPA y devuelve más excepciones a los trabajadores humanos". El consenso de la comunidad es el mismo, y sorprendentemente justo al respecto:

"RPA thrives in rules based end to end process so it's more reliable for structured tasks, while agents thrive on processes having lots of nuances... Not everything needs an LLM to perform rules based decisions."

r/rpa, "RPA vs AI agents vs Agentic Process Automation"

Esa última cita es el planteamiento honesto. El RPA no es malo, es limitado. Y una cola de soporte es en su mayoría el material matizado y conversacional que vive fuera de su carril, por lo que añadir más RPA a los tickets rara vez mueve la aguja en la automatización de tickets.

RPA frente a agentes de IA: quién hace qué

La versión inútil de este debate es "RPA contra IA, quién gana". La versión útil es: hacen trabajos diferentes, y las buenas configuraciones usan ambos. Así es como yo trazaría la división del trabajo.

El agente de IA lee el mensaje entrante, averigua qué quiere realmente el cliente y decide el siguiente paso. El bot de RPA, si todavía se necesita uno, hace la ejecución determinista: iniciar sesión en el ERP, mover los datos, seguir las reglas fijas. El humano gestiona las excepciones genuinas y vigila el conjunto. UiPath describe la misma división: los agentes analizan y deciden, el RPA actúa de forma fiable sobre esas decisiones, y las personas proporcionan supervisión.

Por eso el planteamiento ha cambiado silenciosamente de "¿reemplazará la IA al RPA?" a "IA arriba, RPA abajo", y por eso los números del coste de IA frente a humano favorecen cada vez más colocar al agente en la conversación. La categoría creció en tres pasos.

Primero llegó la simple automatización de tareas (el RPA de los años 2010 que todos imaginan). Luego la automatización inteligente, que combinó el RPA con aprendizaje automático y modelos de lenguaje para poder leer datos no estructurados como correos electrónicos y documentos. Ahora la IA agéntica, donde el agente se encarga de entender y decidir, y el RPA se convierte en la capa de ejecución a la que recurre. Gartner registró un aumento del 750% en las consultas de clientes sobre automatización agéntica solo en la segunda mitad de 2024, lo que indica hacia dónde se dirige la demanda.

Para un líder de soporte, la lectura práctica es sencilla. Si estás decidiendo cómo automatizar una tarea determinada, pregúntate qué tipo de tarea es. Usa la herramienta de abajo para comprobarlo.

Dónde encaja eesel

Este es el nivel en el que realmente trabajo: el conversacional, para el que el RPA nunca fue construido. eesel AI es un agente de IA para el helpdesk que lee el ticket o chat entrante, extrae la respuesta de tu propio conocimiento y lo resuelve, o redacta una respuesta para que un agente la envíe. Es la mitad de "la IA decide" del panorama, y como pieza de IA en el servicio al cliente, se integra en el helpdesk que ya usas en lugar de pedirte que reconstruyas nada.

Hay algunas cosas que hacen esto diferente de apuntar el RPA hacia tus tickets:

• Se entrena con tu propio historial. eesel aprende de tus tickets pasados, tu centro de ayuda y tus macros, así que responde con tu propia voz desde el primer día en lugar de necesitar una regla escrita para cada escenario. Eso es lo opuesto a la cinta de correr del mantenimiento en la que te meten los scripts de RPA.
• Puedes simularlo antes de que entre en producción. Esto viene de una cicatriz. Hemos visto bots que suenan seguros de sí mismos dar respuestas incorrectas en silencio, así que eesel ejecuta una simulación contra tus tickets históricos y te muestra la tasa de resolución y las respuestas exactas antes de que toque a un cliente real. Ves cómo se comportará, y luego lo activas.
• Sabe cuándo detenerse. Lo que más nos dicen los compradores que quieren no es la automatización total, sino el control. Como nos dijo un responsable de soporte de una marca DTC: "Necesito una IA que solo maneje los tickets en los que tiene confianza, y que deje todos los demás en paz". eesel hace escalado y traspaso basado en la confianza, así que resuelve lo que tiene claro y pasa el resto de forma limpia.

Cuando el proceso realmente es determinista, eesel tampoco lo evita: dispara el mismo tipo de acciones que haría el RPA (etiquetar, asignar, actualizar el estado, llamar a una API) como parte de la resolución de un ticket. El equipo de Gridwise, que funciona sobre Zendesk, vio cómo eesel resolvía el 73% de sus solicitudes de nivel 1 en el primer mes, y señaló que la plataforma "incluso incluye automatizaciones para el etiquetado de tickets, la asignación y las actualizaciones de estado". Esa es toda la idea: IA en la conversación, acciones deterministas en la ejecución.

También responde a la pregunta de "por qué no construirlo nosotros mismos" que se hacen muchos call centers con mucho peso en ingeniería. El equipo de GENERAL BYTES resumió por qué compraron en lugar de construir: "Podríamos intentar escribir nuestra propia aplicación de LLM, pero no queríamos invertir nuestro tiempo en eso. Queríamos algo que no tuviéramos que mantener". Ese punto del mantenimiento es la misma razón por la que los scripts de RPA se vuelven caros, solo que un nivel más arriba.

Cómo empezar de verdad

Si estás valorando el RPA de call center ahora mismo, esta es la secuencia que yo seguiría en lugar de automatizar todo de golpe.

1. Enumera tus tareas y clasifícalas. Divide la cola en trabajo de back-office determinista (entrada de datos, extracción de informes, actualizaciones de estado) y trabajo conversacional (cualquier cosa donde un humano lea e interprete). El primer grupo es donde pertenece la automatización basada en reglas; el segundo es un trabajo para el software de servicio al cliente con IA.
2. Automatiza lo estable y aburrido con reglas. Para procesos verdaderamente fijos, un bot basado en reglas o la automatización de flujos de trabajo integrada en tu helpdesk está bien, y es más barata que un agente de IA. Solo entra sabiendo que tendrás que mantenerlo cuando las pantallas cambien.
3. Pon un agente de IA en la conversación. Para los tickets y chats que necesitan comprensión, usa un sistema de tickets con IA que lea la intención y resuelva. Este es el nivel que realmente mueve tus números de resolución y de desviación de nivel 1, y donde aparece el verdadero ahorro en costes de soporte.
4. Simula y luego despliega gradualmente. Haz pruebas contra tickets históricos reales antes de salir en vivo, empieza con la IA en los tipos de tickets en los que tiene más confianza, y amplía a partir de ahí. No cambies todo a automático el primer día.

El error que más veo es tratar esto como un único gran proyecto de automatización. No lo es. Son dos trabajos diferentes, y los equipos que ganan usan la herramienta adecuada para cada uno.

Prueba eesel para tu call center

Si tu cola es sobre todo el nivel conversacional, para eso está exactamente eesel AI. Es un agente de IA que se integra en tu helpdesk actual en minutos, aprende de tus tickets pasados y de tu base de conocimiento, y resuelve la primera línea mientras entrega el resto a tu equipo de forma limpia. La parte que suele convencer a la gente: puedes simularlo con tickets pasados y ver la tasa de resolución real antes de que un solo cliente hable con él, así que no hay que dar un salto de fe.

Es gratis de probar, y puedes apuntarlo a tu helpdesk sin reconstruir nada. Esa es toda la propuesta: mantén el RPA para la fontanería si ya lo tienes, y deja que un agente de IA se encargue de las conversaciones para las que nunca fue diseñado.