¿Qué es un traspaso de turno en soporte?
Un traspaso de turno en soporte es el momento en que un turno de agentes pasa la cola abierta al siguiente. Ocurre en cualquier equipo que no está en una misma sala todo el día: una jornada de dos turnos en una oficina, un modelo follow-the-sun entre regiones, un equipo offshore que cubre tus noches o un equipo de entre semana que pasa el relevo a uno de fin de semana. Si tus clientes pueden escribir a las 18:05, tienes un traspaso de turno, lo hayas diseñado o no.
Todo buen traspaso tiene dos capas, y la mayoría de los equipos solo construye una.
| Capa | Qué cubre | Quién la lee | Dónde vive |
|---|---|---|---|
| Nota de ticket | Un ticket: qué se pidió, qué se probó, qué se prometió, qué ocurre después | Quien reciba ese ticket | Una nota interna en el propio ticket |
| Resumen de turno | Toda la cola: incidencias, picos, SLA en riesgo, promesas que vencen, cualquier cosa rara | Todo el turno entrante | Un mensaje en un canal compartido o un documento fijado |
La nota de ticket evita que el cliente tenga que repetirse, que es el objetivo de pasar el contexto del traspaso. El resumen de turno evita que el siguiente turno descubra una caída del producto un ticket confuso a la vez. Los equipos que solo escriben notas de ticket pierden el patrón; los que solo publican un resumen en Slack dejan el detalle donde el siguiente agente no lo verá al abrir el ticket.
Por qué se pierden tickets en el cambio de turno
El fallo casi nunca es "el agente saliente fue perezoso". Es estructural, y se ve en cómo se comportan los helpdesks por defecto.
El responsable está desconectado, pero el ticket no lo sabe. En Zendesk, el horario laboral no establece el estado unificado de un agente. La propia guía de Out of Office de Zendesk advierte: "agents must remember to update their status." Si no lo hacen, el enrutamiento sigue creyendo que están disponibles, y la respuesta del cliente a las 19:00 cae en alguien que se fue a las seis.
Los tickets tranquilos se quedan aparcados. Front es claro sobre ese hueco en su guía de fuera de oficina: las respuestas a las conversaciones de un compañero fuera de oficina se desasignan, pero las conversaciones "that do not receive new replies will be unaffected." Está bien para un ticket en el que el cliente te espera a ti. No para el ticket en el que tú prometiste una llamada antes de las 9.
El contexto vive en la cabeza de alguien. El agente saliente sabe que el cliente ya probó los pasos de restablecimiento, que un responsable aprobó el reembolso de palabra, que es el tercer ticket de la misma cuenta esta semana. Nada de eso está en el ticket a menos que alguien lo escriba.
Además se escribe en el peor momento posible. Un ingeniero en Hacker News describió el problema del final de turno con claridad:
"I mean in IT i see first hand the notes left by people on pager duty in the middle of the night, and they differ significantly from the same peoples notes after a restful night of sleep."
Un agente cansado a las 17:55 escribe la misma nota pobre. Eso es un argumento a favor de una plantilla fija y de dejar que el software redacte el primer borrador.
Las promesas sobreviven a su responsable. "Lo consulto con ingeniería y te respondo mañana" es un compromiso que el cliente recuerda y que el siguiente turno nunca ha oído. Es lo que te cuesta la puntuación de CSAT, porque desde el lado del cliente la empresa ha faltado a su palabra.
Traspasa menos tickets, no más
Este es el replanteamiento que más defendería. El instinto al final de un turno es pasarlo todo para que nada quede colgando. Eso crea más traspasos, y cada traspaso es un punto donde se filtra contexto. La propia guía de Zendesk sobre soporte follow-the-sun describe a su equipo como uno con "no daily handoffs"; los tickets suelen quedarse con quien los tomó.
Así que clasifica tus tickets abiertos en tres montones antes de escribir una sola nota:
- Conservar. El cliente no te está esperando ahora (pendiente, esperando a un tercero, o tú respondiste y él no). Sigue siendo tuyo. Si responde mientras no estás, los ajustes de reasignación más abajo lo recogen.
- Traspasar. Un objetivo de SLA vence antes de que vuelvas, hiciste una promesa con plazo, o el cliente está en plena conversación en un canal en vivo. Estos llevan una nota y un nuevo responsable.
- Dejar que la IA lo gestione. Las preguntas rutinarias que llegan por la noche (estado del pedido, restablecer contraseñas, dudas que tu base de conocimiento ya responde) no necesitan un traspaso humano si un agente de IA trabaja la cola.
Si tu montón de "traspasar" es más que un puñado, el problema está aguas arriba: los tickets envejecen demasiado, o los turnos son demasiado cortos para el trabajo. Las notas de traspaso no arreglarán eso.
La nota de traspaso: una plantilla de cinco líneas
Para los tickets que sí cambian de manos, la nota importa más que cualquier otra cosa. Debería llevar menos de un minuto escribirla y menos de un minuto leerla.
Esta es la versión que guardaría como macro:
HANDOFF [date, your shift]
Asked: [what the customer wants, in one sentence]
Tried: [what you already did or ruled out]
Promised: [what you told them, and by when]
Next step: [the one action the next person takes]
Owner now: [name or group]
La línea que más trabaja es Promised. Si solo haces obligatorio un campo, que sea ese. Una nota que dice "cliente molesto, por favor revisar" suspende en todas las líneas de la plantilla; el siguiente agente tiene que releer todo el hilo para saber lo que el saliente ya sabía.
Un rápido antes y después con un ticket realista:
| Nota débil | Nota útil |
|---|---|
| "Refund issue, customer chasing. Pls follow up." | Asked: refund for a double charge on order 4417. Tried: confirmed both charges in Stripe, refund for one approved by Dana. Promised: refund confirmation email by 10 a.m. tomorrow. Next step: process refund, send confirmation. Owner now: APAC group. |
Pon la nota en el ticket como nota interna, nunca solo en Slack. Todos los helpdesks lo permiten: las macros de Zendesk pueden fijar el modo de comentario en privado, Help Scout recomienda las Saved Replies como plantillas de notas internas, y una macro de Gorgias puede enviar una nota interna y asignar un agente con un clic, de modo que la nota y la reasignación ocurren juntas. Si quieres que los agentes rellenen los huecos en lugar de borrar texto de relleno, los campos de entrada de macros de Zendesk les piden cada valor.
El resumen de turno: un mensaje para toda la cola
El resumen de turno es la capa de la cola entera, y es corto. Cinco viñetas, publicadas en el mismo canal a la misma hora cada turno:
- Incidencias: cualquier cosa rota ahora mismo, con el enlace de seguimiento interno.
- Volumen: cualquier cosa inusual ("tickets de reembolso al alza tras la campaña de correo de las 14:00").
- En riesgo: tickets que incumplirán el SLA en el siguiente turno, con números de ticket.
- Promesas por vencer: llamadas o seguimientos pendientes antes del siguiente traspaso.
- Avisos: cuentas VIP en juego, una macro errónea, una política que cambió hoy.
Limítalo a lo que el siguiente turno aprendería por las malas. Un resumen que repasa cada ticket que cerraste es un resumen que nadie lee en la tercera semana.
Los equipos que llevan colas de 24 horas llegan casi exactamente a esta forma. De alguien que trabajó en un centro de operaciones de red activo todo el día:
"Worked for a 24x7 NOCC for a while. We had at a minimum a handoff email that had a break down of active tickets along with their current progress and any tickets that needed immediate attention highlighted, along with alarms, and some other necessary info for the next shift. Since we were all in one room we also had coverage overlap of about 30 minutes and we would use that time as an informal information exchange."
Una rutina de traspaso de 45 minutos
Esta es la rutina con la que empezaría, repartida entre ambos turnos. Ajusta los tiempos, mantén el orden.
Últimos 30 minutos del turno saliente
- Repasa tu cola (10 min). Abre una vista de tus tickets asignados sin resolver. Clasifícalos en conservar, traspasar y dejar a la IA.
- Escribe las notas (15 min). Nota de cinco líneas en cada ticket traspasado, y reasígnalo al grupo del siguiente turno, no a una persona con nombre que mañana puede estar enferma. El enrutamiento de tickets basado en grupos hace el resto.
- Publica el resumen (5 min). Cinco viñetas en el canal compartido.
El solape (dentro de esos mismos minutos)
Lo ideal es que los primeros 15 minutos del turno entrante se solapen con los últimos 15 del saliente, de modo que el resumen llegue mientras ambas personas están conectadas. Ahí se hacen las preguntas en directo. Incluso 15 minutos superan a un traspaso escrito perfecto, porque el agente entrante puede preguntar "¿qué querías decir con esto?" mientras el saliente aún lo recuerda.
"The reason shift handoffs go bad is it's usually a singular information dump right as the next round is getting into work mode."
La solución del mismo comentarista es una hora de solape. La mayoría de los equipos de soporte no se pueden permitir eso en cada turno, pero 15 minutos sobre los tickets traspasados te dan la mayor parte del beneficio.
Primeros 15 minutos del turno entrante
- Lee el resumen antes de tocar la cola, y luego haz tu triaje de tickets habitual sobre lo nuevo.
- Revisa las promesas por vencer. Cada línea "Promised" con una hora en el siguiente turno va primero en tu lista.
Después, pon tu propio estado correctamente, en ambos sentidos. La rutina se cae si el agente saliente sigue "en línea" en el helpdesk después de irse.
Configura tu helpdesk para cubrir lo que la gente olvida
La rutina se ocupa de los tickets que la gente recuerda. Los ajustes del helpdesk se ocupan del resto: la respuesta del cliente a las 21:00 en un ticket que nadie marcó. Cada uno de los cinco grandes helpdesks tiene una versión de esto, y los límites de plan importan.
| Qué hace en el cambio de turno | Plan necesario | |
|---|---|---|
| Zendesk | Reasigna tickets reabiertos cuando el responsable tiene un estado elegido; reasigna automáticamente hasta 50 de sus tickets abiertos actualizados más recientemente cuando cambia su estado | Suite Professional ($115/agente/mes anual) y superiores |
| Freshdesk | Agent Shifts cambian la disponibilidad según horario; las reglas al actualizar un ticket reenrutan, reasignan o avisan al cliente cuando el responsable está fuera de turno | Enterprise ($89/agente/mes anual) |
| Help Scout | "Reassign conversations" desasigna conversaciones Active y Pending tras un periodo de ausencia definido; la app pone Away automáticamente a los 10 minutos de cerrarse | No indicado en la documentación |
| Gorgias | "Unassign on reply" para tickets que se reabren mientras el agente está desconectado; ajuste separado para chats en vivo | Todos los planes de helpdesk |
| Front | Las respuestas a las conversaciones de un compañero fuera de oficina se desasignan; Shifts pone a los compañeros en Out of office al terminar el turno | Out of office en todos los planes; Shifts en Enterprise ($105/puesto/mes anual) |
Zendesk
Zendesk retiró su app Out of Office y trasladó la función al enrutamiento omnicanal. Creas un estado personalizado "Out of Office" y luego activas dos interruptores separados: la reasignación de tickets reabiertos y "Auto-reassign open tickets", que recoge "the 50 most-recently updated open email and messaging tickets" cuando un agente cambia a ese estado.
Dos pegas. La configuración requiere Professional o superior, y el estado todavía tiene que cambiar. Zendesk sugiere establecerlo por API desde "Google Calendar or Outlook" o "WFM schedules" para que no dependa de que alguien haga clic en un desplegable al final de un día largo. Si estás por debajo de Professional, la alternativa es el método manual masivo de Zendesk: una vista filtrada por "Assignee is (agent)" y "Status less than Solved", y luego un cambio masivo de asignado. Mi guía de enrutamiento en Zendesk cubre el resto de la configuración de enrutamiento.
Freshdesk
El documento de Agent Shifts de Freshdesk describe el problema del traspaso casi palabra por palabra: un agente del turno de mañana responde, su turno termina y el cliente vuelve a escribir. Puedes hacer que el ticket sea "re-routed, re-assigned, or have the customer notified to expect a delay in response", usando reglas que comprueban la disponibilidad del agente en cada actualización del ticket.
Los turnos cambian la disponibilidad automáticamente, que es la pieza que Zendesk deja en manos del agente. La contrapartida es el plan: Agent Shifts está en Enterprise. He escrito más sobre los Agent Shifts de Freshdesk si lo estás configurando. Para configuraciones más simples, mi guía de asignación automática en Freshdesk cubre el round robin.
Help Scout
Help Scout tiene un ajuste por usuario de Conversation Reassignment: tras un periodo de ausencia elegido, "any Active or Pending conversations assigned to an away user will be automatically unassigned", y se detiene en cuanto la persona vuelve a Active. Combínalo con la detección de presencia: según la guía de estado de Help Scout, cerrar la app te pone en Away en 10 minutos, y el problema del estado se resuelve casi solo.
Una cosa que afinar: el periodo de ausencia lo defines tú, así que uno más corto traspasa tickets más rápido pero también puede quitárselos a alguien en una comida larga. Consulta mi resumen de Help Scout AI para ver qué más incluyen los planes.
Gorgias
Gorgias lo mantiene simple y lo pone en todos los planes de helpdesk. En los ajustes de asignación de tickets, "Unassign on reply" reasigna un ticket que se reabre mientras su agente está desconectado, y una casilla aparte gestiona los chats en vivo cuando el agente deja de estar disponible a mitad de conversación. Gorgias es honesto sobre la contrapartida en el mismo documento: quedarse con un solo agente "might contribute to a consistent experience", mientras que reasignar "might lead to faster resolution times". Para traspasos de turno, yo elegiría el camino más rápido, sobre todo si tu cola es mayoritariamente correo asíncrono. Más sobre enrutamiento en mi guía de Gorgias auto assign.
Front
La función Shifts de Front (Enterprise) pone a los compañeros como Available al inicio del turno y Out of office al final, y "new replies from the customer will also trigger conversations to unassign from any teammates not working on the shift."
Front también tiene un buen truco para la propia nota: la acción "Add comment" de una regla puede publicar un comentario interno fijado con @menciones. El hueco que hay que recordar es el de antes: las conversaciones tranquilas siguen asignadas, así que el paso "repasa tu cola" sigue importando en Front. Mi análisis de Front AI cubre sus complementos de IA.
Dónde encaja la IA en un traspaso de turno
La IA ayuda en tres puntos, y conviene separarlos porque cuestan cantidades distintas y fallan de formas distintas.
1. Resúmenes que redactan la nota del ticket. La mayoría de los helpdesks ofrecen ya resúmenes de tickets con IA. AI Summarize de Help Scout nombra "handing off a conversation to another teammate" como caso de uso. Los límites merecen una lectura atenta: los resúmenes de Copilot de Zendesk estuvieron disponibles en planes Professional en mayo de 2026, pero con una asignación de 5 usos de IA por agente al mes, agrupados en la cuenta y con un tope de 500, según el anuncio de Copilot. Eso no da para un traspaso diario; el uso ilimitado requiere el complemento Copilot de $50. Los resúmenes de Front necesitan el complemento Copilot ($20/puesto), y los resúmenes de Freddy necesitan Freddy AI Copilot ($29/agente).
Mi guía de resúmenes con IA de Zendesk profundiza en el lado de Zendesk.
Un resumen es un borrador, no un traspaso. Dice al siguiente agente qué ocurrió; rara vez sabe lo que prometiste a menos que lo hayas escrito en el hilo. Mantén la línea Promised en manos humanas.
2. Un resumen de turno programado. El resumen de la cola es un buen trabajo para un compañero de IA con temporizador. Con eesel, una tarea programada ejecuta un prompt como "summary of all support tickets from the last 24 hours" a diario, cada hora o cada semana, en la zona horaria que elijas, y lo publica donde lo verá el siguiente turno.
Un equipo de soporte en eesel ejecuta exactamente esto como "daily support handoff summary". La lección honesta de esa configuración: en una ejecución la tarea no produjo nada, y el equipo lo notó cuando el turno de mañana empezó a ciegas. Sea cual sea la herramienta que escriba tu resumen, haz que una persona lo revise las primeras semanas, y trata "el resumen no llegó" como una alerta, no como un día tranquilo.
3. Menos tickets que traspasar desde el principio. Esta es la palanca más grande. Cada ticket rutinario respondido a las 2 de la madrugada es un ticket que el turno de mañana nunca hereda. En Anytime Fitness, los socios que hacían una pregunta a las 22:00 solían esperar hasta la mañana; con eesel respondiendo las preguntas comunes, reciben respuesta a cualquier hora en más de 5.000 gimnasios. Es la misma idea que el soporte 24/7 con IA.
La regla que lo hace seguro es la que piden los compradores en casi todas las llamadas: la IA debe responder solo lo que sabe con certeza y dejar el resto. Un responsable de soporte con una cola de 200-250 tickets en Zendesk describió el objetivo como una aplicación que pudiera:
"handle 60% of the incoming zendesk tickets and know when to pull a real person in for better analysis and resolution."
Eso es el traspaso en miniatura. La IA se lleva la parte rutinaria durante la noche, etiqueta y resume lo que no respondió, y el turno de mañana empieza por los tickets que necesitan a una persona. Es el mismo principio que el traspaso de IA a humano, solo que con un reloj.
Errores comunes en el traspaso de turno
- Traspasar a una persona en lugar de a un grupo. Si el agente con nombre de mañana se da de baja, el ticket se queda parado. Traspasa al grupo o cola del siguiente turno.
- Notas en Slack, no en el ticket. El siguiente agente abre el ticket, no el canal de anoche. Slack es para el resumen; el ticket recibe la nota.
- Disciplina de estado dejada a la memoria. Si tu helpdesk puede cambiar el estado según un horario o la detección de presencia, úsalo. El propio Zendesk dice que el estado manual "require[s] agent discipline."
- Temporizadores de SLA en el reloj equivocado. Si un ticket traspasado conserva el horario laboral de la región saliente, su SLA se detendrá o se incumplirá a horas raras. Apunta las políticas de SLA al horario del grupo que ahora lo tiene.
- Nadie responsable del traspaso en sí. Alguien de cada turno es dueño del resumen. Rótalo, pero ponle nombre, o poco a poco dejará de hacerse.
- No medir nada. Sigue la tasa de reapertura en las dos primeras horas de cada turno. Haz lo mismo con los incumplimientos de SLA; mi guía de seguimiento de SLA en Zendesk muestra cómo. Si ambos se disparan en el cambio de turno, el traspaso es donde vive tu problema.
eesel para traspasos de turno en soporte
El compañero de helpdesk con IA de eesel se une a la cola que ya llevas, sea Zendesk, Freshdesk, Help Scout, Gorgias o Front. En el cambio de turno hace los dos trabajos que la gente se salta cuando está cansada: escribe el resumen de turno de forma programada y deja resúmenes como notas internas en los tickets que no respondió. Durante la noche responde los tickets rutinarios de los que está seguro, aprendiendo de tus tickets pasados, tu centro de ayuda y tus macros, de modo que el turno de mañana hereda una cola más corta con el contexto ya adjunto.
Antes de que toque un ticket en vivo, puedes ejecutarlo contra cientos de tus tickets pasados para ver cómo habría respondido. El precio no añade puestos para el turno de noche: el plan Teammate empieza en $299/mes por 500 créditos, donde un ticket o chat es un crédito.
Si tus mañanas empiezan con una hora releyendo hilos, prueba eesel gratis en tu propia cola y deja que escriba el traspaso de esta noche.