
Resumen
Elige un agente de IA para atención al cliente probándolo con tus propios tickets pasados, no con la demo del proveedor. Todas las demos lucen bien. Tu cola es donde se notan las diferencias. Las dos comprobaciones que más separan a las herramientas son cómo te dejan probar antes del lanzamiento y qué te facturan realmente.
Sobre la facturación: "resolución" significa algo distinto en casi todos los proveedores. Zendesk ahora cobra solo las resoluciones verificadas por IA, Gorgias cuenta cualquier cosa sin respuesta humana en 72 horas, Freshdesk factura una sesión se resuelva o no, y Ada, Decagon y Sierra no publican precio alguno. El precio por resolución parece el más barato en el piloto y se encarece a medida que el agente mejora.
Si quieres un agente que se conecte al helpdesk que ya usas y se demuestre primero, eesel reproduce cientos de tus tickets pasados y puntúa cada respuesta frente a lo que tu equipo envió realmente, y luego factura un plan fijo por ticket gestionado. Puedes probarlo gratis con 100 créditos.
Por qué la demo es el peor lugar para juzgar un agente de IA de soporte
Trabajo en la cola de soporte de eesel todos los días, y lo que he aprendido viendo cómo los equipos evalúan agentes de IA es que la demo casi nunca predice lo que pasará con tus tickets. La demo funciona con preguntas ordenadas que eligió el proveedor. Tu cola tiene el correo a medio escribir, el cliente que pregunta tres cosas a la vez y la política que cambió el martes pasado.
Un ejemplo real: cuando eesel probó su agente en una tienda online de joyería con unos 1.000 tickets al mes, las cifras principales parecían excelentes: 93 % de precisión en la clasificación y 88 % de borradores en la dirección correcta. Pero los agentes enviaron sin cambios solo el 12 % de los borradores. Alrededor del 65 % de sus reescrituras fueron por longitud y tono, no por hechos, y solo cerca del 5 % era la IA equivocándose claramente. Una sola cifra de "precisión" habría ocultado todos esos hallazgos.

