Por qué cambiar de proveedor de IA es un problema de traspaso
Construyo agentes de IA en eesel y me meten en muchas conversaciones del tipo «queremos pasarnos a otra IA». Casi ninguna empieza con «la IA es mala». En las llamadas de ventas de eesel de este año, un operador de comercio electrónico en Zendesk había probado la IA nativa, la había encontrado demasiado cara y no lo bastante buena, y quería cambiar «para ayer». Un equipo de soporte de hardware (unos 250 tickets al mes, cuatro idiomas, también en Zendesk) se veía forzado a dejar su herramienta de IA porque el proveedor cambiaba su forma de hacer negocio. Ninguno había elegido la fecha. La había elegido otro.
Ese es el momento en que la gente se salta la parte cuidadosa. Cuando el plazo era ayer o lo fijó el proveedor, una migración brusca parece la opción rápida. Normalmente no lo es, porque lo que se rompe no son las respuestas de la nueva IA. Es el traspaso entre dos sistemas que creen ser dueños de la conversación. eesel lleva años poniendo agentes de IA en colas de soporte reales, y simulamos cada despliegue contra tickets históricos antes de que salga en vivo porque hemos visto a un bot muy seguro de sí mismo dar respuestas erróneas a clientes reales. Aun así, la mayor parte de lo que sale mal en un cambio es fontanería: dos bots respondiendo a un mismo chat, tickets creados dos veces, historial que no llegó.
Así que este es el cambio de enfoque que yo tendría en mente. No estás moviendo una IA. Estás moviendo una decisión de enrutamiento, y puedes moverla porción a porción, de ida y vuelta, mientras la configuración antigua siga ahí. Esta guía lo recorre en el orden en que yo lo haría, con los controles propios de cada helpdesk comprobados contra la documentación de su proveedor el 20 de octubre de 2026: inventario, construir y probar aparte, sombra, piloto, aumento gradual, con los chats en curso, tu equipo, los disparadores de rollback y las fechas de contrato gestionados en paralelo.
Dos entradas vecinas cubren piezas que no repetiré. Si aún decides si poner una IA de terceros sobre la integrada de tu helpdesk, lee capa de IA vs IA integrada. Si quieres la mecánica semana a semana de un piloto, cómo ejecutar un piloto de IA de soporte la tiene.
Paso 1: inventaría lo que hace la IA antigua y lo que se traslada
Empieza anotando todo lo que hace la IA antigua, incluidas las cosas que nadie recuerda haber configurado. Luego divide la lista en dos montones: lo que vive en tu helpdesk (y se traslada con una exportación, o simplemente se queda) y lo que vive dentro del proveedor de IA (y hay que reconstruir). El resumen honesto de ese segundo montón es que tu conocimiento es portable y tu configuración no.
Esta es la clasificación con la que yo empezaría, con lo que dice la documentación de cada helpdesk sobre cómo sacar las cosas.
| Lo que tienes | ¿Se traslada? | Qué dice la documentación del proveedor |
|---|---|---|
| Artículos del centro de ayuda y otro conocimiento | Sí, normalmente lo más fácil | Se quedan en tu helpdesk, así que una nueva IA que lee el centro de ayuda no necesita exportación. Gorgias te permite activar o desactivar contenido para su IA en la página Knowledge |
| Macros | Sí | Gorgias exporta macros a CSV con columnas de nombre, cuerpo, etiquetas e id. Para Zendesk, consulta exportar macros |
| Historial de tickets | Sí, con límites | Zendesk exporta tickets, usuarios y organizaciones como JSON, CSV o XML, pero el propietario de la cuenta debe pedir al soporte de Zendesk que lo active, y las herramientas de exportación no están en los planes Team (la API REST sí). Gorgias exporta tickets a CSV, hasta 1 millón por vista |
| Flujos, intenciones, prompts | No | Reconstruir. Pasa incluso dentro de un mismo proveedor: la guía de migración de Zendesk dice que pasar de AI agents - Essential y el constructor de bots heredado a la nueva experiencia puede implicar reconstruir agentes, con un agente separado por canal |
| Acciones y hooks de API | No | Reconstruir y luego volver a autenticar cada conexión |
| Respuestas automáticas, mensajes de bienvenida y reglas | No | Anótalos ya, porque una regla olvidada puede responder junto a la nueva IA. Apagarás cada una a propósito en el Paso 4 |
| Registros de conversaciones solo del bot | Comprobar antes de cancelar | La página de exportación de Zendesk dice que los tickets de agente de IA no se pueden exportar con esa herramienta, así que pregunta al proveedor antiguo qué entregará y cuándo |
| Tus cifras de referencia | Tienes que capturarlas | Nadie las exporta por ti. Sácalas en el Paso 1, no después de la migración |
La última fila es la que se olvida. Si no capturas las cifras de la IA antigua antes de que cambie nada, acabarás juzgando la nueva contra un recuerdo. Saca las últimas 8 a 12 semanas de los tipos de ticket que planeas mover: tasa de resolución (contada como la cuenta tu proveedor antiguo), tasa de traspaso, contacto repetido en siete días, tiempo de primera respuesta y CSAT. Los proveedores definen «resuelto» de forma distinta, por eso leería la guía de tasa de resolución de la IA y la lista de KPIs de atención al cliente antes de elegir definiciones.
Otro hábito de inventario que compensa: escribe el comportamiento de la IA antigua como reglas simples: qué rechaza, cuándo traspasa, qué tono usa, qué temas nunca toca. Esas frases se convierten en las instrucciones de la nueva IA, y son la parte de una configuración que realmente se traslada. Si además tu base de conocimiento necesita una puesta a punto antes de alimentar a una nueva IA, una auditoría de la base de conocimiento es la semana más barata que vas a invertir.
Paso 2: construye y prueba la nueva IA sin tocar producción
Construye la nueva IA aparte y pruébala donde no pueda llegar a un cliente. Todos los helpdesks grandes te dan un lugar para hacerlo, y la mayoría no cobra por ello.
- Zendesk: probar en un sandbox no consume resoluciones automatizadas, y tampoco el widget de prueba ni el simulador de conversaciones, aunque probar en producción sí puede. Zendesk también sugiere probadores que no hayan construido los flujos. La guía de sandbox vs producción cubre la configuración.
- Freshdesk: el Email AI Agent tiene una pestaña Evaluate donde puedes crear un conjunto de pruebas a mano, generar correos de ejemplo o importar tickets históricos resueltos. Freshdesk recomienda al menos 20 consultas representativas antes de desplegar, y su vista previa no toca conversaciones en vivo. Mira también configuración del sandbox de Freshdesk.
- Gorgias: las conversaciones de prueba en el Playground no se facturan y no envían mensajes reales a los compradores.
- HubSpot: el agente de clientes tiene pruebas por lotes, donde revisas cada respuesta como buena o mala.
Esas herramientas prueban la IA propia de cada proveedor, así que la IA del nuevo proveedor se prueba en la herramienta del nuevo proveedor. Lo que yo añadiría es un conjunto de pruebas compartido que respondan ambas IAs: unos 50 tickets reales del carril que planeas mover primero, etiquetados por tipo, incluyendo los incómodos (el cliente enfadado, la pregunta que tu documentación responde mal, la solicitud que debería ir a una persona). Cuando la nueva IA y la antigua responden los mismos 50, las diferencias dejan de ser opiniones. La guía de pruebas de agentes de IA de soporte tiene una secuencia de pruebas completa, y las pruebas adversariales tienen los tickets difíciles para tomar prestados.
Aquí es también donde la simulación de eesel se gana su sitio. Le pides por chat que ejecute una simulación sobre tus tickets recientes, y los reproduce y puntúa sus respuestas frente a lo que tu equipo envió realmente, y después lista las lagunas y sugiere cambios en las instrucciones. No pronostica una tasa de resolución ni un coste, y no confiaría en una herramienta que lo hiciera antes de que un solo cliente haya visto una respuesta. Sí te dice, en una tarde, qué tipos de ticket están listos.
Paso 3: migra por fases, primero sombra, luego piloto, luego aumento gradual
Ahora la parte en la que casi todos los manuales de despliegue coinciden: migra por fases en lugar de elegir una fecha. La IA antigua sigue respondiendo todo lo que la nueva aún no se ha ganado, y el porcentaje sube por escalones.
| Fase | La nueva IA hace | La IA antigua hace | Avanza cuando |
|---|---|---|---|
| Sombra (aprox. 1 semana) | Solo borradores o notas internas, nada llega a un cliente | Responde a todos | Los borradores del carril coinciden la mayoría de las veces con lo que envía tu equipo, y ningún borrador propone una acción incorrecta |
| Piloto (aprox. 2 semanas) | Responde al 5 a 10 % de un tipo de ticket | Responde al resto | El piloto cumple tus criterios de aprobación por escrito (el cuadro de mando del piloto tiene umbrales para copiar) |
| Aumento (2 a 3 semanas) | 25 %, luego 50 %, luego 100 %, añadiendo un canal o tipo de ticket en cada paso | Se reduce en cada paso | Has cambiado una sola cosa por paso y las cifras se mantuvieron |
| Ventana de rollback (aprox. 4 semanas) | 100 % de las conversaciones nuevas | Configurada, pero apagada para chats nuevos | No saltó ningún disparador de rollback (ver abajo) |
Un 5 a 10 % de un tipo de ticket es el tamaño que elegiría por una razón: lo bastante grande para mostrar patrones, lo bastante pequeño para que una respuesta incorrecta llegue a un puñado de clientes y no a la mitad de tu cola. Y una regla mantiene legibles las cifras: cambia una sola cosa a la vez y anota la fecha, porque una porción más amplia y una instrucción nueva en la misma tarde significan que no puedes saber cuál movió el resultado.
Cómo envías una porción depende del helpdesk. Esto es lo que te da la documentación de cada proveedor.
| Helpdesk | Enviar una porción a una IA | Apagar la IA antigua |
|---|---|---|
| Zendesk | Elige canales por agente de IA; solo un agente de IA puede estar activo en un canal. Existen divisiones de tráfico A/B, pero tu gestor de cuenta tiene que activarlas | Desmarca el canal en Manage channels y activa el otro |
| Freshdesk | Por fuente de tickets (buzón, portal, formulario), con las estrategias «Deploy to internal team» y «Deploy with custom rules» | Desactiva el agente existente en esa fuente antes de asignar uno nuevo; el despliegue es inmediato y cubre solo tickets nuevos |
| Gorgias | Activa AI Agent por canal en Deploy (correo, chat, SMS, mensajes directos de redes sociales, WhatsApp), y usa la regla «Prevent AI Agent from answering» para excluir tickets por etiqueta, remitente o palabra clave | Cambia el interruptor ON/OFF del canal; los tickets excluidos reciben una etiqueta ai_ignore |
| HubSpot | Un porcentaje de cobertura de conversaciones, horario laboral y listas de contactos para incluir o excluir, en el despliegue por canal | Apaga el agente en Account and Billing, o quítalo de un canal |
El cuadro de Zendesk de arriba muestra la restricción que lo condiciona todo: un agente de IA por canal. Si la IA antigua es la propia de Zendesk y la nueva es una capa de terceros, dividirás por canal o por una etiqueta o cola por la que filtre la capa de terceros, porque los controles propios de Zendesk solo gobiernan la IA propia de Zendesk. Elige una regla de división que ambos lados puedan ver (un canal, una etiqueta, una cola, una lista de clientes) y anótala en el plan.
El calendario de Luxedo es el que yo copiaría, aunque no sustituía a otra IA. El fabricante de proyectores Luxedo conectó Gorgias con eesel en julio de 2026, dedicó agosto a construir el conocimiento y las instrucciones, y activó el disparador de tickets en la última semana de agosto. eesel deja una nota interna con un borrador de respuesta y un resumen, y una persona la envía. Entre el 8 de agosto y el 8 de septiembre preparó 21 tickets. Nadie se llevó ninguna sorpresa, que es justo el objetivo de un aumento gradual.
Aquí tienes un planificador para tu propia versión. Introduce tu fecha de inicio y la duración de las fases, y la fecha de renovación y el preaviso del contrato antiguo. Dibuja el calendario y muestra si tu fecha límite de preaviso cae antes o después de la decisión del piloto, que es lo que más sorprende.
Paso 4: evita tickets duplicados cuando hay un bot de terceros
Si la IA antigua o la nueva es un bot de terceros en Zendesk, hay un cambio de reglas que no puedes saltarte. El propio aviso de Zendesk dice que desde el 4 de mayo de 2026 impone tickets de agente de IA para todas las conversaciones atendidas por bots, no solo las escaladas, y que los tickets de agente de IA pasan a ser el mecanismo exclusivo de creación de tickets para las conversaciones gestionadas por agentes de IA y bots de terceros. Si tu bot además está configurado para crear sus propios tickets en chats solo del bot, ahora obtienes dos tickets por una conversación.
El aviso pide tres cosas, y yo las trataría como lista de comprobación tanto para el bot antiguo como para el nuevo:
- Auditar la creación de tickets. Busca acciones de «crear ticket» en la plataforma del bot y webhooks personalizados que creen tickets a partir de eventos del bot. Zendesk sugiere la acción releaseControl si quieres adjuntar metadatos a tickets resueltos.
- Probar e informar. Prueba la integración en un sandbox antes de que el cambio llegue a producción y muestra a tu equipo el formato de ticket de agente de IA.
- Desactivar la vía heredada. Apaga cualquier creación manual de tickets que lo duplique.
Zendesk añade un alivio: las interacciones con bots de terceros no generan cargos por resolución automatizada, así que estos tickets aportan visibilidad, no una factura. Eso sí, ocupan espacio. Los tickets de agente de IA cuentan para los límites de almacenamiento, son de solo lectura para la mayoría de usuarios, y los triggers y automatizaciones no se disparan en ellos hasta que una conversación se escala a una persona. Así se ve desde la silla del administrador, en un hilo publicado pocos días antes de escribir esto:
"The main issue is that there appears to be no way to disable Zendesk from creating an AI Agent ticket for EVERY SINGLE interaction an end user has with the bot, not just handoffs."
Una respuesta en el mismo hilo expresa bien la ventaja práctica:
"Luckily they’re easy to exclude from reports and views, but definitely annoying to parse through when you need to find something."
El mecanismo de fondo es el switchboard de Zendesk, y entenderlo evita la mayoría de los errores de solapamiento. Cada conversación tiene exactamente una integración de switchboard activa a la vez, y las demás esperan en reserva. Así que durante una ejecución en paralelo, «ambos bots en vivo en el mismo canal» significa que un bot es dueño de cada conversación, y el respondedor por defecto decide quién recibe las nuevas. Hay un filo cortante que conviene conocer: si eliminas una integración de switchboard que estaba activa en una conversación, los mensajes nuevos se reasignan a la integración por defecto sin un webhook passControl. Elimina el bot antiguo después de que sus conversaciones abiertas se hayan cerrado, no antes. La guía de orquestación de switchboard profundiza más.
En otros helpdesks el mismo principio aparece con otras palabras. Freshdesk permite que cada fuente de tickets tenga un agente de IA activo y avisa de un conflicto si intentas asignar un segundo. La solución es la misma en todas partes: un responsable por conversación, decidido por una regla que hayas escrito. Y los duplicados tampoco son solo tickets. Gorgias, por ejemplo, desactiva Article Recommendations automáticamente cuando AI Agent se activa en el chat, y sugiere revisar cualquier regla de respuesta automática personalizada para que los compradores no reciban dos mensajes. Anota tus antiguos mensajes de bienvenida y respuestas automáticas en el Paso 1 para poder apagarlos a propósito.
Paso 5: ejecuta ambas en paralelo y compara en igualdad de condiciones
Durante el piloto y el principio del aumento tendrás ambas IAs en vivo sobre porciones distintas. Aprovéchalo. La comparación más útil no es la nueva IA contra el trimestre pasado, sino la nueva IA contra la IA antigua en los mismos tipos de ticket en las mismas semanas, porque la estacionalidad, un lanzamiento de producto o un cambio de precios afectan por igual a ambas porciones.
Mantén un grupo de control en la IA antigua mientras subes, igual que un piloto mantiene una cola de control solo humana. La documentación de A/B de Zendesk establece el primer grupo como grupo de control, y la guía del piloto explica cómo dimensionarlo. Después compara cuatro cosas, definidas de forma idéntica para ambos lados:
- Resolución: conversaciones que la IA cerró sin contacto repetido en siete días, no la marca de resuelto del propio proveedor.
- Tasa y calidad de traspaso: con qué frecuencia traspasa y si la persona que lo recibe tiene que volver a preguntar.
- Contacto repetido y CSAT: clientes que vuelven por el mismo problema y cómo valoran la conversación.
- Coste por conversación atendida: cada proveedor factura una unidad distinta, así que convierte ambos a coste por conversación que tu equipo habría respondido de otro modo.
Esto último es fácil de hacer mal porque las unidades de facturación difieren mucho: Zendesk factura resoluciones automatizadas, el agente de HubSpot funciona con créditos de HubSpot, y Freddy de Freshdesk tiene su propio precio por sesión. Revisaría la página de precios vigente de cada proveedor antes de montar la comparación y usaría la guía de métricas de IA para CX para mantener claras las definiciones.
Paso 6: protege las conversaciones que ya están en curso
Esta es la sección que leería dos veces. Un cliente que empezó un chat con la IA antigua a las 2:55 pm no debería pasar a otra IA a las 3:00 pm porque cambiaste un ajuste. La regla: dirige las conversaciones nuevas a la nueva IA y deja que las abiertas terminen donde empezaron.
El comportamiento propio de los proveedores coincide en su mayor parte con esa regla, lo que ayuda:
- HubSpot: si apagas el agente de clientes, sigue atendiendo los hilos existentes hasta que la conversación se resuelve, pero no recibe nuevos.
- Freshdesk: el despliegue es inmediato y cubre solo tickets nuevos. Los tickets que llegaron antes no se responden retroactivamente.
- Zendesk: un ticket de agente de IA de mensajería cuenta como en curso hasta que pasan cuatro días sin respuesta, la IA cede el control o (en bots de terceros) el bot decide que está resuelto.
Luego está el traspaso y la devolución entre una IA y tu gente, que se comporta de forma distinta a lo que la mayoría de los equipos supone. En la mensajería de Zendesk, un agente sigue siendo el primer respondedor hasta que el ticket se cierra. La devolución solo ocurre cuando el ticket pasa de Resuelto a Cerrado, y por defecto eso tarda cuatro días, así que un cliente que vuelve en esa ventana sigue cayendo en la conversación antigua con la persona, no con la IA. Puedes acortar la automatización «cerrar ticket 4 días después de resuelto» a una hora o ampliarla a 28 días, pero deja un pequeño margen si usas CSAT, ya que la encuesta se lanza en el momento en que un ticket pasa a Resuelto. Durante una migración eso importa de una forma concreta: quién responde a los clientes que vuelven lo gobierna ese temporizador, no tu ajuste de IA.
Gorgias te da un conjunto distinto de controles de traspaso: temas que siempre escalan, un interruptor para que la IA avise a los clientes por correo o SMS de que traspasa y, en el chat, un paso de confirmación antes de traspasar. Uses el helpdesk que uses, asegúrate de que el traspaso de la nueva IA lleve el contexto que necesita una persona, para que el cliente no tenga que repetirse. La lista de buenas prácticas de traspaso de agentes de IA y la guía de traspaso en Zendesk cubren lo que contiene un buen traspaso.
¿Cuánto dura la cola? Mira tus propios datos: cuánto tiempo permanecen abiertos los chats atendidos por IA antes de cerrarse, y cuál es tu tiempo abierto realista más largo. Ese número es cuánto tiempo debe seguir encendida la IA antigua para los chats existentes después de que la nueva se quede con todos los nuevos.
Paso 7: informa a tu equipo antes del primer día en vivo
Tus agentes son quienes notarán primero los problemas, y quienes más probablemente se enterarán del cambio por un cliente enfadado si no se lo cuentas. Dales un manual de una página antes de que empiece la sombra. El mío tiene seis líneas:
- Qué cambia y cuándo. El calendario de fases, en palabras llanas, con la fecha en que se traslada cada tipo de ticket.
- Su papel en el proceso. Son los revisores. Quince minutos al día leyendo las conversaciones de la IA de ayer y marcando las incorrectas con una etiqueta.
- Qué verán distinto. En Zendesk, los tickets de agente de IA son de solo lectura para la mayoría de usuarios y los escalados vuelven como Nuevos; en los demás helpdesks, la etiqueta o nota que deje la nueva IA.
- Qué hacer en un traspaso. Quién lo recoge, dónde está el contexto y qué decirle a un cliente que pregunta «¿estaba hablando con un bot?».
- Cómo reportar una mala respuesta. Una etiqueta, un canal, respondido el mismo día. Una convención de etiquetas como
ai_oldyai_newhace posible la comparación del Paso 5; etiquetado de soporte con IA tiene ideas de nombres. - Quién puede pausarlo y cuándo. Nombra a una persona en cada turno.
El patrón que más escucho en las llamadas de ventas es que los equipos quieren primero un copiloto y después la automatización completa: la IA redacta respuestas para los agentes y se gradúa cuando existe confianza. Eso encaja perfectamente con un cambio, porque el modo sombra es exactamente eso. Escribir la rutina de revisión en tu SOP de soporte y mantener ligado a ella el proceso de cambio de políticas evita que un nuevo plazo de devolución se convierta sin darte cuenta en una respuesta incorrecta de la nueva IA en la semana tres.
Disparadores de rollback, escritos antes de empezar
Decide qué cuenta como fallo mientras nadie está alterado. Quienes escriben el disparador en mitad de un incidente tienden a convencerse de no usarlo. Esta es la tabla con la que yo empezaría; los umbrales son mis propios puntos de partida, así que ajústalos a tu volumen.
| Disparador | Cómo lo verías | Qué hacer |
|---|---|---|
| Una acción incorrecta llega a un cliente (reembolso, cancelación, cambio de cuenta) | Revisión diaria o queja de un cliente | Pausa esa acción el mismo día; mantén el carril en borradores hasta corregirlo |
| La IA afirma una política o un precio inventados | Revisión diaria | Pausa ese tema, corrige el artículo fuente, vuelve a probar |
| Las peticiones de una persona superan la referencia de la IA antigua | Tasa de traspaso, o frases como «agente» y «humano» | Reduce la porción y revisa los temas de traspaso |
| El contacto repetido en 7 días supera en 3 o más puntos la referencia de la IA antigua durante dos días seguidos | Informe de contacto repetido | Devuelve la porción a la IA antigua y analiza los errores |
| El CSAT de las conversaciones atendidas por IA cae bruscamente frente a la porción antigua | CSAT por etiqueta | Detén el aumento y lee las conversaciones mal valoradas |
«Rollback» debería significar cambiar un ajuste, no reconstruir algo. Por eso la IA antigua sigue configurada durante la ventana de rollback: tu palanca de pausa es un interruptor, como desmarcar el canal en Zendesk, el límite diario de conversaciones en Freshdesk, el interruptor del canal en Gorgias o apagar el agente de clientes en HubSpot. HubSpot tiene una rareza que conviene conocer: un agente de clientes no se puede eliminar una vez creado, solo pausar, así que el antiguo seguirá ahí si lo necesitas. Registra cada pausa con fecha y motivo. Una pausa no es un cambio fallido, es el sistema funcionando.
Solapamiento de contratos y ventana de cancelación
La forma más barata de cambiar es pagar dos IAs durante unas semanas. Parece un derroche, y aun así es más barato que la alternativa, que es cancelar la antigua al empezar el piloto y descubrir en la semana tres que no hay vuelta atrás.
Mantendría tres reglas en cuanto al dinero:
- Conserva el plan antiguo durante la ventana de rollback. Si tu contrato termina antes, pide una modalidad mensual para el solapamiento. El planificador de arriba muestra exactamente cuántos días te faltarían.
- Lee tu propio formulario de pedido para el preaviso. La renovación automática y los plazos de preaviso son condiciones contractuales, no documentación de producto, así que no puedo decirte cuáles son los de tu proveedor. Sí puedo decirte que un preaviso de 60 días puede caer antes de la decisión de tu piloto, y ese es el caso por el que merece la pena negociar.
- Conoce cada unidad de facturación durante el solapamiento. Zendesk dice que las conversaciones con bots de terceros no generan cargos por resolución automatizada, así que solaparte con un bot de terceros te cuesta el plan de ese bot, no la tarifa por resolución de Zendesk. El agente de HubSpot deja de asignarse a conversaciones nuevas si se te acaban los créditos, un evento de facturación que parece una caída.
Antes de cancelar nada, exporta lo que quieras conservar. Pregunta por escrito al proveedor antiguo qué datos puede entregar (registros de conversaciones, analíticas, configuración) y durante cuánto tiempo tras la cancelación. Luego cierra el círculo en el planificador: tu fecha de preaviso debería caer después de la decisión del piloto, dentro o después de la ventana de rollback.
Errores que evitaría
- Cambiar en tus semanas de más trabajo. Elige un tramo tranquilo: Norden-Frisia, una naviera de ferris cuyo calendario se llena a partir de mayo, probó eesel en febrero y después dimensionó su plan según el volumen estacional.
- Mover una conversación a mitad de chat.
- Cambiar dos cosas a la vez y luego discutir cuál rompió las cifras.
- Comparar la nueva IA con el trimestre pasado en lugar de con la porción simultánea de la IA antigua.
- Cancelar al empezar el piloto porque «se ve bien».
Cómo gestiona eesel un cambio
Soy parcial, así que aquí va la versión sencilla de dónde encaja eesel y dónde no. eesel es un compañero de IA para el helpdesk que se conecta al helpdesk que ya tienes, así que un cambio no exige mover tus tickets a ninguna parte. Lee tu centro de ayuda, tus macros y tus tickets pasados directamente del helpdesk, por eso no necesita nada exportado de la IA antigua. Estas son las integraciones que más se activan:
Eso encaja con los pasos anteriores:
- Portabilidad: las macros son el activo más portable que tienes. Koffer.ch, una tienda suiza de maletas en Freshdesk, lee primero sus macros y usa una coincidente palabra por palabra, en cualquiera de los cuatro idiomas en que escribiera el cliente. Cada respuesta es un borrador que envía una persona.
- Entrenamiento y pruebas: Norden-Frisia, una naviera alemana de ferris, conectó Zendesk durante una prueba de una semana en febrero de 2025, importó sus macros y los tickets de los últimos tres meses, y se dio de alta en pocos días. Antes de cualquier salida en vivo, la simulación reproduce tus tickets pasados para que veas primero las lagunas.
- Fases: puedes empezar con eesel despertando solo con una mención @eesel en una nota interna, pasar después a cada mensaje de ticket de cliente y mantenerlo en borradores mientras revisas. Esa es tu semana de sombra incorporada.
- Precios durante el solapamiento: eesel son planes de créditos mensuales fijos, no una tarifa por resolución. Un ticket o un chat es un crédito sin importar cuánto dure, hay un plan gratuito con 100 créditos y sin tarjeta, y Teammate empieza en 299 $ al mes por 500 créditos, con todas las integraciones, agentes y puestos incluidos.
Conviene decir los límites con claridad. eesel no importa los flujos, intenciones ni registros de conversaciones de otro proveedor que nunca llegaron a ser tickets, así que los reconstruyes como instrucciones, algo que a la mayoría de equipos les lleva menos tiempo que la construcción original. Y si solo quieres la IA que tu helpdesk ya incluye, no necesitas una capa; las páginas de comparación de Freddy, Gorgias AI Agent y HubSpot Breeze exponen dónde están las ventajas e inconvenientes.
Prueba eesel
Si te vas de Zendesk AI agents, Freddy, Gorgias AI Agent, HubSpot Breeze o un bot de terceros, prueba eesel primero en tu propia cola. Conecta tu helpdesk, deja que aprenda de tus tickets pasados, ejecuta una simulación y empieza en borradores mientras tu IA actual sigue respondiendo. Es la semana de sombra de esta guía, y el plan gratuito la cubre.
