Gestión de cambios en las políticas de soporte: cómo desplegar una política nueva en todas partes

¿Qué es la gestión de cambios en las políticas de soporte?

Es el proceso de cambiar una regla de cara al cliente y asegurarse de que cada canal, persona y herramienta que repite esa regla pase a la versión nueva el mismo día. Piensa en un plazo de devolución de 30 días que pasa a 14, una tarifa de reposición que aparece, un reembolso que ahora exige una foto, o una promesa de tiempo de respuesta (un SLA) que pasa de 4 horas a 1 día hábil.

Atiendo la cola de soporte de eesel todos los días, y el patrón siempre es el mismo. El responsable de la política (finanzas, legal, operaciones) actualiza la página de la política y avisa a la responsable de soporte. Ella actualiza el artículo principal del centro de ayuda. Y durante las tres semanas siguientes siguen llegando tickets en los que un cliente te cita la regla antigua, porque la leyó en una respuesta guardada, una traducción al francés, un correo de confirmación de pedido o una respuesta del chatbot.

Esa es la idea central de esta guía: una política no es un documento, son seis o siete copias de un documento, y la gestión de cambios es el trabajo de encontrarlas todas.

Dónde se esconden las copias antiguas de una política

Antes de cambiar nada, necesitas un inventario. Estos son los sitios que reviso siempre, más o menos ordenados por la frecuencia con la que fallan.

1. El artículo principal del centro de ayuda. De este se acuerda todo el mundo.
2. Otros artículos que mencionan la regla de pasada. Las preguntas frecuentes de envíos que dicen "las devoluciones son gratis durante 30 días". El artículo de tarjetas regalo. La página de pedidos internacionales. Estos son los que nadie recuerda.
3. Traducciones. Cada versión de idioma es su propia copia y no se actualiza cuando se actualiza la inglesa.
4. Macros y respuestas guardadas. Normalmente el montón más grande y el más difícil de buscar (más sobre esto abajo).
5. Conocimiento del agente de IA. Artículos del centro de ayuda, PDF subidos, Google Docs, páginas web rastreadas y cualquier regla o "guidance" que hayas escrito directamente en la herramienta de IA.
6. Flujos de chatbot y plantillas de correo. Confirmaciones de pedido, textos del portal de devoluciones, respuestas automáticas activadas por etiquetas.
7. La cabeza de tus agentes. La regla que han escrito de memoria 400 veces.

El problema de búsqueda del que nadie avisa

Esto me sorprendió cuando repasé la documentación de los proveedores. La mayoría de los helpdesks solo documentan la búsqueda de macros y respuestas guardadas por nombre, no por el texto que contienen. La búsqueda de macros de Zendesk funciona con el nombre o parte del nombre. Los snippets de HubSpot se buscan por nombre. Help Scout y Zoho Desk también buscan respuestas guardadas y snippets por nombre. Así que no puedes escribir "30 días" y obtener todas las respuestas que prometen 30 días.

El truco es exportar. Freshdesk te permite exportar respuestas predefinidas a CSV, editar la columna Content HTML y reimportar, siempre que no toques el Canned Response ID. Gorgias hace lo mismo con CSV de macros identificados por id. En Zendesk, exportar macros te da un archivo que puedes buscar con Ctrl+F. Cuando el texto está en una hoja de cálculo, encontrar cada copia de la regla antigua lleva minutos en lugar de una tarde de clics.

Help Scout tiene una trampa extra. Las respuestas guardadas viven por bandeja de entrada, y el botón Copiar crea una respuesta separada en la otra bandeja. Cinco bandejas significan cinco ediciones.

Por eso las bibliotecas de macros desordenadas duelen más de lo que parece. En una llamada de ventas de eesel, una marca DTC en Gorgias con unos 7.000 tickets al mes describió su conocimiento como disperso entre herramientas de SOP, vídeos de Loom sin transcribir y macros desactualizadas. Cada cambio de política en un entorno así es un proyecto de arqueología. Si el tuyo se parece, mi guía sobre gestionar macros es una buena primera limpieza.

¿Con qué rapidez se entera tu agente de IA del cambio?

Esta es la sección que le diría a cada responsable de soporte que lea dos veces. Cuando editas un artículo, un agente humano ve la versión nueva la próxima vez que lo abre. Tu agente de IA quizá no.