Esa brecha es la razón por la que las métricas de soporte con IA importan más que la presentación comercial. Un profesional con diez años en IA para contact centers expresó con franqueza la línea de base honesta:
"El problema es que los proveedores les dicen a las empresas que pueden eliminar el 80-90 % (quizá incluso el 100 % si logran mantener la cara seria) de los puestos de agentes de atención al cliente con IA, y eso es una tontería."
La línea de base aproximada del mismo comentarista era que cerca del 30 % de los contactos entrantes se desvían. Tu cifra puede ser mucho mayor, y muchos equipos la superan, pero solo lo sabrás probando con tu cola. Por eso las siete comprobaciones siguientes giran en torno a una idea: que cada proveedor lo demuestre con tus tickets antes de firmar.
Paso 1: Escribe un briefing de un párrafo antes de cualquier demo
Antes de reservar una sola llamada, anota qué significa "bueno" para ti. No "automatizar el soporte", sino un objetivo y una regla de traspaso. Un responsable de soporte en una llamada de ventas con eesel resumió su briefing en una frase: quería algo que pudiera "gestionar el 60 % de los tickets entrantes de zendesk y supiera cuándo pasar a una persona real para un mejor análisis y resolución".
Es un briefing estupendo, porque tiene las dos mitades que toda evaluación necesita. Un objetivo de cobertura te dice qué medir. Una regla de traspaso te dice cómo es el fracaso. Otro responsable de CX con 7.000 tickets al mes le dijo a eesel que la segunda mitad importaba más que la primera:
"Necesito una IA que gestione solo los tickets que está segura de poder gestionar y que deje en paz todos los demás."
Tu briefing debería responder:
- Qué temas debe asumir el agente. El estado de pedidos, los restablecimientos de contraseña y las dudas de facturación suelen ir primero. Saca un mes de tickets y etiqueta las preguntas repetidas; mi guía de clasificación de tickets muestra cómo.
- Qué canales: ¿correo, chat, redes sociales, voz?
- Qué puede hacer, no solo decir: ¿consultar pedidos, emitir reembolsos, cambiar direcciones?
- Cuándo debe parar y pasar a una persona, y qué debe recibir esa persona.
- Cuánto pagarás al mes, en el peor caso, en tu temporada más fuerte.
Lleva este briefing a cada demo y haz que el proveedor lo responda en tus términos. También evita que la conversación se desvíe hacia funciones que nunca usarás.
Paso 2: Decide dónde debe vivir el agente
La primera bifurcación es si compras el agente de IA que tu helpdesk ya vende, una plataforma independiente o una capa que se conecta al helpdesk que tienes. Esta decisión fija en silencio tu techo en todo lo demás: de qué aprende el agente, cómo lo pruebas y si puedes irte.
| Opción | Ejemplos | Dónde vive | ¿Aprende de tickets pasados? | Configuración |
|---|---|---|---|---|
| Integrado en tu helpdesk | Zendesk AI agents, Gorgias AI Agent, Freddy AI | Solo en ese helpdesk | No, sobre todo centro de ayuda y documentos | Autoservicio, en el panel de administración del helpdesk |
| Plataforma empresarial independiente | Ada, Decagon, Sierra | Delante de tu helpdesk, traspasa a él | En parte, las conversaciones pasadas sirven para pruebas o borradores de artículos | Liderada por el proveedor, primero demo |
| Capa sobre tu helpdesk actual | eesel | Dentro de Zendesk, Freshdesk, Gorgias, Front, HubSpot y más | Sí, con una conexión completa | Autoservicio |
Los agentes integrados son el camino de menor resistencia, y eso es una fortaleza real. Si vives en Gorgias y vendes en Shopify, el Gorgias AI Agent puede cancelar pedidos, editar direcciones de envío y reenviar sin ninguna configuración adicional. La contrapartida es que solo funciona allí: la documentación de Gorgias dice que "puede usarse con tiendas Shopify conectadas a Gorgias", y una reseña de Capterra que lo valoró con 5/5 aun así señaló que "ofrece funcionalidad completa solo para Shopify" (Frank A., Capterra).
Las plataformas independientes como en Decagon vs Sierra encajan con equipos grandes que quieren que un equipo del proveedor construya con ellos. La propia página de producto de Sierra vende trabajar con "un equipo experto de desarrollo de agentes" y dice "Despliega en semanas" (Sierra). Encaja bien a escala empresarial y supone mucho proceso si tienes tres agentes y una cuenta de Zendesk.
Un dato más antes de elegir por defecto la opción integrada. Un responsable de CX de una plataforma sanitaria de EE. UU. llegó a eesel tras probar la IA integrada de Zendesk y decidir que era demasiado cara para lo que le aportaba. Es un solo equipo, y muchos otros están contentos con ella, pero por eso yo sometería al agente integrado a las mismas pruebas que a los demás en lugar de tratarlo como la opción segura por defecto. Mis comparativas de alternativas a Zendesk AI y alternativas a Freddy profundizan más.
Paso 3: Comprueba de qué aprende
Un agente de IA es tan bueno como lo que lee. La mayoría aprende de tu centro de ayuda, un rastreo del sitio web y archivos subidos. Muchos menos aprenden de lo que realmente codifica cómo responde tu equipo: tus tickets resueltos.
Esa diferencia se ve en la documentación. Gorgias responde directamente en sus preguntas frecuentes: "¿AI Agent usa mis macros? No" (Gorgias). La página de fuentes de conocimiento de Zendesk enumera centros de ayuda y fuentes externas, pero no tickets pasados (Zendesk). Freddy de Freshdesk aprende de "URL, archivos, artículos de soluciones, preguntas y respuestas personalizadas y aplicaciones externas" (Freshdesk), y los tickets resueltos solo aparecen como entradas de prueba.
Por qué importa: ¿recuerdas aquella prueba en la que el 65 % de las ediciones eran de tono y longitud? Eso es justo lo que arregla un agente que lee las respuestas enviadas por tu equipo. Amogh, cofundador de eesel, lo oye en casi todas las llamadas de ventas:
"Además: el entrenamiento con tickets pasados ataca de nuevo. Un clásico. La gente quiere de verdad, de verdad, de verdad entrenar con tickets pasados."
Sea lo que sea lo que lea el agente, el contenido tiene que estar al día. Este comentario de Reddit es la advertencia más clara que he visto:
"He visto a un bot dar respuestas erróneas con total seguridad porque la base de conocimiento llevaba 8 meses sin actualizarse. Los clientes no solo recibieron malas respuestas. Las recibieron al instante."
Pregunta a cada proveedor dos cosas: ¿puede leer nuestros tickets pasados y macros?, y ¿puede leer los documentos internos donde viven nuestras políticas reales (Confluence, Notion, Google Docs)? Luego audita la base de conocimiento antes de la prueba, no después. Los artículos obsoletos son la causa más común de alucinaciones de IA que veo.
Paso 4: Pruébalo con tus propios tickets pasados
Esta es la comprobación que más separa a las herramientas y la que la mayoría de los compradores se salta. Todos los proveedores te dejan probar antes de salir en vivo, pero "probar" significa tres cosas muy distintas.

