La IA ayuda con los traspasos de turno en soporte de dos maneras, y la segunda importa más. La obvia es escribir mejores notas de traspaso: resumir cada ticket abierto y marcar los que tienen un SLA o una actualización prometida pendiente. La que la mayoría de equipos pasa por alto es que un agente de IA que trabaja la cola entre turnos nunca cambia de turno él mismo, así que menos tickets cruzan la línea, y cada ticket que pasa a una persona llega con una nota escrita en el momento del escalado, no a las 17:55 de memoria.
Lo que realmente se pierde en un cambio de turno rara vez es el contexto. Es el compromiso: "Le dije que le daríamos novedades a las 14:00 UTC", quién es responsable del siguiente paso y las soluciones ya probadas. Una buena nota de traspaso lleva cinco cosas (qué quiere el cliente, qué se probó, qué se prometió y para cuándo, quién es el siguiente responsable, qué pruebas se encontraron), y los resúmenes nativos del helpdesk en Zendesk, Freshdesk y Help Scout cubren bien las dos primeras y el resto solo si un agente lo escribe a mano.
Un compañero de IA como eesel lo hace dentro de tu helpdesk actual. En SE Ranking, un equipo de Zendesk repartido por 16 países y todas las zonas horarias, traspasó unos 1.260 chats a personas en un mes, cada uno con el nombre y el correo del cliente, y dejó unas 2.600 notas internas en tickets. Los planes empiezan en 299 $ al mes por 500 créditos.
¿Por qué se cuelan cosas por las grietas en el cambio de turno?
Porque un traspaso es el único momento en que un ticket no tiene dueño. El agente saliente ya está mentalmente fuera, el entrante todavía no se ha puesto al día, y todo lo que vivía solo en la cabeza del agente saliente simplemente desaparece. Trabajo la cola de soporte de eesel cada día, y los tickets que duelen casi nunca son los difíciles. Son los fáciles, en los que alguien hizo una pequeña promesa y luego nadie la anotó.
Esto es lo que suele colarse, más o menos en orden de cuánto daño hace cada cosa:
- La promesa. "Lo consulto con facturación y te contesto antes de que acabe el día." El ticket parece uno más en pendiente, pero ahora hay un cliente esperando una hora concreta.
- Lo que ya se ha probado. Sin eso, el siguiente agente le pide al cliente que vacíe otra vez la caché, y el cliente lo nota.
- Quién es responsable del siguiente paso. ¿Escalado a ingeniería? ¿Esperando al cliente? ¿En manos de un compañero que ya se ha ido a casa?
- El reloj del SLA. Un ticket que incumple a las 9:15 debe estar arriba de la lista del siguiente turno, no en algún punto intermedio.
- El estado de ánimo del cliente. El tercer contacto de un cliente molesto se lee muy distinto de un primer contacto.
Los clientes también lo notan desde fuera. Un ingeniero en Hacker News describió cómo se veía el soporte de un proveedor de nube cuando un ticket rebotaba entre regiones:
"...instead they keep sending tickets back for "more info", inevitably followed by a hand-off to another team in a different time zone. We have spent days trying to convince them there was an issue before, which just seems unacceptable."
Ese es el coste de un traspaso escaso: el siguiente equipo empieza el diagnóstico desde cero. Tampoco es un problema de nicho; otro comentarista describió el modelo follow-the-sun en términos bastante claros:
"It can absolutely work, given the right async workflows, but it can also absolutely fail. I'm inclined to believe failure is the default mode of operation."
"Los flujos asíncronos correctos" es básicamente todo el juego. La mayoría de equipos intenta arreglarlo con un documento compartido o un hilo de Slack al final de cada turno. Eso funciona más o menos una semana, luego el documento se queda obsoleto, porque escribirlo es lo último que hace un agente cansado antes de desconectarse.
¿Cómo puede ayudar la IA con los traspasos de turno en soporte?
La IA puede hacer cuatro trabajos aquí, y solo el primero es el que describen la mayoría de artículos. Este es el orden en que yo los activaría.
Los números de tickets de este esquema son ilustrativos. Introduce tus propias cifras en la calculadora más abajo.
1. Resumir los tickets abiertos. Es la versión que venden ChatGPT y la mayoría de proveedores: la IA lee cada ticket y escribe un resumen, para que el agente entrante no tenga que desplazarse por 20 respuestas. Ayuda, y la mayoría de helpdesks ya lo incluyen (más sobre eso abajo). Mi guía de resumen de tickets profundiza en lo buenos que son esos resúmenes.
2. Marcar los tickets de riesgo. Ordena el traspaso por riesgo y no por antigüedad: SLA que vence en la próxima hora, una llamada prometida, un contacto repetido o un aviso de incidencia. Una lista de resúmenes de 40 tickets por fecha esconde los pocos que de verdad importan.
3. Reducir lo que cruza la línea. Este es el trabajo que cambia las cuentas. Un agente de IA para helpdesk que responde y resuelve tickets no se desconecta a las 6 pm. Estado de pedidos, preguntas de cómo hacer algo, enlaces de devolución: si la IA los cierra mientras el turno saliente termina y antes de que llegue el entrante, nunca llegan a ser elementos de traspaso. El traspaso más barato es el que nunca tiene que ocurrir.
4. Escribir la nota en el momento del escalado. Cuando la IA no puede cerrar un ticket, lo pasa a una persona. Ese pase es un traspaso en sí mismo, y ocurre en cada ticket en el momento en que el contexto está más fresco, en lugar de una vez por turno. Así el traspaso deja de ser una tarea de fin de turno y pasa a ser una propiedad del ticket.
Los trabajos 3 y 4 son la razón por la que creo que "la IA escribe un mejor documento de traspaso" se queda corto. Un documento mejor sigue suponiendo que la misma pila de tickets pasa de un escritorio al siguiente. Un agente que trabaja la cola entre turnos hace la pila más pequeña, y las notas sobre lo que queda las escribió algo que nunca se cansa al final de un turno.
¿Qué debe contener una buena nota de traspaso?
Cinco campos por ticket. Si una nota los tiene, la siguiente persona puede actuar sobre el ticket sin leer el hilo. Si le falta alguno, leerá el hilo de todos modos, y entonces la nota no ahorró nada.
| Campo | Ejemplo | Quién debería rellenarlo |
|---|---|---|
| Qué quiere el cliente | Reembolso del pedido 4417 | IA, a partir de la conversación |
| Qué se ha probado | Enlace de restablecimiento enviado dos veces, falló | IA, a partir de las respuestas y las notas internas |
| Qué se prometió y para cuándo | "Actualización para las 14:00 UTC" | La IA lo redacta a partir de las respuestas, una persona lo confirma |
| Quién es responsable del siguiente paso | Equipo de facturación | Una persona, o una regla de enrutamiento que aplica la IA |
| Pruebas ya encontradas | Pedido pagado, no enviado | IA, a partir de una consulta en Shopify, el CRM o la herramienta de facturación |
El patrón de esa última columna merece atención. La IA es muy buena en los dos primeros campos y en el último, porque son datos que están en el ticket o en un sistema conectado. La promesa y el responsable son donde una persona debe seguir dando el visto bueno, porque son compromisos, y un compromiso equivocado en una nota de traspaso es peor que ninguno. Mi guía de traspaso a humano en el chat cubre el lado de cara al cliente del mismo momento.
Dos reglas hacen que estas notas sean fiables entre zonas horarias:
- Enlaza a la fuente. Cada afirmación de la nota debería poder comprobarse en el ticket. "El cliente está enfadado" es una opinión; "tercer contacto en 48 horas" es un hecho que el siguiente agente puede verificar.
- Separa lo encontrado de lo supuesto. "Pedido enviado el 28 de oct." (de Shopify) y "probablemente un retraso del transportista" (una suposición) nunca deberían leerse igual.
¿Qué hacen ya Zendesk, Freshdesk, Help Scout y Gorgias?
La mayoría de helpdesks ya pueden resumir un ticket bajo demanda, y eso cubre la parte de "qué pasó" de un traspaso. Ninguno de ellos mantiene de serie una lista continua de lo prometido y de quién es responsable. Esto es lo que hace cada uno, según la documentación de los propios proveedores, consultada el 30 de octubre de 2026.
| Helpdesk | IA nativa relacionada con el traspaso | Qué cubre | Plan y límites |
|---|---|---|---|
| Zendesk | Resúmenes de tickets en Agent Workspace | Recapitula comentarios públicos; notas internas solo si un administrador lo activa | Suite y Support Professional o superior, con cuota de uso mensual; parte del complemento Copilot |
| Freshdesk | Freddy AI Summarize | Issue, Steps Taken y Outcome, incluidas las notas privadas | Dentro de Ticket content assist de Freddy AI Copilot, el administrador debe activarlo |
| Help Scout | AI Summarize | Resumen de la conversación con un clic | Planes Plus y Pro; el resumen siempre está en inglés |
| Gorgias | AI Agent ajustes de traspaso | Temas de traspaso y mensajes distintos según el chat esté en línea o fuera de línea | Parte de Gorgias AI Agent |
Resúmenes de tickets de Zendesk
La versión de Zendesk aparece como un banner bajo la cabecera del ticket. Su documentación dice que recapitula "the public comments that have been added to a ticket so far", y las notas internas se incluyen solo si tu administrador lo activa. Para un traspaso, este ajuste importa mucho, porque en las notas internas es donde el agente saliente suele escribir lo que probó. Los resúmenes pueden actualizarse manualmente cada cinco minutos para recoger los comentarios nuevos. Más detalle en mi artículo sobre los resúmenes de tickets de Zendesk Copilot.
Freddy AI Summarize en Freshdesk
El resumen de Freshdesk es el más cercano a una nota de traspaso de serie, porque viene estructurado: una sección Issue, una sección Steps Taken que incluye notas privadas y un Outcome. Los agentes pueden editarlo y guardarlo, y Freshworks sugiere añadir los resúmenes a notas privadas como referencia del equipo. No se actualiza solo cuando llegan respuestas nuevas; hay que regenerarlo. Mi guía de los resúmenes de Freddy incluye la configuración.
Quienes lo usan describen más o menos el beneficio de traspaso que cabría esperar:
"Freddy makes our tickets easy to understand for all agents. The need for explanation has decreased, as agents can find the Freddy summary at the top of the ticket."
Help Scout AI Summarize y los traspasos de Gorgias
Help Scout es el único proveedor cuya documentación nombra directamente el caso de uso del traspaso: su AI Summarize es "useful for handing off a conversation to another teammate." Hay dos límites que conviene conocer para un equipo en varias zonas horarias: el resumen siempre se escribe en inglés sea cual sea el idioma de la conversación, y no se actualiza solo; hay que hacer clic en Update Summary cuando entran respuestas nuevas. Más en mi resumen de Help Scout AI.
Gorgias lo aborda desde el otro lado. Los ajustes de traspaso de su AI Agent permiten escribir instrucciones de traspaso distintas para cuando el chat está en línea y cuando está fuera de línea, compartir el horario laboral en el mensaje fuera de línea y recoger el correo del comprador para que el siguiente turno pueda hacer seguimiento. Es un traspaso de la IA al equipo más que de un turno a otro, pero es el mismo momento. Lo traté en mi artículo sobre la guía de traspaso de Gorgias.
La carencia común a los cuatro: los resúmenes se piden bajo demanda y describen el pasado. No ordenan la cola según a quién se le debe qué, y además solo existen en los tickets que alguien pensó en abrir. Para una cola tranquila está bien. Para un equipo con dos o tres cambios de turno al día, la nota de traspaso tiene que estar ya ahí cuando llegue la siguiente persona.
¿Cómo se ve esto en producción?
Aquí hay tres clientes de eesel cuyas configuraciones resuelven el problema del traspaso cada una a su manera. Todas las cifras proceden de sus casos publicados y cubren del 8 de agosto al 8 de septiembre de 2026.
SE Ranking: las reglas de traspaso por escrito. SE Ranking gestiona el soporte de tres productos en Zendesk, con un equipo de 16 países que cubre todas las zonas horarias. Esa es la forma de un equipo follow-the-sun, y las reglas de traspaso están escritas. Cuando un chat necesita a una persona (un reembolso, una ampliación de prueba, la misma pregunta repetida o un cliente que dice que su pantalla no coincide), eesel lo traspasa con el nombre y el correo del cliente. Si había estado resolviendo un problema, lo traspasa con una nota de lo que ya le dijo al cliente. Los problemas de nivel 2 se convierten en un ticket con las pruebas adjuntas primero: el dominio, el enlace de la auditoría o una captura del conector. Y nunca le dice a un cliente que alguien se une ahora; le dice que espere una respuesta en uno o dos días laborables. En ese mes traspasó unos 1.260 chats al equipo y dejó unas 2.600 notas internas, la mayoría borradores para que una persona los enviara.
Esa última regla es la que copiaría en cualquier equipo con varias zonas horarias. Un bot que promete un agente en vivo a las 3 de la madrugada crea exactamente el tipo de compromiso que muere en el traspaso.
Amagency: el formato de nota que ahorra una lectura previa. Amagency gestiona el soporte de cuatro marcas de consumo desde una sola cuenta de Gorgias. eesel nunca responde a los clientes allí. En su lugar, cada nota interna pone arriba la respuesta completa al cliente, lista para copiar, y debajo una sección corta con los datos del pedido que encontró y cualquier cosa que marcó. Eso es una nota de traspaso en todo menos en el nombre: quien recoge el ticket después ve las pruebas y la respuesta propuesta sin abrir el hilo. Dejó unas 900 notas internas y 460 borradores de respuesta en unos 350 tickets durante el mes. También hace cada día laborable a las 9 de la mañana, hora de Sídney, una revisión breve del espacio de trabajo y envía una nota por correo al equipo, que sirve de resumen de inicio de turno.
Swiftreg: el turno de noche que no es uno. Swiftreg, un vendedor británico de matrículas en Zendesk, recibe la mayoría de sus tickets durante la jornada laboral, pero el caso indica que los que llegan de noche reciben el mismo trato que los diurnos. De unos 2.100 tickets en el mes, eesel envió 1.494 respuestas públicas y dejó 1.055 notas internas allí donde el siguiente paso correspondía al personal. Quien abre la cola por la mañana encuentra los tickets de la noche o respondidos o con una nota.
Una regla de la configuración de un cliente muestra por qué las reglas por escrito superan a los documentos de traspaso. Un administrador de soporte que configuraba el agente lo expresó así:
"I have a rule in CS where we do not address a cancel or refund request when there is an issue attached to it."
Reglas como esa suelen vivir en la cabeza de un agente veterano y viajan de turno en turno de boca en boca. Una vez escritas en las instrucciones del agente, se aplican igual a las 2 de la tarde que a las 2 de la madrugada, sea quien sea el que esté de turno. Es un beneficio discreto de la IA para equipos con varios turnos: la política deja de depender de quién trabaja ese día.
¿Cuánto tiempo te cuesta tu traspaso?
Introduce tus propias cifras. Los valores por defecto suponen dos cambios de turno al día, 40 tickets abiertos en cada uno y 6 minutos para que el siguiente agente se ponga al día con un ticket sin nota, frente a 1,5 minutos con una buena nota. Marca lo que tu traspaso actual recoge de forma fiable y el comprobador enumerará las carencias.
El tiempo de puesta al día actual escala con cuántos de los seis campos recogen ya tus notas. "Con un agente de IA" supone que el agente cierra la parte que fijes antes del traspaso y deja una nota completa en todo lo demás.
Dos cosas suelen llamar la atención. Primero, el tiempo de puesta al día es mayor de lo que la gente espera, porque se paga en cada cambio de turno, cada día: 80 tickets a 4,5 minutos cada uno son 6 horas de tiempo del nuevo turno poniéndose al día, antes de que nadie responda a un cliente. Segundo, la nota hace más trabajo que la desviación. Incluso con el control al 0 %, una nota completa en cada ticket reduce el tiempo de puesta al día en cerca de dos tercios con los valores por defecto. Si lo que te preocupa es el tamaño de la cola en sí y no la puesta al día, mis artículos sobre despejar una acumulación de tickets y reducir el tiempo de gestión cubren ese lado.
¿Qué debe traspasar la IA y qué debe quedarse con una persona?
La IA debería llevar los hechos y los tickets rutinarios; las personas deberían ser dueñas de los compromisos y las decisiones de criterio. Así lo dividiría yo para un equipo con dos o tres turnos:
| En el cambio de turno | Lo gestiona la IA | Lo gestiona una persona |
|---|---|---|
| Tickets rutinarios (estado de pedido, cómo hacer algo, devoluciones) | Los responde y los cierra antes y después del traspaso | Revisa una muestra al inicio del turno |
| Resumen de cada ticket abierto | Lo escribe en cada ticket que toca | Lo lee y señala lo que esté mal |
| Pasos probados y pruebas encontradas | Los extrae de respuestas, notas y consultas | Añade lo hecho fuera del ticket (una llamada, un hilo de Slack) |
| Actualizaciones y plazos prometidos | Los redacta a partir de las respuestas y marca los que vencen pronto | Confirma la promesa y la cumple |
| Responsable de un escalado | Aplica tus reglas de enrutamiento | Acepta la responsabilidad, sobre todo en ingeniería o facturación |
| Incidencias y problemas de seguridad | Avisa a quien esté de guardia | Es responsable de la incidencia y de las actualizaciones al cliente |
| Clientes enfadados o recurrentes | Los marca al principio del traspaso | Escribe la respuesta |
Las salvaguardas para que el lado de la IA sea seguro son pocas. Nunca debería cerrar ni reasignar en silencio un ticket que pertenece a otro turno. Cada nota de traspaso que escriba debería enlazar al ticket del que procede. Y nunca debería prometer una persona en vivo que el calendario no pueda cumplir, que es otra vez la regla de SE Ranking. Para el diseño más amplio, consulta mi artículo sobre buenas prácticas de traspaso con IA.
¿Cómo configuras traspasos asistidos por IA en tu helpdesk?
Cinco pasos. Los dos primeros son tareas de orden en el helpdesk que cualquier proceso de traspaso necesita, con IA o sin ella.
Paso 1: convierte los cinco campos en campos reales del ticket
Una nota de traspaso en texto libre se salta. Añade campos personalizados o etiquetas para siguiente responsable y prometido para (fecha y hora), y asegúrate de que la hora de vencimiento del SLA se vea en la vista del ticket. Una vez que son campos, tanto las personas como la IA pueden rellenarlos, y puedes crear una vista ordenada por "prometido para".
Paso 2: define el horario laboral por región
Tu helpdesk necesita saber quién está conectado y cuándo; si no, los temporizadores de SLA y los mensajes de "el chat está fuera de línea" serán incorrectos en cada cambio de turno. Zendesk admite varios horarios en Enterprise, Freshdesk admite varios horarios laborales de Pro en adelante, Gorgias tiene horario laboral en todos los planes desde Basic, y Help Scout tiene horario de empresa con horarios de bandeja personalizados en Plus y Pro. Recorrí las rutas de menú de cada uno en mi guía de cobertura de fin de semana. Para el diseño de SLA en sí, consulta las buenas prácticas de SLA.
Paso 3: conecta un agente de IA y dale una plantilla de nota de traspaso
Conecta el agente a tu helpdesk, tu centro de ayuda y los tickets pasados, además de los sistemas que necesite para las consultas (Shopify, tu herramienta de facturación). Luego escribe la regla de traspaso con palabras sencillas, como si informaras a una persona nueva: "Cuando pases un ticket a una persona, deja una nota interna con lo que quiere el cliente, lo que has probado, cualquier cosa que hayas prometido y para cuándo, quién debería ser el responsable y lo que has encontrado." En eesel eso es simplemente texto en las instrucciones del agente; se aplica en cada escalado, las 24 horas.
Paso 4: programa un resumen de inicio de turno
Haz que la IA publique un resumen corto al empezar cada turno: tickets con un SLA que vence en las próximas dos horas, tickets con una actualización prometida para hoy, contactos repetidos, todo lo escalado desde el último turno. Envíalo adonde tu equipo ya mira: Slack, Microsoft Teams o correo. En eesel es un trabajo programado: un prompt, una hora y una zona horaria, de modo que el resumen de APAC y el de Europa lleguen cada uno a las 9 de la mañana locales.
Paso 5: funciona dos semanas solo con borradores y luego amplía
Empieza con la IA escribiendo notas y borradores, sin enviar respuestas. En cada cambio de turno hazle una pregunta al agente entrante: ¿podías actuar sobre este ticket solo con la nota? Corrige la plantilla donde la respuesta sea no. Después deja que la IA cierre sola tus dos o tres temas rutinarios principales. Llevo años viendo cómo eesel pone agentes de IA en colas de soporte reales, y toda configuración nueva se prueba primero con tickets pasados reales, porque las respuestas que suenan seguras fallan de formas que solo se ven con tus propios datos. Mi lista de errores de implementación de IA cubre las trampas habituales.
¿Cómo sabes que tus traspasos funcionan?
Mide el traspaso en sí y no solo la cola. Cuatro números te dicen casi todo lo que necesitas:
- Compromisos incumplidos. Tickets en los que pasó la hora de actualización prometida sin respuesta. Este es el número que todo el ejercicio busca llevar a cero.
- Incumplimientos de SLA en la primera hora de un turno. Si los incumplimientos se concentran justo después del cambio de turno, el traspaso está perdiendo el reloj.
- Tiempo hasta la primera acción tras el inicio del turno. Cuánto tarda el turno entrante en responder a su primer ticket heredado. Con buenas notas son minutos, no una hora.
- Tickets que cruzan cada cambio de turno. La cifra que estima la calculadora de arriba. Debería bajar a medida que la IA asume más volumen rutinario.
Etiqueta todo lo que toque la IA para poder separar sus tickets de los del equipo. SE Ranking pidió una etiqueta ai_handled en cada ticket que trabaja eesel, además de etiquetas de útil y no útil, de modo que la contención se cuenta en Zendesk en lugar de adivinarse. Mis artículos sobre métricas de atención al cliente con IA y calidad del escalado van más lejos, y IA para informes de soporte cubre cómo construir el informe en sí.
Cuándo eesel no es la opción adecuada: si tienes un único turno con uno o dos agentes, una plantilla de traspaso de cinco líneas en tu helpdesk más el botón de resumen nativo bastarán. Y si tu problema es que no hay nadie conectado durante largos periodos, en lugar del momento entre turnos, lee mi guía de soporte fuera de horario o mira las opciones de dotación en IA para la dotación de soporte.
Prueba eesel para los traspasos de turno
Si tu equipo de soporte trabaja por turnos y la mañana empieza con una pila que nadie documentó, eesel funciona como un compañero que nunca cambia de turno. Se une a tu cola actual en Zendesk, Freshdesk, Gorgias o Help Scout, responde lo que tu centro de ayuda y los tickets pasados ya cubren, y deja una nota interna con los hechos, el borrador y las pruebas en cada ticket que pasa a una persona. Un resumen programado puede llegar a Slack o Teams al inicio del turno de cada región.
Así es como SE Ranking gestiona una cola en 16 países, y así consigue Amagency una respuesta lista para enviar en los tickets de Gorgias antes de que el equipo abra. Los planes son un lote mensual fijo de créditos: un ticket o chat es un crédito, desde 299 $ al mes por 500, y los 100 créditos del plan gratuito te dejan ver primero las notas en tus propios tickets.
Prueba eesel en el traspaso de esta noche, o mira cómo se compara en mi resumen de los mejores agentes de IA para atención al cliente.