La regla general según la documentación de los proveedores: las ediciones de artículos dentro de tu helpdesk llegan rápido a la IA, mientras que las ediciones de cualquier cosa fuera (una página web, un Google Doc, una página de política rastreada) pueden quedar obsoletas hasta que alguien resincroniza.

Aquí está el detalle, todo del centro de ayuda de cada proveedor:

La fila de Gorgias merece una mirada más atenta, porque las tiendas Shopify tienen su política de devoluciones y envíos en el sitio web de la tienda. Gorgias trae esas páginas a snippets de preguntas y respuestas que no puedes editar, y resincronizar está permitido una vez cada 24 horas. Si cambias la página de devoluciones a las 9 de la mañana, tu agente de IA puede seguir citando el plazo antiguo esa tarde. La alternativa de la propia Gorgias, cuando no puedes esperar, es desactivar el snippet con el contenido obsoleto.

Dos copias que se contradicen son peores que una copia obsoleta

Gorgias también publicó la advertencia más clara que encontré sobre copias en conflicto. Su documentación de conocimiento dice "guidance carries the most weight" y da este ejemplo exacto: si un artículo del centro de ayuda dice que el plazo de devolución es de 30 días pero una guidance dice 14, el agente de IA "might not respond the same way every time". Ese es el modo de fallo realista de un cambio de política a medio terminar. No una respuesta errónea cada vez, sino un cara o cruz. La función Opportunities de Gorgias (en beta) puede marcarlos como "Resolve knowledge conflict" y mostrar ambos contenidos lado a lado.

Help Scout tiene una versión de la misma trampa. Sus AI Answers te permiten añadir pequeñas "Improvements" para corregir respuestas. Si corriges el artículo de Docs y olvidas la Improvement antigua, la IA puede seguir repitiendo la regla vieja. Si ejecutas IA en cualquier helpdesk, el hábito de gestión de la base de conocimiento que más importa durante un cambio de política es borrar la versión antigua, no solo añadir la nueva.

Por qué esto importa más que antes

En febrero de 2024, el Civil Resolution Tribunal de la Columbia Británica resolvió Moffatt v. Air Canada. El chatbot del sitio web de Air Canada le dijo a un cliente en duelo que podía solicitar una tarifa reducida por duelo dentro de los 90 días posteriores a la compra del billete, incluso después de viajar. La página de duelo a la que enlazaba el chatbot decía que la política no se aplicaba después del viaje. Air Canada argumentó, en palabras del tribunal, que no podía ser considerada responsable de la información de sus representantes, "including a chatbot". El tribunal lo llamó "a remarkable submission" y escribió: "It makes no difference whether the information comes from a static page or a chatbot." También dijo que los clientes no deberían tener que contrastar una parte de un sitio web con otra. La aerolínea pagó 812,02 $ en daños, intereses y costas.

La cantidad es pequeña. El principio no. Cuando dos de tus copias se contradicen, el cliente puede apoyarse en la que leyó. Un comentarista de Hacker News expuso la causa más probable sin rodeos:

"I wonder whether the bot hallucinated the wrong information or whether the policy changed and the bot simply wasn't updated / retrained. The latter seems more likely but less interesting, akin to information on a boring HTML page getting overlooked during a site update."

danepowell, Hacker News

No solo les pasa a las aerolíneas. En abril de 2025, el bot de soporte con IA de Cursor le dijo a un usuario que los inicios de sesión estaban restringidos a un dispositivo. El cofundador de Cursor respondió en Reddit que "we have no such policy", y el hilo de Hacker News sobre ello superó los 600 comentarios. Un agente de IA con una política obsoleta o ausente no se queda callado. Rellena el hueco.

Un despliegue de cambio de política paso a paso

Este es el calendario que usaría para cualquier cambio de cara al cliente, desde un retoque de redacción hasta una nueva política de reembolsos. Para un cambio grande, alarga la primera mitad. Para uno pequeño, comprímelo en dos días. El orden se mantiene.

1. Escribe una nota de cambio de una página (día -7)

Antes de que nadie edite nada, anota cinco cosas en una página:

• La regla antigua y la nueva, palabra por palabra.
• La fecha y hora de entrada en vigor, con zona horaria.
• A quién se aplica. Esta es la pregunta de respetar lo anterior: ¿un pedido hecho el día 3 recibe los 30 días antiguos o los 14 nuevos? Elige una fecha de corte (la fecha del pedido es la más común) y escríbela.
• Las excepciones y quién puede aprobarlas, con números. "El jefe de equipo puede aprobar devoluciones hasta 30 días para pedidos de menos de 200 $" se puede seguir. "Usa tu criterio" no.
• El motivo en una frase que puedes dar a los clientes.