El problema de las preguntas que escribes tú es que solo prueban lo que se te ocurrió. El problema de los clientes simulados es que una IA inventa al cliente, así que la prueba es tan realista como el generador. Reproducir tus tickets reales es el único método en el que la "respuesta correcta" es algo que tu equipo ya envió.
Así describe cada proveedor las pruebas en su propia documentación:
| Proveedor | Cómo pruebas antes del lanzamiento | Puntuado frente a |
|---|---|---|
| Zendesk | Chat de vista previa, más un simulador de conversaciones (acceso anticipado, solo mensajería) que ejecuta escenarios que tú escribes con datos ficticios | Su propia estimación de la tasa de resolución |
| Gorgias | Chat de vista previa en el playground; puedes volver a ejecutar un ticket existente cada vez | Tu criterio, por conversación |
| Freshdesk Freddy | Hasta 100 consultas escritas o generadas por IA por ejecución en el chat; en correo, importa hasta 50 tickets resueltos por ejecución | Respondida, sin respuesta o error |
| Ada | Casos de prueba escritos, hasta 3.000 simulaciones al día | Aprobado o suspendido por prueba |
| Decagon | Clientes ficticios generados por IA, que pueden alimentarse con transcripciones subidas | Aprobado o suspendido por prueba |
| Sierra | Usuarios ficticios generados por IA, calificados por una segunda IA | Juez de IA |
| eesel | Reproduce tus tickets resueltos por lotes | Lo que tu equipo respondió realmente |

El simulador de Zendesk es un buen ejemplo del enfoque de escenarios escritos. Su artículo de ayuda dice que "genera conversaciones realistas basadas en los escenarios que creas" y añade que está "diseñado para pruebas con datos ficticios" (Zendesk). Es útil para pruebas de regresión de un flujo, pero la tasa de resolución que estima sale de escenarios que tú imaginaste.

La prueba masiva de Freddy es rápida de ejecutar, y la opción del agente de correo de importar tickets resueltos te acerca más a la realidad. El problema es la puntuación: cada consulta vuelve como "Answered", "Unanswered" o "Error" (Freshdesk). Un ticket respondido aún puede estar mal.
Otra trampa a vigilar: algunas pruebas ejecutan acciones reales. La documentación de Ada dice que en las simulaciones las "acciones no se simulan" y "se ejecutan contra sistemas en vivo" (Ada), y Gorgias advierte que una acción de prueba "puede afectar a datos reales de clientes y pedidos (como cancelar un pedido)" (Gorgias). Usa un perfil de cliente falso antes de activar acciones en una prueba.
Cómo se ve la reproducción de tickets pasados
Este es el método que presionaría a todos los proveedores para que admitan, así que aquí está cómo se ve en eesel. Le pides al agente una simulación en el chat, recupera tus tickets resueltos y los recorre por lotes, y luego te dice cuántas respuestas coincidieron con lo que tu equipo envió realmente, tema por tema (documentación de eesel).

En el ejemplo de la documentación, coincidieron 17 de 20 tickets. Lo más útil es el hallazgo de fondo: los borradores eran correctos, pero la mitad de los tickets coincidentes aún necesitaban que una persona ejecutara una acción en el backend que nadie había conectado todavía. Es una conclusión de compra que nunca obtendrías de una demo.

