Was ist Follow-the-sun-Support?
Follow-the-sun-Support ist ein Abdeckungsmodell, bei dem die Support-Arbeit mit dem Tageslicht um den Globus wandert. Ein Team in Amerika arbeitet seinen Tag und übergibt die Queue an ein Team in Europa, das sie an ein Team im Asien-Pazifik-Raum übergibt, das sie wieder an Amerika zurückgibt. Jeder Standort arbeitet normale lokale Zeiten, und die Queue schläft nie.
Ich arbeite jeden Tag in der Support-Queue bei eesel und habe viel Zeit mit Teams verbracht, die 24/7-Support erreichen wollen, ohne eine Nachtcrew zu verheizen. Follow-the-sun ist die Variante, die auf dem Whiteboard am besten aussieht. Ein Ingenieur auf Hacker News hat es so sauber beschrieben, wie es nur geht:
"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."
Achte auf den Teil in Klammern. Die kurze Überlappung an jedem Schichtende ist der Moment der Übergabe, und mit drei Standorten hast du davon jeden Tag drei.
Das ist der Tausch im Kern des Modells. Du tauschst Nachtschichten gegen Übergaben. Ob das ein guter Tausch ist, hängt fast ganz davon ab, wie du mit diesen drei Grenzen umgehst, und darum geht es im Rest dieses Leitfadens.
Es ist ein enger Verwandter von Offshore-Support, und die beiden werden oft verwechselt. Bei Offshore geht es darum, wo das Team sitzt (meist wegen der Kosten). Bei Follow-the-sun geht es darum, wann jedes Team arbeitet. Du kannst Follow-the-sun mit drei eigenen Büros betreiben oder mit einem Onshore-Team plus einem ausgelagerten Standort auf der anderen Seite der Welt.
Zwei Standorte oder drei?
Die meisten Teams wählen zwischen drei Formen. So schneiden sie bei den Punkten ab, die wirklich wehtun.
| Modell | Standorte | Schichtlänge | Übergaben pro Tag | Hauptkosten |
|---|---|---|---|---|
| Nachtschicht an einem Standort | 1 | 8 Std., rotierend | 0 | Nachtarbeit, Mitarbeiterbindung |
| Follow-the-sun mit zwei Standorten | 2, etwa 12 Std. auseinander | ca. 12 Std., oder 8 Std. mit ungedeckten Rändern | 2 | Späte Abende und frühe Morgen |
| Follow-the-sun mit drei Standorten | 3, etwa 8 Std. auseinander | 8 Std. | 3 | Personal an jedem Standort |
| Ein oder zwei Standorte plus KI | 1 bis 2 | 8 Std. | 0 bis 2 menschliche Übergaben | KI-Einrichtung und Kontrolle |
Zwei Standorte sind der Startpunkt der meisten Teams, weil man nur zwei Büros braucht. Der Schmerz wandert an die Ränder der Schicht statt in die Mitte der Nacht:
"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."
Dafür müssen die beiden Standorte weit genug auseinanderliegen. Ein Kommentator auf r/devops, der eine Aufteilung zwischen den USA und Irland abwog, schrieb, es gebe "there isn't really enough difference in TZs to make that work cleanly", und das irische Team müsse wachsen, damit die Last nicht einseitig verteilt ist (Quelle).
Drei Standorte geben dir saubere 8-Stunden-Schichten, sind aber die personell teuerste Option. Im selben r/devops-Thread berichtet jemand, dessen Firma von einem Standort mit 24/7 (mit "a high burnout rate") über eine 12/12-Aufteilung mit einem US-Team zu einer 8/8/8-Aufteilung wechselte, indem ein britisches Team aus drei Leuten dazukam. Sein Urteil zu diesem Dreier-Standort:
"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."
Diese Zahl solltest du im Kopf behalten. Ein Standort mit zwei oder drei Leuten ist kein Standort, sondern ein Single Point of Failure mit Urlaubskalender. Wenn du nicht in jeder Region echtes Personal hinstellen kannst, schlägt ein kleinerer Fußabdruck plus etwas, das die Lücken füllt, meist eine dünne Rotation mit drei Standorten.
Die Nachtschicht an einem Standort sieht am günstigsten aus, besonders mit einem ausgelagerten Team. Sie verliert aber eher bei den Menschen als beim Preis. Ein MSP-Inhaber auf r/msp sagte es nach einer früheren Offshore-Nachtcrew unverblümt: "keeping people when they are being asked to work through their nights is something I feel never works well" (Quelle).
Wo Follow-the-sun scheitert: die Übergabe
Abdeckung ist der leichte Teil. Jeder Praktiker, den ich gelesen habe und der Follow-the-sun wirklich betrieben hat, sagt dasselbe: Der Schichtwechsel ist die Schwachstelle, nicht die Uhrzeiten.
Das erste Leck ist der Kontext. Jede Region sieht einen anderen Ausschnitt des Tages:
"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."
In einer Support-Queue sieht das so aus: Zwei Kunden stellen am selben Tag dieselbe Frage und bekommen zwei verschiedene Antworten, weil das EMEA-Team in seinem Morgen-Stand-up von einer Lieferverzögerung erfahren hat und APAC nie davon hörte. Darum sind konsistente Antworten über alle Schichten in diesem Modell wichtiger als fast überall sonst.
Das zweite Leck ist die Zuständigkeit. Der nächste Standort erbt ein Ticket, aber nicht das Fachwissen dahinter:
"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."
Das dritte Leck ist die Übergabe selbst als Aufwand. Eine Notiz muss geschrieben, gelesen und ihr muss vertraut werden. Eine für ein einzelnes kniffliges Ticket zu schreiben, ist in Ordnung. Dreißig um 16:55 Uhr zu schreiben, macht aus Notizen "ticket 4512, customer upset, pls check."
Das Nützlichste, was ich in der Recherche gefunden habe, stammt aus Zendesks eigenem Leitfaden zur Konfiguration eines Follow-the-sun-Modells. Bei der Beschreibung, wie das eigene Support-Team arbeitet, heißt es "there are no daily handoffs" und dass Tickets in der Regel bei dem Agenten bleiben, der sie übernommen hat. Das ist die Umdeutung: Follow-the-sun ist vor allem ein Routing-Problem, kein Übergabe-Problem. Neue Tickets gehen an die Person, die wach ist. Besitzer behalten ihre Tickets und nehmen sie morgen wieder auf. Nur die dringenden überqueren die Grenze, und die bekommen eine ordentliche Notiz.
Zwei weitere Dinge machen Standorte auf eine Weise ungleich, die ein Whiteboard nicht zeigt. Arbeitsrecht entscheidet, wer wirklich die Wochenenden abdeckt: Ein Hacker-News-Kommentator kam zu einer Firma mit "follow the sun rotation" und stellte fest, dass das US-Team den Support außerhalb der Zeiten für alle anderen machte, weil die anderen Länder strengere Regeln hatten (Quelle). Und manche Verträge schließen einen Standort ganz aus. Ein anderer Kommentator arbeitete mit Enterprise-Kunden, die nicht erlaubten, dass "a subcontractor in London provide support", weil ihre Daten die USA nicht verlassen durften (Quelle). Prüfe beides, bevor du dein drittes Büro wählst.
So richtest du Follow-the-sun-Support in deinem Helpdesk ein
So würde ich jedes Team der Reihe nach durchführen. Die Schritte sind in jedem Helpdesk gleich; der Tarif, den du für jeden freischalten musst, ist es nicht, darum gibt es nach den Schritten eine Matrix.
1. Lege pro Region eine Gruppe (oder ein Postfach) an
Lege pro Standort eine Gruppe an ("Support-Americas", "Support-EMEA", "Support-APAC") und ordne jeden Agenten seiner Heimatregion zu. Alles andere hängt an diesen Gruppen: Zeitpläne, Routing, Ansichten und Reporting. In Help Scout und Front entspricht dem ein Postfach pro Region.
2. Gib jeder Region eigene Geschäftszeiten
Jede Gruppe bekommt einen Zeitplan in ihrer eigenen Zeitzone. Dieser Schritt ist am häufigsten durch den Tarif gesperrt. In Zendesk können nur Enterprise-Tarife mehrere Zeitpläne anlegen; Suite Professional bekommt einen. Freshdesk lässt jede Gruppe eigene Zeiten führen (es nennt wörtlich "EU, North America, or Asia" als Beispiel), mit zusätzlichen Zeiten ab Pro.
Ein kleiner Stolperstein in Zendesk: Ein Geschäftsintervall darf nicht über Mitternacht gehen, eine Schicht von 22:00 bis 06:00 muss also in zwei Intervalle geteilt werden.
3. Richte deine SLAs auf Geschäftszeiten aus
Stelle jede SLA-Richtlinie so ein, dass sie Geschäftszeiten statt Kalenderzeiten zählt. So verletzt ein Ticket, das am Ende des APAC-Tages eintrifft, die SLA nicht, bevor das EMEA-Team sich anmeldet. Jeder Helpdesk hier unterstützt das, und Freshdesk-SLA-Richtlinien stoppen die Uhr außerhalb der Gruppenzeiten. Der Haken: Der Timer folgt dem Zeitplan, der am Ticket hängt, also muss Schritt 2 zuerst stimmen. In Front heißen SLA-Regeln jetzt Time-Goal-Regeln, und der Timer läuft weiter, während eine Konversation zurückgestellt ist, was viele überrascht.
4. Route danach, wer tatsächlich verfügbar ist
Dieser Schritt macht aus Follow-the-sun von "drei Teams teilen sich eine Queue" ein funktionierendes Modell. Die Zuweisung sollte Tickets nur an Agenten schicken, die gerade online sind. Genau das bedeutet intelligentes Routing in der Praxis. Zendesk Omnichannel Routing routet in jedem Tarif nach Status und Kapazität, und in Professional und Enterprise kann es ein wieder geöffnetes Ticket neu zuweisen, wenn sein Besitzer nicht verfügbar ist. Diese letzte Funktion ist die native Übergabe: Der Kunde antwortet um 2 Uhr seiner Zeit, der Besitzer schläft, und das Ticket wandert zu jemandem, der nicht schläft.
Eines solltest du vorab wissen. Zendesks Doku zu vereinheitlichten Agentenstatus sagt klar: "Operating hours won't set an agent's status." Agenten stellen sich selbst auf Online und Offline. Wenn jemand am Ende seines Tages vergisst, auf Offline zu gehen, füttert das Routing ihn über Nacht weiter mit Tickets.
Nur zwei der fünf Helpdesks, die ich geprüft habe, lösen das nativ. Freshdesks Agent Shifts (Enterprise) ändern die Verfügbarkeit automatisch nach den Schichtzeiten, jede Schicht in ihrer eigenen Zeitzone, wobei Schichten über Mitternacht nicht akzeptiert werden (mehr dazu in meinen Notizen zu Freshdesk Agent Shifts). Fronts Shifts (Enterprise) setzen Teammitglieder zu Schichtbeginn auf Available und zum Schichtende auf Out of office, und eine neue Kundenantwort entzieht die Konversation jedem, der nicht im Dienst ist, "so someone else can follow up."
5. Standardisiere die Übergabenotiz und lass dann KI sie entwerfen
Für die Tickets, die eine Grenze überqueren, legt fest, was eine Übergabenotiz enthält: was der Kunde gefragt hat, was versucht wurde, was bis wann versprochen wurde, wer es jetzt besitzt und der nächste Schritt. Packe es in ein Makro, damit die Vorlage einen Klick entfernt ist.
Dann hör auf, sie von Hand zu schreiben. Die meisten Helpdesks haben inzwischen KI-Zusammenfassungen genau dafür. Help Scouts AI Summarize nennt "handing off a conversation to another teammate" als Einsatzfall. Freshdesks Freddy-Zusammenfassung ist als Issue, Steps Taken und Outcome aufgebaut und enthält private Notizen. Fronts Zusammenfassungen aktualisieren sich mit jeder neuen Nachricht.
Achte auf die Limits. Zendesk hat Copilot-Ticketzusammenfassungen im Mai 2026 ab Professional verfügbar gemacht, aber als gemeinsamer Pool von 5 Nutzungen pro Agent und Monat (Zusammenfassungen und Schreibwerkzeuge zusammen), begrenzt auf 500 pro Konto. Ein Team mit drei Standorten und echten Übergaben verbraucht das in der ersten Woche, danach brauchst du das Copilot-Add-on. Mein Leitfaden zu Zendesk-KI-Zusammenfassungen erklärt die Einrichtung.
6. Führe eine Wissensdatenbank, die allen gehört
Der schnellste Weg, Regionen am Auseinanderdriften zu hindern, ist eine einzige Wissensdatenbank, aus der jeder Standort liest und die jeder aktualisiert. Wenn EMEA von der Lieferverzögerung erfährt, kommt sie vor Ende ihres Tages ins Help Center, nicht in einen Slack-Thread, in dem APAC nie zurückscrollt. Wenn du mehrere Sprachen bedienst, richte ein mehrsprachiges Help Center ein, statt jede Region ihre eigene übersetzte Kopie pflegen zu lassen.
Welcher Tarif schaltet was frei
Hier ist der günstigste Tarif, der jeden Baustein freischaltet, laut Preisseite und Help Center des jeweiligen Anbieters, Stand Oktober 2026. Preise gelten pro Agent und Monat bei jährlicher Abrechnung, und jeder Anbietername in der Kopfzeile verlinkt auf seine Preisseite.
| Funktion | Zendesk | Freshdesk | Help Scout | Gorgias | Front |
|---|---|---|---|---|---|
| Mehr als ein Zeitplan | Enterprise (Vertrieb) | Pro $55 | Plus $45 (Zeiten pro Postfach) | Basic (eigene Zeiten pro Kanal) | Professional $65 (Zeiten pro Postfach) |
| SLAs auf Geschäftszeiten | Suite Professional $115 | Growth $19 (1 Richtlinie), Pro für mehr | Standard $25 (1 Richtlinie) | Alle Tarife | Professional $65 |
| Verfügbarkeitsbasierte Zuweisung | Suite Team $55 | Pro $55 | Plus $45 | Alle Tarife | Professional $65 |
| Schichten, die den Status automatisch umschalten | Nicht nativ | Enterprise $89 | Nicht verfügbar | Nicht verfügbar | Enterprise $105 |
| KI-Übergabezusammenfassung | Professional, 5 Nutzungen/Agent/Monat; unbegrenzt mit Copilot $50 | Freddy AI Copilot $29 Add-on | Plus $45 und höher | Nicht bestätigt | Copilot $20 Add-on, in Enterprise enthalten |
Gorgias ist der Sonderfall, weil es nach Ticketvolumen bepreist wird, nicht pro Agent, und in jedem Tarif einen Schalter "Pause SLA timer outside of business hours" hat. Für ein wachsendes Team, das Agenten in einer neuen Region hinzufügt, ist dieses Preismodell freundlicher als jeder Tarif pro Lizenz, und seine Regeln können pro Region Autoresponder außerhalb der Geschäftszeiten senden.
Was Follow-the-sun-Support an Lizenzen kostet
Nimm die Faustregel von 6 pro Standort von oben: drei Standorte, 18 Agenten. So sieht die monatliche Helpdesk-Rechnung im Tarif mit Zeiten pro Region aus und im Tarif, der automatische Schichten ergänzt.
| Helpdesk | Tarif mit regionalen Zeiten | 18 Agenten / Monat | Tarif mit automatischen Schichten | 18 Agenten / Monat |
|---|---|---|---|---|
| Zendesk | Enterprise | Vertrieb kontaktieren | Nicht nativ | n/a |
| Freshdesk | Pro $55 | $990 | Enterprise $89 | $1,602 |
| Help Scout | Plus $45 | $810 | Nicht verfügbar | n/a |
| Front | Professional $65 | $1,170 | Enterprise $105 | $1,890 |
| Gorgias | Basic und höher | Nach Tickets bepreist, nicht nach Lizenzen | Nicht verfügbar | n/a |
Das gilt vor den Gehältern, und die Gehälter sind die wahren Kosten. 18 Agenten auf drei Büros verteilt sind ein ganz anderes Budget als die 8 oder 10, die ein Ein-Regionen-Team für dasselbe Ticketvolumen bräuchte, weil das Volumen nicht gleichmäßig über die Uhr verteilt ist. Die meisten Queues haben eine geschäftige Region und zwei ruhige, und im Drei-Standorte-Modell brauchen auch die ruhigen Standorte genug Leute für die Feiertage.
Hier lohnt es sich, die Zahlen ehrlich gegen die Alternativen zu rechnen, auch gegen die Rechnung KI vs. Offshore. Für kleinere Teams geht mein Skalierungsleitfaden für Startups dieselbe Entscheidung durch. Wenn zwei deiner drei Standorte vor allem existieren, um um 3 Uhr nachts "Wo ist meine Bestellung?" zu beantworten, ist das ein teurer Weg dafür.
Wo KI in ein Follow-the-sun-Modell passt
KI ersetzt das Modell nicht. Sie verändert, wie viele Menschen das Modell braucht, und nimmt den schlimmsten Job vom Tisch: die Person zu sein, die die ruhigen Stunden allein abdeckt.
Ich habe das bei vielen Einführungen bei eesel erlebt. Das Muster, das funktioniert, ist eng und langweilig, und genau deshalb funktioniert es:
-
KI deckt die Stunden zwischen den Standorten ab. In der Lücke beantwortet ein KI-Helpdesk-Agent die Routine-Tickets (Bestellstatus, Passwort-Resets, How-to-Fragen) aus deinem Help Center und früheren Tickets. Anytime Fitness betreibt über 5.000 Studios in mehr als 40 Ländern, und vor eesel wartete ein Mitglied, das um 22 Uhr eine Frage stellte, bis zum Morgen. Jetzt bekommen die häufigen Fragen zu jeder Stunde eine Antwort.
-
KI antwortet nur, wo sie sicher ist. Alles andere wartet unberührt auf die nächste menschliche Schicht. Ein CX-Lead mit rund 7.000 Tickets im Monat hat es besser formuliert, als ich es in einem Verkaufsgespräch könnte:
"I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."
-
KI schreibt die Übergabe. Bei Tickets, die sie liegen lässt, taggt und routet sie und hinterlässt eine interne Notiz, damit die Morgenschicht mit Kontext statt mit einer kalten Queue startet. Das ist das Problem der menschlichen Übergabe aus der anderen Richtung.
-
KI gibt jeder Region dieselbe Antwort. Sie liest aus einer Wissensdatenbank und einem Satz Anweisungen, sodass APAC und EMEA bei der Antwort zur Lieferverzögerung nicht auseinanderdriften können. Ein Service-Desk-Lead bei CartonCloud beschrieb die Wirkung in ihrer Fallstudie als "consistent, on-brand tone, still keeping our own style and still keeping that human touch".
Ein Team, mit dem ich arbeite, geht noch einen Schritt weiter und betreibt eine geplante "tägliche Support-Übergabezusammenfassung": Jeden Morgen schreibt der Agent alles auf, was in den letzten 24 Stunden in allen Regionen passiert ist, sodass jeder Standort mit demselben Bild in den Tag startet.
Eine ehrliche Warnung aus derselben Erfahrung. Bei einem langjährigen eesel-Kunden verhielt sich die KI rund um die Geschäftszeiten uneinheitlich, weil die Zeiten nur im Prompt-Text standen. Lege Geschäftszeiten und Übergaberegeln in den Einstellungen des Helpdesks selbst fest (die Zeitpläne, SLAs und das Routing aus den Einrichtungsschritten oben) und lass die KI sie lesen, statt sie in einem Absatz Anweisungen zu beschreiben und zu hoffen.
Häufige Follow-the-sun-Fehler
Die meisten davon habe ich in echten Queues gesehen, ein paar selbst gemacht.
- Zum Schichtende alles übergeben. Wenn jedes offene Ticket um 17 Uhr neu zugewiesen wird, hast du eine Maschine gebaut, die dreimal am Tag Kontext verliert. Übergib nur dringende Tickets.
- Standorte, die zu klein sind, um einen Feiertag zu überstehen. Ein Standort mit zwei Leuten ist auf eine Person geschrumpft, sobald jemand im Urlaub ist, und diese Person ist jetzt der 24/7-Plan. Plane für 6 bis 8 oder verkleinere den Fußabdruck.
- Darauf vertrauen, dass Agenten ihren Status selbst umschalten. Besonders in Zendesk bedeutet ein vergessener Online-Status, dass Tickets bei jemandem landen, der schläft. Nutze automatische Schichten, wo dein Tarif sie hat, oder einen kurzen Check am Schichtende in deiner Ticket-Triage-Routine.
- SLAs auf Kalenderzeiten. Ein Ticket, das am Ende des Tages einer Region entsteht, verletzt über Nacht die SLA und ruiniert ohne echten Grund dein SLA-Tracking.
- Die Standorte getrennt messen. Schau dir die erste Antwortzeit nach Tageszeit über die ganze Queue an, nicht pro Büro, neben den anderen Kundenservice-KPIs. Die Lücken zeigen sich an den Grenzen, und Berichte pro Standort verstecken sie.
- Den Tagesrand vergessen. Wie ein Sysadmin es ausdrückte: Wenn dein Desk um 17:00 schließt, "what happens if they have a critical incident at 16:50? Because that happens quite often" (Quelle). Follow-the-sun multipliziert diese 16:50-Momente mit der Zahl der Standorte.
eesel für Follow-the-sun-Support
Wenn du Follow-the-sun mit weniger Leuten betreibst, als das Modell verlangt, oder einen dritten Standort vor allem für die ruhigen Stunden erwägst, probiere zuerst eesels KI-Helpdesk-Teammate in diesem Slot aus. Es verbindet sich mit Zendesk, Freshdesk, Gorgias, Front und Help Scout, lernt aus deinen früheren Tickets und deinem Help Center und arbeitet die Queue zu jeder Stunde ab. Es beantwortet, wo es sich sicher ist, und hinterlässt den Rest mit einer Übergabenotiz für deine nächste Schicht.
Bevor es ein Live-Ticket anfasst, kannst du es gegen Hunderte deiner früheren Tickets simulieren und seine Antworten mit dem vergleichen, was dein Team tatsächlich gesendet hat. Und weil die Preise pro bearbeitetem Ticket gelten statt pro Lizenz, heißt die Abdeckung der Nachtlücke nicht, die Lizenzen eines weiteren Büros zu kaufen.
Teste eesel kostenlos und sieh, wie deine Queue aussieht, wenn die Stunden zwischen den Standorten nicht leer sind.