Esa última línea importa más de lo que la gente cree. Los agentes que pueden explicar por qué cambió una regla manejan las quejas con calma. Los que no pueden acaban disculpándose por ella, y los clientes lo leen como "esta regla es negociable". Si ya tienes un SOP de atención al cliente para reembolsos, la nota de cambio se convierte en el diff que le aplicas.

2. Inventaría cada copia (día -7 a día -5)

Repasa los siete lugares enumerados arriba. Exporta las macros a una hoja de cálculo y busca los números y frases antiguos, no solo el nombre de la política. Busca en tu centro de ayuda los mismos términos. Revisa cada idioma.

Luego usa los datos de uso para priorizar. Zendesk puede ordenar macros por uso durante los últimos 30 días en Suite Growth y superiores. Freshdesk tiene un informe de uso de respuestas predefinidas, Front tiene un informe de plantillas de mensajes, y Gorgias te permite monitorizar el uso de macros desde la lista de macros. La respuesta que tu equipo envía 50 veces al día se arregla primero.

3. Prepara las ediciones para que cambien a la vez (día -5 a día -3)

El objetivo es que cada copia cambie en el mismo momento. Cuánto ayuda el helpdesk depende mucho de tu plan.

Zendesk tiene las mejores herramientas y bloquea la mayoría tras Enterprise. Los content blocks te permiten escribir el párrafo de la política una vez y reutilizarlo en varios artículos. Edita el bloque y se actualiza cada artículo que lo usa, sin republicar. Si estás en un plan inferior, mi guía de gestión del conocimiento en Zendesk cubre las alternativas manuales. La publicación y despublicación programadas son solo Enterprise, en incrementos de una hora, y puedes aplicar la programación a todas las traducciones a la vez.

Una trampa de Zendesk: si más tarde restauras una versión antigua de un artículo que contenía un content block, Zendesk desvincula el bloque y pega su texto en el artículo. Ese artículo deja de recibir actualizaciones del bloque, así que el siguiente cambio de política lo pasa por alto en silencio. Mi entrada sobre el historial de versiones de artículos de Zendesk cubre el resto de herramientas de revisión.

HubSpot (Service Hub Pro y superiores, donde vive la base de conocimiento) tiene aquí un detalle útil: Schedule update, que prepara una edición de un artículo ya publicado y la publica en tu fecha de entrada en vigor.

Freshdesk muestra un diff "Show changes" en cada versión guardada, y después de editar el artículo principal ofrece marcar otras traducciones como desactualizadas. Un paso formal de aprobación (Draft, In Review, Approved) es solo Enterprise.

Gorgias mantiene las ediciones de un artículo o guidance publicados como borradores, y la documentación es clara: "AI Agent does not use drafts in real customer conversations." Cuando publicas un cambio en la base de conocimiento, puedes añadir un resumen del cambio. El ejemplo de la propia Gorgias es "updated return window from 15 to 30 days" (fuente).

Front y Help Scout tienen borradores e historial de versiones, pero ninguna publicación programada en la documentación que revisé, así que en ellos editas en vivo el día señalado. Zoho Desk tiene una función que nadie más tiene para políticas con límite de tiempo: una fecha de caducidad de artículo que retira el artículo del centro de ayuda automáticamente, con correos al propietario 7 días antes, el día anterior y el mismo día. Es perfecto para una ampliación de devoluciones en vacaciones.

4. Informa a los agentes (día -3)

Aquí hay un hueco que no esperaba: ninguno de los tres grandes helpdesks que investigué más de cerca (Zendesk, HubSpot, Help Scout) documenta una función de anuncios integrada para agentes. Las actualizaciones de política salen por Slack, correo o la reunión del equipo, y el helpdesk solo ayuda en el momento de uso. El panel de conocimiento de Zendesk muestra artículos dentro del ticket, y los playbooks de HubSpot pueden incrustar un artículo en el registro del ticket.

Así que el briefing corre de tu cuenta. Lo que funciona:

• Comparte la nota de cambio de una página en tu base de conocimiento interna, no solo un enlace al artículo nuevo.
• Repasa los tres tickets que esperas con más frecuencia: el cliente que compró antes de la fecha de corte, el cliente que compró después y está enfadado, y el caso límite.
• Da a los agentes la redacción exacta para "por qué cambió esto" y el límite exacto de excepción que pueden aprobar sin preguntar.
• Diles dónde está la macro nueva y que la antigua va a desaparecer.