Elijas la herramienta que elijas, puntúa al menos cuatro cosas en la prueba: precisión de la clasificación, borradores enviados sin cambios, errores factuales y escaladas correctas. Mide también los tiempos de respuesta. Un comprador con quien habló eesel hizo una evaluación metódica de 67 pruebas, encontró las respuestas sólidas y aun así se marchó porque el widget de chat era lento y se quedaba atascado.
Paso 5: Lee la unidad de facturación antes de enamorarte
Aquí es donde veo más arrepentimiento. Los equipos eligen el agente que más les gustó y luego descubren qué significa "resolución" en su primera factura.

Esto es lo que factura realmente cada proveedor, con sus propias palabras:
| Proveedor | Unidad facturable | La definición | Precio de lista | ¿Se factura si no se resuelve? |
|---|---|---|---|---|
| Zendesk | Resolución automatizada verificada | Un LLM "evalúa el texto de la conversación para confirmar que la solicitud del cliente se resolvió satisfactoriamente" | 1,50 $ comprometido, 2,00 $ pago por uso (precios), tras una asignación por agente | No |
| Gorgias | Interacción automatizada, más la tarifa por ticket | El cliente "no requiere la intervención de un agente humano en 72 horas" | De 0,85 a 1,00 $ cada una según el plan | Tarifa por ticket sí, tarifa de automatización no |
| Freshdesk | Sesión | Chat: todo en 24 horas. Correo: una ventana de 72 horas | 49 $ por 100 sesiones, 500 gratis una vez | Sí |
| Ada | No publicado | Ada defiende el precio por conversación "independientemente del resultado" | Solo demo | No está claro |
| Decagon | Por conversación (la mayoría de clientes) o por resolución | "Una tarifa fija por cada conversación entrante" | Solo demo | Sí, en el modelo por conversación |
| Sierra | Resultado acordado | "Si la conversación queda sin resolver, en la mayoría de los casos no hay cargo" | Solo demo | Casi nunca |
| eesel | Ticket o chat gestionado | "Un ticket o chat es 1 crédito, sea cual sea su duración" | 299 $/mes por 500, hasta 1.749 $ por 5.000 | Sí, pero el spam y los tickets omitidos no cuentan |
Hay que reconocer el mérito: Zendesk cambió su modelo el 18 de mayo de 2026. Con los niveles de resolución, "Assisted escalation" y "Contained resolution" no cuentan contra tu asignación, y una resolución solo llega al nivel "Verified" tras una comprobación de un LLM. Eso responde a la queja que los usuarios de Zendesk plantearon cuando se lanzó la facturación por resolución:
"Una basura total jaja, cosas que antes eran gratis ahora cuentan como una AR. La mayoría de las AR son chats abandonados. No hay proceso de disputa."
Ese comentario es de 2024, y las cuentas antiguas aún pueden estar en el esquema anterior hasta que se migren, así que comprueba en cuál estás. Incluso los proveedores que venden precio por resolución admiten que la definición es resbaladiza. El director de producto de Decagon escribió: "Nunca quieres encontrarte discutiendo qué es una 'resolución'" (Decagon).
El problema mayor es cómo escala cada modelo. Juega con la calculadora de abajo: ajusta el volumen a tu cola y luego sube la tasa de resolución.
Con 2.000 conversaciones gestionadas por IA al mes, el panorama se invierte a medida que el agente mejora:
| Tasa de resolución | Zendesk (1,50 $/res.) | Gorgias (0,90 $/interacción) | Freshdesk (0,49 $/sesión) | eesel (plan de 2.000 créditos) |
|---|---|---|---|---|
| 20 % (piloto inicial) | 600 $ | 360 $ | 980 $ | 849 $ |
| 50 % | 1.500 $ | 900 $ | 980 $ | 849 $ |
| 70 % (maduro) | 2.100 $ | 1.260 $ | 980 $ | 849 $ |
El modelo de pago por resolución es la opción más barata justo cuando el agente es peor. Eso no es motivo para descartar esas herramientas, porque también pagas por un agente que funcione. Es un motivo para modelar tu mes pico antes de firmar y para preguntar si el recuento de resoluciones del proveedor incluye spam y chats abandonados. Para más sobre las cuentas, consulta mi desglose del coste por resolución y las guías de precios de Zendesk AI y precios de Freddy AI.
Un reseñador de Gorgias en G2 nombró directamente el problema de la temporada alta:
"A medida que crece nuestro volumen de pedidos y aumentan las consultas de clientes, el coste sube rápidamente de formas difíciles de prever y presupuestar. En temporadas altas como las fiestas, cuando se dispara el volumen de soporte, los costes pueden aumentar mucho en poco tiempo."
Paso 6: Comprueba qué puede hacer y qué lo frena
Responder preguntas es la mitad del trabajo. La otra mitad es hacer cosas: consultar un pedido, reembolsar un artículo, actualizar un campo del ticket. Y para cada acción que pueda ejecutar, quieres un freno equivalente.
Sobre las acciones, comprueba tres cosas para cada proveedor:
- ¿Funciona en tu entorno, de serie? Las acciones de Shopify de Gorgias no necesitan pasos extra si Shopify ya está conectado. Las consultas de pedidos y reembolsos de Zendesk implican construir una integración de API o un flujo de acciones contra tu propio sistema (Zendesk).
- ¿Está restringido? Ada te limita por defecto a "cinco herramientas de API activas de cara al cliente por AI Agent" y señala que la función "puede no estar incluida en el paquete de suscripción de tu organización" (Ada).
- ¿Quién lo construye? Sierra dice que los flujos de trabajo e integraciones complejos "siguen requiriendo código" (Sierra). Bien si te sobran ingenieros, un obstáculo si no.
La prueba es simple: en el piloto, haz que ejecute la acción sobre un pedido de prueba y comprueba el resultado en el sistema de origen, no solo la respuesta. Un desarrollador en Reddit describió un agente cuyas "respuestas de texto parecían perfectas" mientras extraía datos de la cuenta del usuario equivocado (u/properwomanhood_292, Reddit).
Sobre las salvaguardas, busca tres cosas. Primero, la aprobación por acción: eesel te deja configurar cada acción para que se ejecute sola, pregunte antes o permanezca desactivada, y su documentación recomienda mantener "los reembolsos, las cancelaciones y todo lo que cuesta dinero tras una aprobación" (documentación de eesel). Segundo, el control por tema: la página de cobertura de IA de Gorgias te permite poner cada intención en "AI allowed" o "Handover" (Gorgias). Tercero, un traspaso a una persona que transmita contexto, no un volcado de transcripción.
Lo último importa más de lo que parece:
"se arregló forzando un resumen estructurado del traspaso en lugar de un volcado de transcripción en bruto (ahorró más tiempo que la propia automatización). CSAT bien en lo desviado, se desplomó en todo lo que rebotaba tras un intento fallido del bot"

