Resumen
Para hacer un piloto de soporte con IA, dale cuatro semanas y un carril estrecho. La semana 0 es de planificación: elige dos o tres tipos de ticket que la IA pueda responder directamente desde tus documentos, anota tu línea base y tus umbrales de aprobación, y monta una cola de IA junto a una cola de control solo humana para los mismos tickets. La semana 1 es el modo sombra, en el que la IA solo redacta borradores y tu equipo los puntúa. En la semana 2 responde a clientes en el 10 al 20 % del carril. En la semana 3 amplías a cerca de la mitad. En la semana 4 no cambias nada y dejas que los números se asienten, y una semana después decides: ampliar, corregir y repetir la prueba, o parar.
La parte que los equipos se saltan es la revisión diaria. Quince minutos al día leyendo los tickets de IA de ayer, cada acción que tomó y cada conversación reabierta es donde se ganan los pilotos. Cada fallo se remonta a una de cuatro causas (una laguna de conocimiento, una instrucción, datos que faltan o el enrutamiento), y cada una tiene una solución distinta. Reembolsos, cancelaciones y cambios de cuenta quedan fuera del piloto, o tras una aprobación humana, hasta que el carril de solo respuestas esté limpio.
Si quieres un piloto que ya funciona así: eesel reproduce tus tickets pasados para darte una puntuación antes del primer día, empieza como borradores dentro de Zendesk, Freshdesk, Gorgias o HubSpot y registra cada acción para tu revisión diaria. XAP empezó con una sola porción, tickets de derivación redactados como notas internas, y va ampliando el filtro desde ahí. El plan gratuito te da 100 créditos para probarlo en tu propia cola.
Por qué la mayoría de los pilotos de soporte con IA fallan en la semana dos
Yo atiendo la cola de soporte de eesel, así que veo los pilotos desde dentro: las preguntas de configuración en la semana uno y luego los mensajes de «¿esto es normal?» en la semana dos. Los pilotos que se atascan rara vez lo hacen porque la IA sea mala. Casi siempre es porque nadie se encarga de leer cada día lo que hizo la IA, porque el alcance se amplía antes de que el primer carril esté limpio y porque entonces entran tres cambios la misma tarde y nadie sabe cuál rompió las respuestas de devoluciones.
Aquí va un caso real. Un equipo danés de telemática de vehículos en Zendesk descubrió que su bot decía a los clientes «sí, admitimos el modelo de su coche» para marcas que no estaban en su base de datos. El modelo no se lo inventaba de la nada. Un artículo de ayuda decía que el producto admitía todos los modelos, y la IA se lo creyó. Su propio resumen de la configuración fue «trial and error in the beginning», que es honesto y es justo el trabajo de un piloto: encontrar las frases de tu base de conocimiento que están mal de una forma que un agente humano esquivaría en silencio.
Por eso planificaría un piloto como un proyecto de operaciones, no como una prueba de software. El patrón que funciona, en la mayoría de los equipos con los que hablo, es el que la gente pide de todos modos: empezar con la IA redactando respuestas para los agentes y dejar que responda sola a los clientes cuando los borradores sean correctos.
"The safest rollout I have seen is: let the agent draft, tag confidence plus reason, require approval for refunds or account changes, and review every reopened conversation for the first month. That review log is usually where the real automation boundary shows up."
Este artículo es un manual para esas cuatro semanas. Si quieres la parte de medición (qué va en la scorecard y cómo puntuarla), está en la scorecard del piloto de soporte con IA. Para la secuencia de pruebas previa al lanzamiento con más detalle, consulta pruebas de agentes de soporte con IA.
Qué preparar antes de la semana uno
La semana 0 son unas horas de trabajo repartidas en varios días, y es lo que decide si el resto del piloto se puede leer siquiera. Hay cinco cosas que deben cumplirse antes de que la IA vea un solo ticket real.
- Un responsable, con nombre. La persona que hace la revisión diaria, aprueba los cambios y puede ordenar una pausa. En equipos pequeños suele ser el responsable de soporte. No debería ser la misma persona que montó la configuración, por la misma razón por la que la propia guía de pruebas de Zendesk te dice que «select testers who aren't the same people who built your conversation flows».
- Una línea base. Las cifras del último trimestre para los tipos de ticket incluidos: volumen semanal, tiempo de primera respuesta, tasa de reapertura o recontacto y también lo que te cuesta un ticket gestionado por una persona. La guía de KPIs de servicio al cliente explica cómo sacarlas.
- Umbrales de aprobación por escrito. Qué tiene que cumplirse al final para que amplíes. Yo copiaría los umbrales y objetivos de la scorecard del piloto en vez de inventar otros, y se los enviaría al proveedor antes del primer día.
- Un plan de enrutamiento. Qué tickets van a la cola de IA, qué tickets idénticos se quedan en una cola de control solo humana y cómo vas a etiquetar ambas para poder sacarlas después. Más sobre esto abajo.
- Un plan de pausa. Quién puede apagar la IA, dónde está el interruptor en tu helpdesk y qué cuenta como motivo para usarlo.
Después cuéntale a tu equipo de soporte qué está pasando y cuál es su papel. Los agentes que se enteran del piloto por la queja de un cliente tratarán a la IA como una amenaza durante meses. A los agentes a quienes se les dice «vosotros sois los revisores, y la IA se queda con el montón de estado de pedido» se convierten en tu mejor fuente de informes de fallos. Un SOP de soporte para el piloto (quién revisa, cuándo, dónde marcar una mala respuesta) se escribe en diez minutos y ahorra muchos hilos de Slack.
| Rol en el piloto | Quién | Tiempo que lleva |
|---|---|---|
| Responsable del piloto | Responsable de soporte o agente senior que no montó la configuración | 15 a 20 minutos al día, más un informe semanal |
| Revisores | 2 o 3 agentes, idealmente uno más nuevo | 10 minutos al día cada uno en la semana 1, menos después |
| Corrector de conocimiento | Quien se encargue de tu centro de ayuda | Unas pocas correcciones por semana, sobre todo en las semanas 1 y 2 |
| Contacto de escalado | Alguien con autoridad sobre reembolsos y cuentas | Solo cuando un traspaso requiere una decisión |
Cómo elegir los tickets para un piloto de soporte con IA
La mayoría de los equipos ordena los candidatos del piloto por tema. Yo prefiero ordenarlos por lo que la IA tiene que hacer para cerrar el ticket, porque ahí está el riesgo. Hay tres tipos:
- Respuestas desde tus documentos. Política de devoluciones, plazos de envío, preguntas de cómo hacer algo. Si la IA se equivoca, el cliente recibe una frase equivocada y la solución suele ser solo un artículo.
- Consultas de solo lectura. Estado del pedido, seguimiento, detalles del plan. La IA lee un sistema y cuenta lo que encontró. Equivocarse aquí significa leer el pedido o el estado equivocado, lo cual es peor pero sigue sin cambiar nada.
- Acciones sobre dinero o cuentas. Reembolsos, cancelaciones, cambios de dirección, ediciones de cuenta. Equivocarse aquí significa que ya ha pasado algo que ahora tienes que deshacer.
El piloto empieza con el primer tipo y añade el segundo en la semana 3 si la revisión diaria está limpia; el tercero espera hasta después del piloto, tras una aprobación. Esa separación también coincide con cómo los proveedores configuran sus propias pruebas: Gorgias, por ejemplo, mantiene las acciones desactivadas por defecto en las conversaciones de prueba porque, si se activan, «can affect real customer and order data (like cancelling an order)».
Hay dos filtros más antes de que un tipo de ticket entre. Tus documentos ya tienen que responderlo (si no, es trabajo de un análisis de lagunas de conocimiento en la semana 0, no un hallazgo del piloto). Y necesita volumen, porque un carril de 15 tickets a la semana no te dirá casi nada en un mes. Las preguntas de estado del pedido son la favorita habitual por esta razón: mucho volumen, una consulta y poco riesgo.
Los juicios de criterio (quejas, contracargos, clientes molestos) se quedan con personas durante todo el piloto. Un profesional lo expresó bien:
"Splitting it by impact makes more sense to me. A slightly awkward response is one thing but anything involving pricing, refunds or account changes should have a much higher bar."
Estrecho está bien. XAP, que desarrolla software de preparación universitaria y profesional, empezó su configuración de eesel en Freshdesk con una sola porción: tickets en los que un estudiante pregunta por algo que gestiona su universidad o una agencia estatal, que necesitan una derivación educada y exacta. Un filtro deja pasar solo esos casos (más los restablecimientos de contraseña del portal), y entonces eesel redacta la respuesta completa como nota interna a partir de la respuesta predefinida del equipo y una persona la envía. En su historia llaman al agente de derivación «the first slice», y el filtro se está ampliando a medida que el equipo añade casos de derivación para sus otros portales. Eso es un carril de piloto bien hecho: pequeño, respondible y fácil de comprobar.
Introduce tu propia mezcla de tickets para ver en qué carril cae cada tipo y si el carril tiene volumen suficiente para juzgar al final de la semana 4.
Si el carril se queda corto, añade otro tipo de ticket de respuesta antes de alargar el calendario. Un piloto más largo sobre un carril escaso casi solo da más tiempo para que el alcance se desborde.
Cómo separar una cola de IA y una cola de control en tu helpdesk
Quieres los mismos tipos de ticket, en el mismo canal, gestionados de dos maneras durante las mismas semanas: unos por la IA, otros solo por personas. El artículo de la scorecard explica por qué la cola de control solo humana importa para las cifras. Aquí está dónde viven los controles en cada helpdesk, comprobado en el centro de ayuda de cada proveedor el 20 de octubre de 2026.
| Helpdesk | Acota el carril de IA con | Mantén una cola de control mediante | Pausa mediante |
|---|---|---|---|
| Zendesk | Canales por agente de IA; condiciones de activación de un agente de correo | Un trafficSplit aleatorio con grupo de control, activado por tu account manager (prueba A/B), o una dirección de soporte aparte | Desmarcar el canal en Manage channels |
| Freshdesk | Orígenes de ticket, «Deploy to internal teams» o reglas personalizadas con hasta cinco niveles de AND/OR | Una regla personalizada que deje fuera parte del carril (un buzón, un atributo del cliente) | Un límite en Daily conversation limits, o desactivar el agente en ese origen |
| HubSpot | Un canal por despliegue, horario laboral, listas de inclusión y exclusión en el correo | El porcentaje de Conversation coverage (el resto va a personas) | Desactivar la asignación del customer agent |
| Gorgias | AI Agent > Deploy por canal, una skill cada vez | Dejar un canal o una skill desactivados para el carril y comparar | Desactivar una skill «without affecting others» |
| Help Scout | Por Beacon y por bandeja; el correo puede limitarse a «Only customers matching these conditions» | El alcance «except ones matching these conditions» en la misma bandeja | El interruptor Enable por Beacon o bandeja |
Algunos detalles de esas páginas que cambian cómo lo configuras:
- Zendesk solo permite un agente de IA a la vez por canal, y un agente creado para mensajería no puede pasarse luego a correo. Decide primero el canal, antes de construir.
- La salida a producción de Freshdesk solo avanza hacia delante. Los tickets que llegaron antes del despliegue «are not retroactively answered», lo que significa que el día uno del piloto empieza limpio.
- El propio consejo de HubSpot coincide con la rampa de aquí: empieza con «a single channel or limit it to a small percentage of conversations», y luego revisa escalados y lagunas de conocimiento antes de ampliar. Cuando está en pausa, «it keeps existing chats but won't get new ones».
- Gorgias te da vistas de bandeja para los tickets que la IA está gestionando, los que ha cerrado y los que ha traspasado, que es básicamente tu cola de revisión diaria ya construida.
El constructor de condiciones de Help Scout es un buen ejemplo de lo específico que puede ser un carril: la IA solo responde a los tickets que coinciden con una etiqueta o una regla de asignación.
Sea cual sea el helpdesk, etiqueta ambas colas desde el primer día (ai_pilot y ai_control funcionan bien). La guía de etiquetado de soporte con IA tiene más sobre cómo nombrarlas. En la semana 4 querrás volcar ambos conjuntos a una hoja de cálculo sin depender del informe del proveedor.
Semana 1: modo sombra antes de que ningún cliente lo vea
El modo sombra significa que la IA trabaja con tickets reales entrantes de tu carril, pero todo lo que escribe es un borrador o una nota interna. Una persona lo lee y lo puntúa, y luego lo envía, lo edita o lo ignora. Los clientes no ven ninguna diferencia. No tiene riesgo para el cliente y es donde aparecen la mayoría de los problemas corregibles.
Antes de que empiece la semana sombra, ejecutaría la IA sobre tus tickets pasados para que entres con una puntuación en vez de una suposición. La mayoría de los helpdesks ya tienen alguna forma de hacerlo sin pagar:
- La evaluación del AI Agent de correo de Freshdesk puede Import tickets «to use solved historical tickets», hasta 50 consultas por ejecución, y Freshworks recomienda «at least 20 representative queries before deploying». La vista previa «does not affect live conversations or consume message limits».
- Las pruebas por lotes de HubSpot construyen preguntas de prueba a partir de temas de tus conversaciones reales, y previsualizar o probar no consume HubSpot Credits.
- Las conversaciones de prueba de Gorgias «are free to use» y pueden reproducir «an existing ticket», una a una.
- El sandbox, el widget de prueba y el simulador de conversaciones de Zendesk no consumen resoluciones automatizadas, pero un agente de correo probado en producción sí. La guía de configuración de sandbox en Freshdesk cubre el equivalente en ese lado.
Durante la propia semana sombra, pide a los revisores que puntúen cada borrador de una de tres maneras: enviar tal cual, enviar con cambios o incorrecto. Anota una nota breve en cada «incorrecto». Para el viernes tendrás una lista, y esa lista es tu plan de correcciones para la semana 2. Añade también algunos tickets deliberadamente incómodos, de los insistentes del tipo «te equivocas, devuélveme el dinero»; la guía de pruebas adversarias tiene un conjunto para tomar prestado.
Espera muchos «enviar con cambios» al principio, y no te alarmes. En la prueba de una joyería con eesel, la mayoría de las ediciones que hicieron los agentes en los borradores eran sobre la longitud y el tono, el tipo de cosa que mejora cuando la IA aprende de las respuestas enviadas del propio equipo. Las ediciones que corregían un error de hecho eran solo una parte pequeña. Es un hallazgo muy distinto de «la IA se equivoca», y solo lo ves si los revisores dicen por qué editaron.
La prueba de salida de la semana 1 es sencilla: el montón de «incorrecto» es pequeño y cada elemento tiene o bien una corrección que has hecho o bien un motivo por el que ese tipo de ticket debe salir del carril.
Semanas 2 y 3: salir a producción con una porción y luego ampliar
En la semana 2 la IA empieza a responder a clientes, pero solo en una parte del carril. Yo empezaría con el 10 al 20 %. El campo de cobertura de HubSpot lo hace directamente; en otros helpdesks lo consigues con una regla sobre un atributo del cliente o con un buzón. El resto del carril se queda con personas, lo que hace de cola de control.
Tres reglas para estas dos semanas:
- Amplía solo tras un tramo limpio. Si la revisión diaria ha estado limpia tres o cuatro días laborables, pasa de cerca del 20 % a cerca de la mitad en la semana 3. Si no, quédate donde estás y arregla primero.
- Cambia una cosa a la vez y anota la fecha. Ampliar el carril y añadir una instrucción nueva el mismo día significa que no puedes saber cuál movió las cifras. Swiftreg, que vende matrículas personalizadas en el Reino Unido, mantiene sus instrucciones de soporte en eesel como versiones numeradas que se despliegan con su propio procedimiento en vez de editarse en vivo. Es más proceso del que necesitan la mayoría de los pilotos, pero el hábito (cada cambio tiene versión y fecha) es el correcto.
- Añade consultas de solo lectura antes que acciones. Si la semana 2 estuvo limpia con tickets de solo respuesta, la semana 3 es cuando pueden sumarse el estado del pedido y el seguimiento. Las acciones siguen apagadas.
Haz evidente el camino «hablar con una persona» desde el primer día en vivo. Los clientes que se quedan atascados y no encuentran a un humano no aparecen como fallos en la mayoría de los paneles; aparecen como conversaciones abandonadas o tickets enfadados en otro canal. La lista sobre el traspaso de agentes de IA cubre qué debe llevar un traspaso para que tu agente no tenga que volver a preguntar.
En cuanto a la transparencia, yo diría a los clientes que están hablando con una IA. Swiftreg termina cada respuesta pública de la IA con un pie que dice que la escribió el AI Support Assistant y que puede contener errores, y el chat en vivo de HubSpot muestra «Powered by AI» en la cabecera mientras el customer agent está asignado. Eso fija las expectativas y también hace más fácil perdonar una respuesta equivocada.
La revisión de QA diaria que decide tu piloto
Este es el hábito que separa los pilotos que acaban en una decisión clara de los que acaban en una discusión. Quince minutos, a la misma hora cada día, desde la semana sombra hasta el final de la semana 4.
Qué entra en esos quince minutos:
- Cada acción que tomó la IA, si hay alguna activada. Lee el registro, no solo la respuesta. Una respuesta puede leerse perfecta y aun así apoyarse en el número de pedido equivocado.
- Cada conversación reabierta o de recontacto de la cola de IA. Son los fallos que el panel cuenta como aciertos.
- Cada traspaso. ¿Recibió la persona suficiente para seguir sin volver a preguntar?
- Una muestra del montón de «resueltos», de 10 a 20 al día. Gorgias sugiere revisar «at least 10 tickets that AI Agent handled» en la primera semana como parte de la salida a producción; yo mantendría ese ritmo durante todo el piloto.
Después etiqueta cada fallo por su causa, porque cada causa tiene una solución distinta y también un responsable distinto:
| Causa del fallo | Cómo se ve | La solución | Quién lo arregla |
|---|---|---|---|
| Laguna de conocimiento | Respondió con un artículo obsoleto o ausente («we support all models») | Editar o añadir el artículo; volver a probar el tema | Responsable del centro de ayuda (auditoría de la base de conocimiento) |
| Instrucción | Datos correctos, comportamiento incorrecto: demasiado largo, tono equivocado, no traspasó | Añadir o ajustar una regla | Responsable del piloto |
| Datos que faltan | Necesitaba un pedido, una cuenta o un sistema que no puede ver | Conectar la fuente, o sacar el tipo de ticket del carril | Quien se encargue de la integración |
| Enrutamiento | Un ticket que no debía estar en el carril llegó a él | Ajustar el filtro o el disparador | Administrador del helpdesk |
Lleva un registro de cambios compartido con tres columnas: la fecha y qué cambió, y luego por qué cambió. La guía de pruebas de Zendesk sugiere lo mismo para los probadores, un archivo compartido para «track whether a resolution has been implemented». Cuando una cifra se mueve en la semana 3, el registro te dice si fue el artículo que corregiste el martes o el carril que ampliaste el miércoles. Si dos revisores no coinciden en si una respuesta fue «incorrecta», una breve sesión de calibración de QA fija el criterio antes de que el desacuerdo se convierta en ruido en tus resultados.
El responsable de esta revisión no tiene que ser técnico. En Norden-Frisia, una naviera alemana a las islas del Mar del Norte, la responsable de soporte Frauke Hagen lleva sola la configuración de eesel: comprueba el historial de conversaciones y pregunta cuando una respuesta contradice las FAQs, y copia las correcciones del bot de Zendesk al chatbot por su cuenta. Su prueba duró solo una semana, y el entrenamiento con tickets pasados fue lo que decidió la suscripción.
"I think the key is testing the decision separately from the conversation. An agent can have a perfectly polite chat and still issue a refund it wasn't allowed to. If it has to state which policy and limit it applied before it takes any action, you can check that against the rule instead of reading through transcripts."
Cuándo pausar un piloto de soporte con IA a mitad de camino
Escribe las reglas de pausa en la semana 0 para que nadie tenga que discutirlas en un mal martes. Yo pausaría la cola de IA el mismo día si ocurre cualquiera de estas cosas:
- Una acción equivocada llegó a un cliente: un reembolso al pedido equivocado, un cambio en la cuenta equivocada.
- La IA afirmó una política que no existe, o prometió algo que tu equipo no puede cumplir.
- Se dispara el porcentaje de clientes que piden una persona en comparación con los días anteriores.
- Cambió una política y el conocimiento no se ha puesto al día. Un nuevo plazo de devolución, nuevos precios o una caída. Pausa hasta que los artículos estén actualizados y luego vuelve a probar ese tema. La guía de gestión de cambios de política tiene una lista de comprobación.
Pausar es barato si sabes dónde está el interruptor. En Zendesk se hace desmarcando el canal; no hay un botón de pausa aparte.
HubSpot te permite «manually pause customer agent assignment by turning it off», algo que sugiere «when updating or reviewing content sources or making changes to the agent's configuration». El límite diario de Freshdesk es el freno más suave: «Conversations continue to arrive but the AI stops replying once the limit is reached». Uses el que uses, una pausa no significa un piloto fallido. Anótala con la fecha y el motivo, haz un breve análisis de errores de qué la causó y reinicia el reloj de ese carril una vez corregido.
Semana 4 y después: ampliar, repetir la prueba o parar
La semana 4 es una semana de contención. Sin tipos de ticket nuevos ni cambios de cobertura, tampoco instrucciones nuevas salvo que algo esté roto de verdad. Dejas que los últimos cambios se asienten para que la última semana refleje una configuración estable. Luego fija la reunión de decisión una semana después de que termine el piloto, porque las ventanas de resolución de los proveedores y tu propia comprobación de recontacto necesitan algo de tiempo para terminar de contar (la scorecard explica los tiempos).
La decisión en sí es una de tres, y cada una significa algo concreto para el mes siguiente:
| Decisión | Cuándo | Qué haces después |
|---|---|---|
| Ampliar | Se cumplieron los umbrales y los objetivos en el carril | Sube un peldaño: añade el siguiente tipo de ticket de respuesta, o consultas de solo lectura, o un canal más. De uno en uno, con la misma revisión diaria |
| Corregir y repetir la prueba | Seguro, pero por debajo del objetivo | Trabaja las causas principales de tu registro de cambios, vuelve a ejecutar la reproducción de tickets pasados y luego dos semanas más en el mismo carril |
| Parar | Falló un umbral, o los clientes volvieron más que en la cola de control | Conserva los artículos depurados y las etiquetas de ticket, anota el motivo y decide si otra herramienta o un carril más estrecho merece un segundo piloto |
«Ampliar» es donde la mayoría de los equipos quiere saltar directamente a los reembolsos. Yo mantendría las acciones un ciclo más y las pasaría antes por flujos de aprobación: la IA prepara el reembolso y una persona lo aprueba, y luego cuentas con qué frecuencia la persona no está de acuerdo. Cuando esa cifra esté cerca de cero durante unas semanas, las acciones rutinarias pueden ejecutarse solas. Los reembolsos grandes, los contracargos y todo lo que supere los límites de tu matriz de aprobación de reembolsos se quedan con personas.
Errores que veo cuando los equipos hacen un piloto de IA
- Sin un responsable con nombre. La revisión diaria se convierte en «quien tenga tiempo», que es nadie el jueves.
- Pilotar los tickets más difíciles para «probarla de verdad». Aprenderás que los tickets difíciles son difíciles. Empieza donde la IA puede ganar y amplía desde ahí.
- Todos los canales a la vez. Una mala semana en chat y correo juntos no se puede atribuir a ninguno de los dos.
- Cambiar tres cosas el mismo día. No puedes saber cuál ayudó, ni cuál rompió las devoluciones.
- Saltarse la cola de control porque el antes y el después parece obvio. La mezcla de tickets y la estacionalidad también se mueven.
- Leer el panel del proveedor en vez de los tickets. El panel te dice cuántas conversaciones terminaron, no si eran correctas. La lista más larga está en errores al implantar IA en atención al cliente.
Haz tu piloto de soporte con IA con eesel
eesel es un compañero de IA para el helpdesk que se une a tu cola actual en Zendesk, Freshdesk, Gorgias, HubSpot y otros, y está hecho para pilotarse de la manera que describe este artículo:
- Puntuación de la semana 0 a partir de tu propio historial. La skill Simulation ejecuta tu agente contra tickets pasados reales y puntúa cada respuesta frente a lo que envió tu equipo, y luego sugiere cambios de instrucciones. No envía nada a los clientes.
- Modo sombra por defecto. Empieza con borradores: cada respuesta es un borrador o una nota interna para que una persona la envíe. Le dejas responder de principio a fin lo fácil cuando estés listo, y puedes volver a apagar cualquier cosa en cualquier momento.
- Acciones tras aprobación. Cada acción es Auto, Needs approval o Disabled, y las aprobaciones nunca se ejecutan por su cuenta tras un tiempo de espera. Los reembolsos pueden quedarse en Needs approval durante todo el piloto.
- Una revisión diaria ya preparada. La página Activity lista cada ticket que gestionó, qué buscó, cada acción y quién la aprobó, también con su razonamiento. Cuando lo corriges en el chat junto a una ejecución, la corrección se convierte en una regla en sus instrucciones, de modo que la corrección sigue valiendo la semana que viene.
Los precios son un plan mensual fijo en el que un ticket o un chat cuesta 1 crédito: gratis con 100 créditos sin tarjeta, y luego desde $299/month por 500 créditos. El plan gratuito basta para ver sus borradores sobre tus propios tickets antes de comprometerte a nada. Si estás a punto de empezar un piloto con cualquier proveedor, ejecuta primero la simulación de eesel sobre tu cola y lleva el informe a la comparación. Prueba eesel.