El modo de fallo cuando esto se omite le resulta dolorosamente familiar a cualquiera que haya trabajado una cola. Un hilo de r/callcentres preguntando cómo se enteran los equipos de los cambios de política estaba lleno de respuestas como esta:

"Emails get buried so fast man I swear I will find a important update like 3 days later after already giving wrong info to 10 customers. The knowledge base is good when they actually update it but half the time someone forgot to change the article and then supervisor says oh yeah they sent email about that last week"

u/RaspyStoppage, Reddit r/callcentres

El único canal que, según la gente de ese hilo, llegaba de forma fiable era una reunión diaria breve antes del turno. Usa una el primer día de un cambio grande, aunque tu equipo nunca haga reuniones.

Si das feedback regular a los agentes, añade la regla nueva a la hoja de evaluación de QA durante el primer mes. Un escenario de formación construido a partir del tipo de ticket complicado es la forma más rápida de dar confianza a los agentes nuevos.

5. Publica todo el día 0

En la fecha de entrada en vigor, cambia todo de una sentada:

1. Publica el artículo nuevo (o deja que lo haga la programación) y despublica o redirige el antiguo.
2. Actualiza o sustituye cada macro de tu inventario (macros de Gorgias y respuestas predefinidas de Freshdesk admiten reimportación por CSV). Archiva las macros antiguas en vez de borrarlas si puedes necesitar el historial. En Gorgias archivar es recuperable, borrar es permanente (fuente).
3. Actualiza la IA. Edita o elimina la regla antigua en tu herramienta de IA y resincroniza cada fuente externa que contenga la política. En Gorgias, resincroniza el sitio web de la tienda. En Front, Freshdesk y Help Scout, resincroniza cualquier fuente de sitio web o documento.
4. Desactiva lo que no puedas arreglar hoy. Desactiva el snippet obsoleto, despublica el PDF antiguo, apaga la fuente.
5. Actualiza los flujos de chatbot y las plantillas de correo automáticas.

En Zendesk Enterprise hay un truco más que vale la pena copiar. Zendesk mismo sugiere desverificar artículos en bloque después de un cambio grande (su ejemplo es un cambio de nombre de marca). Cada artículo que desverificas va a una lista "Needs verification", y los propietarios reciben correos cada dos semanas hasta que lo confirman. Para un cambio de política, desverifica cada artículo que apareció en tu búsqueda por palabras clave y deja que la lista persiga a la gente por ti.

6. Prueba la IA antes que los clientes (día 0 a día 1)

Escribe diez preguntas de prueba tal como las formulan los clientes: "¿puedo devolver esto todavía? lo compré el 2", "¿por qué hay una tarifa ahora?", "vuestra web decía 30 días". Hazle cada pregunta a la IA y lee la respuesta y su fuente.

La mayoría de los helpdesks ya tienen un lugar para hacerlo con seguridad. El AI Agent Studio de Freshdesk tiene una pestaña Test que ejecuta hasta 100 consultas a la vez, y un modo sombra del agente de IA de correo que redacta respuestas como notas privadas. Gorgias te permite probar un borrador en Playground antes de publicar, usando toda tu configuración en vivo con el borrador cambiado. El Autopilot de Front tiene una simulación que ejecuta escenarios que tú escribes.

Presta especial atención al caso de respetar lo anterior. Los agentes de IA son buenos citando una regla y menos buenos con "depende de la fecha de tu pedido" a menos que les digas cómo comprobarlo. Si la IA no puede consultar la fecha del pedido, la instrucción correcta es escalar esos tickets, no adivinar.

7. Busca la redacción antigua (día 14)

Dos semanas después, busca en tus respuestas enviadas los números y frases antiguos. Cada resultado es una copia que se te pasó. Rezagadas habituales: la macro personal de un agente, una plantilla dentro de una automatización, un artículo traducido, un PDF que la IA aún tiene.

Front documenta una forma inteligente de cazar copias enviadas automáticamente: crear una regla que etiquete los mensajes salientes cuyo cuerpo contenga un fragmento único de la plantilla, ya que el informe de plantillas no cuenta las respuestas automáticas. La misma idea funciona en cualquier sitio donde puedas etiquetar por contenido del mensaje.