Comprueba también los disparadores de escalada con tus propios tickets. Una responsable de soporte en Reddit dijo que sus primeras reglas, "escalar si es de facturación o si usan ciertas palabras clave", pasaron por alto "como la mitad de las situaciones en las que realmente hacía falta una persona" (u/Salt-Question8632, Reddit). Mi guía de disparadores de escalada cubre los patrones que funcionan.
Paso 7: Despliega por fases y elige una herramienta que lo permita
La última comprobación trata del despliegue, no del producto, pero debería influir en qué producto compras. Quieres una herramienta que pueda empezar supervisada y ganarse la autonomía, un tema a la vez.

La lectura de Amogh en las llamadas de ventas es que primero copiloto y luego IA completa es el patrón que casi todos quieren: empezar en modo de borrador de respuestas y pasar a automático total cuando confías. Una responsable de soporte en Reddit describió lo mismo desde el lado del operador:
"El despliegue más seguro que he visto es: que el agente redacte, etiquete confianza más motivo, exija aprobación para reembolsos o cambios de cuenta y revise cada conversación reabierta durante el primer mes. Ese registro de revisión suele ser donde aparece el verdadero límite de la automatización."
Así que pregunta a cada proveedor: ¿puede publicar borradores como notas internas para que los agentes los aprueben? ¿Puedo activarlo solo para un tema o un canal? ¿Puedo limitar cuántas respuestas envía al día? El agente de correo de Freshdesk tiene justo ese límite, "útil para despliegues controlados" (Freshdesk). Redactar primero también le da a tu equipo un copiloto de IA mientras reúnes evidencia, así que la prueba se paga sola con el tiempo de escritura que ahorra.
Las preguntas para hacer a cada proveedor
Llévate esto a cada demo. Si un proveedor no puede responder una con claridad, esa es tu respuesta.
| Pregunta | Por qué importa |
|---|---|
| ¿Puedo probarlo con mis propios tickets pasados antes de salir en vivo? | Los escenarios escritos solo prueban lo que se te ocurrió |
| ¿Frente a qué se puntúa en esa prueba? | "Respondida" no es lo mismo que "correcta" |
| ¿Aprende de nuestros tickets resueltos y macros? | Ahí viven el tono de tu equipo y tus políticas reales |
| ¿Qué cuenta exactamente como unidad facturable? | "Resolución" significa algo distinto en casi todos los proveedores |
| ¿Cómo sería mi factura en nuestro mes más fuerte? | Los costes por resolución suben a medida que el agente mejora |
| ¿Una resolución cuenta el spam o los chats abandonados? | Infla tanto la factura como la tasa reportada |
| ¿Qué acciones funcionan en mi entorno sin ingeniería? | Los entornos de demo no son tu entorno |
| ¿Puede funcionar solo en borrador, por tema, con aprobaciones en reembolsos? | El despliegue por fases es cómo evitas un error público |
| ¿Qué recibe una persona en el traspaso? | Un mal traspaso cuesta más tiempo de agente del que ahorra |
| ¿Funciona dentro de mi helpdesk actual? | Cambiar de helpdesk para tener un agente de IA es un gran coste oculto |
Para una lista corta ya preparada con la que probar estas preguntas, consulta mi comparativa de agentes de soporte con IA y mi lista de herramientas de automatización de soporte.
Errores que veo cometer a los equipos
- Juzgar por una sola cifra. La tasa de resolución de un proveedor, o tu propia "precisión", oculta la historia. Sigue la tasa de deflexión, el CSAT de IA y los tickets reabiertos a la vez. Como dijo un comentarista de Hacker News, la dirección "puede ver métricas que muestran que el agente de servicio de IA ayudó con éxito en el 80 % de las preguntas, pero no se da cuenta de lo dañino que es ese 20 %" (cortesoft, Hacker News).
- Probar antes de mirar el precio. Un usuario de prueba con el que trabajó eesel vio resultados excelentes en 12 chats de prueba y luego pidió cancelar al ver la página de facturación. Modela primero el coste y luego prueba.
- Dejar que el bot esté seguro de cosas que no puede hacer. Un reseñador de G2 señaló que Ada una vez ofreció "acciones que en realidad no puede realizar (por ejemplo, cancelar pedidos)", aunque añadió que el entrenamiento lo solucionó (G2). Prueba el límite de lo que se le permite prometer.
- Saltarse la prueba de traspaso. Los tickets desviados se ven bien en un panel; los tickets que rebotan son donde cae el CSAT.
- Comprar un helpdesk nuevo para tener un agente de IA. A menos que ya fueras a cambiar, migrar de herramienta solo para tener un agente es la forma más cara de automatizar. Mira primero las opciones que funcionan en tu configuración actual de Zendesk, Freshdesk o Gorgias.
Prueba eesel en tu helpdesk
Si estás eligiendo ahora un agente de IA para atención al cliente, el compañero de IA para helpdesk de eesel se construyó en torno a las comprobaciones anteriores. Se une al helpdesk que ya usas (Zendesk, Freshdesk, Gorgias, Front, HubSpot, Help Scout, Salesforce y más), aprende de tus tickets pasados y macros con una conexión completa, y ejecuta una simulación sobre tus tickets resueltos para que veas dónde coincide con tu equipo y dónde no antes de que un cliente vea una respuesta. Empieza en modo borrador con los reembolsos tras una aprobación, y amplías su alcance tema por tema.
Gridwise lo expresó así tras su prueba: "En el primer mes, eesel está resolviendo el 73 % de nuestras solicitudes de nivel 1". El precio es un plan fijo por ticket gestionado, desde 299 $/mes por 500 tickets, sin tarifas por puesto, y el spam no cuenta. El plan gratuito te da 100 créditos para ver borradores reales con tus propios tickets primero.

Prueba eesel gratis, o reserva una demo y trae tu briefing.