¿Qué es el soporte follow-the-sun?
El soporte follow-the-sun es un modelo de cobertura en el que el trabajo de soporte se mueve por el globo con la luz del día. Un equipo en América trabaja su día y pasa la cola a un equipo en Europa, que se la pasa a un equipo en Asia-Pacífico, que se la devuelve a América. Cada centro trabaja en horario local normal y la cola nunca duerme.
Trabajo la cola de soporte en eesel todos los días y he pasado mucho tiempo con equipos que intentan llegar al soporte 24/7 sin quemar a un equipo nocturno. Follow-the-sun es la versión que mejor queda en una pizarra. Un ingeniero en Hacker News lo describió tan limpiamente como se puede:
"Three regular shifts (8 hours of work plus some lunch break that gives you time for a short overlap at the beginning/end of the shift) during that region's local daytime hours, in three different regions with time zones roughly 8 hours apart. That way nobody has to work nights and you still get 24/7 coverage."
Fíjate en la parte entre paréntesis. El breve solape al final de cada turno es donde ocurre el traspaso, y con tres centros tienes tres cada día.
Ese es el trueque en el corazón del modelo. Cambias los turnos de noche por traspasos. Que sea buen cambio depende casi por completo de cómo gestiones esos tres límites, y de eso trata el resto de esta guía.
Es un primo cercano del soporte offshore, y a menudo se confunden. Offshore trata de dónde está el equipo (normalmente por coste). Follow-the-sun trata de cuándo trabaja cada equipo. Puedes llevar follow-the-sun con tres oficinas propias, o con un equipo onshore más un centro externalizado al otro lado del mundo.
¿Dos centros o tres?
La mayoría de los equipos elige entre tres formas. Así se comparan en lo que de verdad duele.
| Modelo | Centros | Duración del turno | Traspasos al día | Coste principal |
|---|---|---|---|---|
| Turno de noche en una sede | 1 | 8 h, rotativo | 0 | Trabajo nocturno, retención |
| Follow-the-sun con dos centros | 2, a unas 12 h | ~12 h, u 8 h con extremos sin cubrir | 2 | Noches tardías y madrugadas |
| Follow-the-sun con tres centros | 3, a unas 8 h | 8 h | 3 | Plantilla en cada centro |
| Uno o dos centros más IA | 1 a 2 | 8 h | 0 a 2 traspasos humanos | Configuración y revisión de la IA |
Dos centros es donde empiezan la mayoría de los equipos, porque solo hacen falta dos oficinas. El dolor pasa a los bordes del turno en lugar de a mitad de la noche:
"My team in Sydney partners with San Francisco for example, so worst case for me is a page at midnight just before I hand over, worst case for them is about 5am. So not usually anything happening in the middle of the night, at worst a late night or early morning, but never both."
Los dos centros tienen que estar lo bastante lejos para que eso funcione. Un comentarista de r/devops que sopesaba un reparto entre EE. UU. e Irlanda señaló que "there isn't really enough difference in TZs to make that work cleanly" y que el equipo irlandés tendría que crecer para que la carga no quedara descompensada (fuente).
Tres centros te dan turnos limpios de 8 horas, pero es la opción más cara en personas. El mismo hilo de r/devops tiene a alguien cuya empresa pasó de una sede 24/7 (con "a high burnout rate"), a un reparto 12/12 con un equipo en EE. UU., a un reparto 8/8/8 añadiendo un equipo británico de tres personas. Su veredicto sobre ese centro de tres:
"I can't see how we can create a sensible sustainable even rota in these three regions, I also feel like each team needs at least 6-8 people in it for it to be sustainable long term."
Ese es el número que yo tendría en la cabeza. Un centro de dos o tres personas no es un centro, es un punto único de fallo con calendario de vacaciones. Si no puedes poner plantilla real en cada región, una huella más pequeña más algo que cubra los huecos suele ser mejor que una rotación fina de tres centros.
El turno de noche en una sola sede parece lo más barato, sobre todo con un equipo externalizado. Suele perder en personas, no en precio. El dueño de un MSP en r/msp lo dijo sin rodeos tras un equipo nocturno offshore anterior: "keeping people when they are being asked to work through their nights is something I feel never works well" (fuente).
Dónde falla follow-the-sun: el traspaso
La cobertura es la parte fácil. Todos los profesionales que he leído y que han llevado follow-the-sun de verdad dicen lo mismo: el cambio de turno es el punto débil, no las horas.
La primera fuga es el contexto. Cada región ve un trozo distinto del día:
"The communication costs from time zones are real, and it makes everyone's context on what is going on different because they see updates from different regions."
En una cola de soporte, eso se ve como dos clientes que hacen la misma pregunta el mismo día y reciben dos respuestas distintas, porque el equipo de EMEA supo de un retraso de envío en su reunión de la mañana y APAC nunca se enteró. Por eso las respuestas coherentes entre turnos importan más en este modelo que casi en ningún otro sitio.
La segunda fuga es la titularidad. El siguiente centro hereda un ticket, pero no la experiencia que hay detrás:
"I've been at places that follow the sun, and you frequently have no idea what to do during an incident, because the person who owns the system is offline."
La tercera fuga es el propio traspaso, como sobrecarga. Hay que escribir una nota, leerla y fiarse de ella. Escribir una para un único ticket difícil está bien. Escribir treinta a las 4:55 p. m. es como las notas acaban en "ticket 4512, customer upset, pls check."
Lo más útil que encontré en la investigación vino de la propia guía de Zendesk para configurar un modelo follow-the-sun. Al describir cómo trabaja su propio equipo de soporte, dice "there are no daily handoffs" y que los tickets suelen quedarse con el agente que los cogió. Ese es el replanteamiento: follow-the-sun es sobre todo un problema de enrutamiento, no de traspaso. Los tickets nuevos van a quien esté despierto. Los responsables conservan sus tickets y los retoman mañana. Solo los urgentes cruzan la frontera, y esos llevan una nota en condiciones.
Otras dos cosas vuelven desiguales los centros de formas que una pizarra no muestra. La legislación laboral decide quién cubre de verdad los fines de semana: un comentarista de Hacker News entró en una empresa con "follow the sun rotation" y descubrió que el equipo de EE. UU. hacía el soporte fuera de horario para todos los demás porque los otros países tenían reglas más estrictas (fuente). Y algunos contratos descartan un centro por completo. Otro comentarista ha trabajado con clientes enterprise que no permitían que "a subcontractor in London provide support" porque sus datos no podían salir de EE. UU. (fuente). Comprueba ambas cosas antes de elegir tu tercera oficina.
Cómo configurar el soporte follow-the-sun en tu helpdesk
Este es el montaje que le haría seguir a cualquier equipo, en orden. Los pasos son los mismos en todos los helpdesks; el plan que necesitas para desbloquear cada uno no, así que después de los pasos hay una matriz.
1. Crea un grupo (o buzón) por región
Crea un grupo por centro ("Support-Americas", "Support-EMEA", "Support-APAC") y pon a cada agente en su región de origen. Todo lo demás cuelga de estos grupos: horarios, enrutamiento, vistas e informes. En Help Scout y Front, el equivalente es un buzón por región.
2. Dale a cada región su propio horario laboral
Cada grupo recibe un horario en su propia zona horaria. Este es el paso que más a menudo limita el plan. En Zendesk, solo los planes Enterprise pueden tener varios horarios; Suite Professional tiene uno. Freshdesk deja que cada grupo lleve sus propias horas (usa literalmente "EU, North America, or Asia" como ejemplo), con horas adicionales en Pro y superiores.
Un pequeño inconveniente en Zendesk: un intervalo laboral no puede cruzar la medianoche, así que un turno de 22:00 a 06:00 hay que dividirlo en dos intervalos.
3. Apunta tus SLA a las horas laborales
Configura cada política de SLA para que cuente horas laborales y no horas naturales, de modo que un ticket que llega al final del día de APAC no incumpla antes de que el equipo de EMEA se conecte. Todos los helpdesks de aquí lo admiten, y las políticas de SLA de Freshdesk detienen el reloj fuera del horario del grupo. El inconveniente es que el temporizador sigue el horario que esté asociado al ticket, así que el paso 2 tiene que estar bien primero. En Front, las reglas de SLA ahora se llaman reglas de objetivo de tiempo, y el temporizador sigue corriendo mientras una conversación está en pausa, lo que sorprende a la gente.
4. Enruta según quién está disponible de verdad
Este es el paso que convierte follow-the-sun de "tres equipos que comparten una cola" en un modelo que funciona. La asignación solo debería enviar tickets a agentes que estén conectados ahora mismo, que es lo que significa en la práctica el enrutamiento inteligente. El enrutamiento omnicanal de Zendesk enruta por estado y capacidad en todos los planes, y en Professional y Enterprise puede reasignar un ticket reabierto cuando su responsable no está disponible. Esa última función es el traspaso nativo: el cliente responde a las 2 a. m. de su hora, el responsable duerme y el ticket pasa a alguien que no.
Hay un inconveniente que conviene saber de antemano. La documentación de Zendesk sobre los estados de agente unificados lo dice claramente: "Operating hours won't set an agent's status." Los agentes se ponen a sí mismos en Online y Offline. Si alguien olvida pasar a Offline al final de su día, el enrutamiento sigue enviándole tickets durante la noche.
Solo dos de los cinco helpdesks que revisé lo resuelven de forma nativa. Los Agent Shifts de Freshdesk (Enterprise) cambian la disponibilidad automáticamente según las horas del turno, cada turno en su propia zona horaria, aunque no admiten turnos que crucen la medianoche (más en mis notas sobre Freshdesk Agent Shifts). Los Shifts de Front (Enterprise) ponen a los compañeros en Available al empezar el turno y en Out of office al acabarlo, y una nueva respuesta del cliente desasigna la conversación de cualquiera que esté fuera de turno "so someone else can follow up."
5. Estandariza la nota de traspaso y deja que la IA la redacte
Para los tickets que sí cruzan una frontera, acordad qué contiene una nota de traspaso: lo que pidió el cliente, lo que se ha probado, lo que se prometió y para cuándo, quién lo tiene ahora y el siguiente paso. Ponlo en una macro para que la plantilla esté a un clic.
Después deja de escribirlas a mano. La mayoría de los helpdesks ya tienen resúmenes con IA hechos justo para esto. El AI Summarize de Help Scout nombra "handing off a conversation to another teammate" como caso de uso. El resumen de Freddy en Freshdesk se estructura como Issue, Steps Taken y Outcome, e incluye las notas privadas. Los resúmenes de Front se actualizan con cada mensaje nuevo.
Ojo con los límites. Zendesk hizo disponibles los resúmenes de tickets de Copilot en Professional y superiores en mayo de 2026, pero como un conjunto común de 5 usos por agente al mes (resúmenes y herramientas de escritura juntos), con un tope de 500 por cuenta. Un equipo de tres centros con traspasos reales lo agotará en la primera semana, y después necesitas el complemento Copilot. Mi guía de resúmenes con IA en Zendesk cubre la configuración.
6. Mantén una sola base de conocimiento, de todos
La forma más rápida de evitar que las regiones se separen es una única base de conocimiento de la que lean y que actualicen todos los centros. Cuando EMEA se entera del retraso de envío, entra en el centro de ayuda antes de que acabe su día, no en un hilo de Slack al que APAC nunca volverá a hacer scroll. Si atiendes varios idiomas, monta un centro de ayuda multilingüe en lugar de dejar que cada región mantenga su propia copia traducida.
Qué plan desbloquea qué
Este es el plan más barato que desbloquea cada pieza, según la página de precios y el centro de ayuda de cada proveedor a octubre de 2026. Los precios son por agente al mes, facturados anualmente, y el nombre de cada proveedor en la cabecera enlaza a su página de precios.
| Capacidad | Zendesk | Freshdesk | Help Scout | Gorgias | Front |
|---|---|---|---|---|---|
| Más de un horario | Enterprise (ventas) | Pro $55 | Plus $45 (horas por buzón) | Basic (horas propias por canal) | Professional $65 (horas por buzón) |
| SLA en horas laborales | Suite Professional $115 | Growth $19 (1 política), Pro para más | Standard $25 (1 política) | Todos los planes | Professional $65 |
| Asignación según disponibilidad | Suite Team $55 | Pro $55 | Plus $45 | Todos los planes | Professional $65 |
| Turnos que cambian el estado automáticamente | No nativo | Enterprise $89 | No disponible | No disponible | Enterprise $105 |
| Resumen de traspaso con IA | Professional, 5 usos/agente/mes; ilimitado con Copilot $50 | Complemento Freddy AI Copilot $29 | Plus $45 y superiores | No confirmado | Complemento Copilot $20, incluido en Enterprise |
Gorgias es el caso aparte porque se tarifica por volumen de tickets, no por agente, y tiene un interruptor "Pause SLA timer outside of business hours" en todos los planes. Para un equipo en crecimiento que añade agentes en una región nueva, ese modelo de precios es más amable que cualquier plan por puesto, y sus reglas pueden enviar respuestas automáticas fuera de horario por región.
Cuánto cuesta el soporte follow-the-sun en puestos
Supón que sigues la regla de 6 por centro de antes: tres centros, 18 agentes. Esta es la factura mensual de helpdesk en el plan que da horas por región y en el que añade turnos automáticos.
| Helpdesk | Plan con horas regionales | 18 agentes / mes | Plan con turnos automáticos | 18 agentes / mes |
|---|---|---|---|---|
| Zendesk | Enterprise | Habla con ventas | No nativo | n/a |
| Freshdesk | Pro $55 | $990 | Enterprise $89 | $1,602 |
| Help Scout | Plus $45 | $810 | No disponible | n/a |
| Front | Professional $65 | $1,170 | Enterprise $105 | $1,890 |
| Gorgias | Basic y superiores | Tarificado por tickets, no por puestos | No disponible | n/a |
Eso es antes de las nóminas, y las nóminas son el coste real. 18 agentes repartidos en tres oficinas es un presupuesto muy distinto de los 8 o 10 que podría necesitar un equipo de una sola región para el mismo volumen de tickets, porque el volumen no se reparte por igual a lo largo del día. La mayoría de las colas tienen una región ocupada y dos tranquilas, y en un modelo de tres centros los centros tranquilos igualmente necesitan gente suficiente para cubrir festivos.
Aquí vale la pena hacer las cuentas con honestidad frente a las alternativas, incluida la cuenta de IA frente a offshore. Para equipos más pequeños, mi guía de escalado para startups recorre la misma decisión. Si dos de tus tres centros existen sobre todo para responder "¿dónde está mi pedido?" a las 3 a. m., es una forma cara de hacerlo.
Dónde encaja la IA en un modelo follow-the-sun
La IA no sustituye al modelo. Cambia cuántos humanos necesita el modelo y quita de la mesa el peor trabajo: ser la persona que cubre sola las horas tranquilas.
He visto esto en muchos despliegues en eesel. El patrón que funciona es estrecho y aburrido, y por eso funciona:
-
La IA cubre las horas entre centros. Durante el hueco, un agente de helpdesk con IA responde los tickets rutinarios (estado del pedido, restablecimiento de contraseñas, preguntas de cómo hacer algo) desde tu centro de ayuda y tickets pasados. Anytime Fitness gestiona más de 5.000 gimnasios en más de 40 países, y antes de eesel, un socio que hacía una pregunta a las 10 p. m. esperaba hasta la mañana. Ahora las preguntas comunes reciben respuesta a cualquier hora.
-
La IA solo responde lo que tiene claro. Todo lo demás espera intacto al siguiente turno humano. Un responsable de CX que gestiona unos 7.000 tickets al mes lo expresó mejor de lo que yo lo haría en una llamada de ventas:
"I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."
-
La IA escribe el traspaso. En los tickets que deja, etiqueta, enruta y deja una nota interna para que el turno de la mañana empiece con contexto en lugar de una cola fría. Es el problema del traspaso a humanos visto desde el otro lado.
-
La IA da a cada región la misma respuesta. Lee de una base de conocimiento y un conjunto de instrucciones, así que APAC y EMEA no pueden separarse en la respuesta sobre el retraso de envío. Una responsable de service desk en CartonCloud describió el efecto como "consistent, on-brand tone, still keeping our own style and still keeping that human touch" en su caso de éxito.
Un equipo con el que trabajo va un paso más allá y ejecuta un "resumen diario de traspaso de soporte" programado: cada mañana, el agente redacta todo lo ocurrido en las últimas 24 horas en todas las regiones, de modo que cada centro empieza el día con la misma imagen.
Una advertencia honesta de la misma experiencia. Un cliente veterano de eesel tuvo una vez una IA que se comportaba de forma inconsistente respecto al horario laboral, porque las horas vivían solo en el texto del prompt. Pon el horario laboral y las reglas de traspaso en los ajustes del propio helpdesk (los horarios, SLA y enrutamiento de los pasos de configuración de arriba) y deja que la IA los lea, en lugar de describirlos en un párrafo de instrucciones y esperar lo mejor.
Errores comunes de follow-the-sun
La mayoría los he visto en colas reales, y unos cuantos los he cometido yo.
- Traspasar todo al final del turno. Si cada ticket abierto se reasigna a las 5 p. m., has construido una máquina para perder contexto tres veces al día. Traspasa solo los tickets urgentes.
- Centros demasiado pequeños para sobrevivir a un festivo. Un centro de dos personas se queda en una en cuanto alguien está de baja, y esa persona es ahora el plan 24/7. Dimensiona para 6 a 8, o reduce la huella.
- Confiar en que los agentes cambien su propio estado. En Zendesk sobre todo, un estado Online olvidado significa tickets enrutados a alguien que duerme. Usa turnos automáticos donde tu plan los tenga, o una comprobación rápida al final del turno en tu rutina de triaje de tickets.
- SLA en horas naturales. Un ticket creado al final del día de una región incumplirá durante la noche y arruinará tu seguimiento de SLA sin motivo real.
- Medir los centros por separado. Mira el tiempo de primera respuesta por hora del día en toda la cola, no por oficina, junto con los demás KPI de atención al cliente. Los huecos aparecen en los límites, y los informes por centro los esconden.
- Olvidar el borde del día. Como dijo un sysadmin, si tu mesa cierra a las 17:00, "what happens if they have a critical incident at 16:50? Because that happens quite often" (fuente). Follow-the-sun multiplica esos momentos de las 16:50 por el número de centros.
eesel para el soporte follow-the-sun
Si llevas follow-the-sun con menos gente de la que pide el modelo, o piensas añadir un tercer centro sobre todo para cubrir las horas tranquilas, prueba primero a poner en ese hueco al compañero de helpdesk con IA de eesel. Se conecta con Zendesk, Freshdesk, Gorgias, Front y Help Scout, aprende de tus tickets pasados y tu centro de ayuda, y trabaja la cola a cualquier hora. Responde lo que tiene claro y deja el resto con una nota de traspaso para tu siguiente turno.
Antes de que toque un ticket real, puedes simularlo con cientos de tus tickets pasados y comparar sus respuestas con lo que tu equipo envió de verdad. Y como los precios son por ticket gestionado y no por puesto, cubrir el hueco nocturno no significa comprar las licencias de otra oficina entera.
Prueba eesel gratis y mira cómo se ve tu cola cuando las horas entre centros no están vacías.