Luego pon la revisión en un calendario, igual que harías con el contenido desactualizado del centro de ayuda en general. Las revisiones programadas de artículos de Front (plan Professional y superiores) envían a los revisores un recordatorio diario de los artículos pendientes, y las reglas de verificación de Zendesk pueden volver a marcar los artículos de política cada pocos meses.

Hoja de referencia de cambio de política para tu helpdesk

Cada helpdesk gestiona de forma distinta las cuatro tareas de un despliegue: preparar el artículo, encontrar respuestas antiguas, lograr que la IA se entere y probar antes que los clientes. Elige el tuyo.

Cómo tratar a los clientes durante la transición

Los tickets de las dos primeras semanas vienen sobre todo de gente que leyó la regla antigua en algún sitio. Unas cuantas cosas los hacen mucho más fáciles.

Respeta la versión que vieron, dentro de lo razonable. Si un cliente puede mostrarte la redacción antigua en tu propio sitio o en tu propio correo, lo más barato casi siempre es respetarla una vez y corregir la copia. Eso es, más o menos, lo que acabarías haciendo de todos modos según la sentencia de Air Canada.

Escribe una macro de transición. Si necesitas un punto de partida, adapta una de estas plantillas de macros de reembolsos y devoluciones. Una respuesta que diga: la política cambió en esta fecha, este es el motivo, esto es lo que se aplica a tu pedido y esto es lo que puedo hacer por ti. Los agentes no deberían improvisar eso 40 veces al día.

Da a los agentes un límite de excepción real. Si un agente tiene que escalar cada pregunta de respeto a lo anterior, tu cola se duplica durante dos semanas. Un límite claro en dinero o días que puedan aprobar por su cuenta mantiene los tickets en movimiento.

Las excepciones incoherentes son lo que convierte un cambio de política en una pelea larga. Los trabajadores del comercio lo saben bien:

"Yup, customers have definitely played the "but the other guy did it for me!" card and it sucks because now there's precedent"

u/ralphcorleone, Reddit r/retailhell

Una solución del mismo hilo: los gerentes introducen su propio código para las devoluciones fuera de política, de modo que cada excepción lleva un nombre. En un helpdesk, el equivalente es una nota interna y una etiqueta en cada ticket de excepción.

Etiqueta los tickets. Añade una etiqueta como policy-change-returns a cada ticket sobre el cambio. Tras un mes sabrás a cuántos clientes afectó, a qué se opusieron y si el cambio necesita una mejor explicación en la página de la política. Si usas el etiquetado de tickets con IA, esto ocurre sin que nadie tenga que acordarse.

Errores comunes

• Actualizar el artículo principal y darlo por terminado. Es una copia de seis o siete.
• Dejar la versión antigua activada junto a la nueva. Dos copias en conflicto convierten a la IA en un cara o cruz, como muestra el ejemplo de 30 frente a 14 días de Gorgias.
• Olvidar las fuentes externas. Un PDF de política subido a la herramienta de IA, un Google Doc, una página de política rastreada. Son las copias más lentas de refrescar.
• No decidir de antemano la regla de respeto a lo anterior. Cada agente inventará la suya, y los clientes compararán notas. Un comentarista de Hacker News, al reaccionar ante un proveedor que canceló planes anuales prepagados para subir precios, escribió que "actually stick with them" si los planes prepagados se hubieran respetado.
• Entrenar la IA con tickets antiguos. Si tu IA aprende de respuestas pasadas, los tickets de los últimos seis meses le enseñan todos la regla antigua. Filtra la fuente de tickets a después de la fecha del cambio cuando tu herramienta lo permita.

Cómo gestiona eesel un cambio de política

Te cuento sin rodeos por qué me importa tanto esto: ayudar a los equipos a desplegar cambios de reglas a su compañero de IA es una parte importante de lo que hago en la cola de soporte de eesel. Y el equipo tiene cicatrices aquí. Al principio, eesel tuvo clientes que volvían a enseñar al agente reglas que creían haber guardado ya en un chat anterior. Por eso el producto actual muestra cada regla guardada en una única página de Instructions que puedes leer y editar, y por eso ahora le digo a todo el mundo que revise esa página después de cualquier cambio.

Así funciona un cambio de política con el compañero de IA para helpdesk de eesel, paso a paso.

Los hechos van en documentos, las reglas van en instrucciones. La documentación de eesel es directa en esto: no pongas precios ni políticas en las instrucciones del agente. Tu agente responde preguntas factuales buscando en el conocimiento conectado, y las instrucciones gobiernan "tone, policy and escalation". Es la misma razón por la que la recuperación supera al fine-tuning en los centros de ayuda: cambias un documento, no un modelo. En la práctica, el texto de la nueva política de devoluciones vive en tu artículo del centro de ayuda o en un documento, y la regla de comportamiento ("pregunta antes de aprobar cualquier devolución de más de 14 días") vive en las instrucciones.

Cambiar una regla edita la regla antigua. Cuando corriges al agente en el chat ("cambiamos el plazo de devolución a 14 días, los pedidos anteriores al día 1 siguen teniendo 30"), primero lee sus instrucciones actuales. Si una regla ya cubre el punto, edita esa regla en lugar de añadir una línea nueva. Eso es exactamente el problema de las copias en conflicto de antes, resuelto en origen.

Así se ve en una configuración real. Un administrador de soporte en Zendesk le enseñó al agente su regla de cancelaciones con palabras sencillas:

"I have a rule in CS where we do not address a cancel or refund request when there is an issue attached to it."

Es un administrador de soporte codificando una política de "soluciona el problema antes de cancelar", y cuando el agente redactó más tarde una respuesta de cancelación demasiado pronto, la corrección del administrador fue una línea: "This is incorrect. You have not provided troubleshooting steps yet." Esa es toda la interfaz: dile qué estaba mal, di que sí cuando ofrezca conservar el cambio, y la corrección se convierte en una regla en la página de Instructions.

Conoce cómo se actualiza cada fuente. Aquí es donde yo iría más despacio, porque es el mismo problema de documentos externos que tiene cada helpdesk:

Todo esto viene de la documentación de conocimiento de eesel. La fila de Google Drive es la que hay que vigilar. Si tu nueva política es un Google Doc nuevo en lugar de una edición del antiguo, una resincronización no lo encontrará, y el documento antiguo sigue indexado hasta que lo quites. Edita el documento existente o vuelve a elegir la carpeta. Un detalle más de Zendesk: los borradores del centro de ayuda se excluyen salvo que los incluyas, así que un borrador del artículo nuevo no se filtrará en las respuestas antes de tiempo.

Pruébalo con tickets reales antes de que esté en vivo. El skill de simulación de eesel reproduce tus tickets pasados reales (o casos de prueba que escribe por ti) sin enviar nada, y puntúa cada respuesta frente a lo que tu equipo realmente envió. Una salvedad para los cambios de política: la referencia son las respuestas de tu equipo bajo la política antigua, así que un "desajuste" en el tema cambiado puede ser la respuesta correcta. Yo le pediría que genere casos de prueba específicamente para la nueva regla y leería los resultados del resto para asegurarme de que nada más se movió.

Retén el tema de riesgo para aprobación durante la transición. Cada acción puede ajustarse a Auto, Needs approval o Disabled, y puedes retener un tema incluso con las respuestas en Auto con una instrucción como "pregunta antes de responder cualquier cosa sobre reembolsos" (documentación de aprobaciones). Durante la primera semana tras un cambio de política de reembolsos, eso es lo que haría, y así configuraría en general la IA para solicitudes de reembolso. Además, cada borrador nombra el artículo del centro de ayuda que usó, para que veas de un vistazo si leyó la versión nueva.

Precios. El plan Free de eesel incluye 100 créditos sin tarjeta. Los planes Teammate empiezan en 299 $ al mes por 500 créditos, y un ticket o chat cuenta como un crédito sin importar cuánto dure. Las preguntas que haces en el panel (como probar tus diez preguntas de política) son en su mayoría gratuitas.

Lo que eesel no hace: no reemplaza las herramientas de artículos de tu helpdesk. Los content blocks, la publicación programada y las listas de verificación siguen en Zendesk o donde esté tu centro de ayuda. eesel es el compañero que lee el resultado y responde a partir de él.

Prueba eesel en tu próximo cambio de política

Si tu próximo cambio de política te preocupa más por la IA que por el centro de ayuda, prueba eesel. Se une a tu helpdesk existente como compañero de IA, lee tu centro de ayuda, tus macros y tus documentos, y acepta cambios de reglas en frases sencillas. Puedes reproducir tickets pasados reales contra la nueva regla antes de que los clientes vean una sola respuesta. El plan gratuito incluye 100 créditos y todas las integraciones.

Probar eesel