Follow-the-sun scheduling is the most agent-friendly way to run 24/7 support — yet most teams that try it get the implementation wrong and end up with messy handoffs, coverage gaps, and frustrated agents who feel like they’re working blind.
This guide covers everything: what the follow-the-sun model is, which companies use it, how to design your regional windows, how to manage the handoffs that make or break it, and the pitfalls that sink teams who rush the setup.
If you’re running a distributed support team across multiple continents, this is the model you should be building toward.
Follow-the-sun (FTS) scheduling is a 24/7 work model where teams in different geographic regions each cover their local daytime hours, and responsibility “follows the sun” westward as each region’s business day ends.
Instead of rotating night shifts through a single team (the traditional 24/7 approach), you leverage the fact that your people are genuinely spread across the globe. When your Asia-Pacific team clocks out, your Europe team picks up. When Europe clocks out, the Americas team is just hitting their stride. Nobody works nights. Nobody burns out on the graveyard shift.
The result: continuous coverage from agents who are alert, rested, and working at peak cognitive performance — because it’s the middle of their afternoon, not 3 AM.
At its simplest, follow-the-sun works like a relay race:
The intentional 1–2 hour overlaps between regions are your handoff windows — time for outgoing and incoming shifts to sync before the baton officially changes hands.
Follow-the-sun isn’t a startup idea. Some of the most operationally sophisticated tech companies in the world run on this model.
Atlassian — the makers of Jira and Confluence — operate engineering and support teams across Sydney, Amsterdam, Austin, and New York. Their distributed engineering model is explicitly follow-the-sun: teams hand off work daily so development and customer escalations move around the clock.
GitLab — a fully remote company with 2,000+ employees in 65+ countries — built their entire culture around asynchronous, follow-the-sun workflows. Their public handbook includes detailed documentation of how regional teams hand off issues, merge requests, and customer issues between time zones.
Automattic — the company behind WordPress.com and WooCommerce — runs Happiness Engineers (their support team) across dozens of countries, using staggered coverage so customers in any timezone get native-hour support.
HubSpot, Zendesk, and Salesforce all operate FTS support models at scale, with dedicated teams in APAC, EMEA, and Americas covering their respective daytime windows.
What these companies have in common: they treat handoffs as a first-class engineering problem, not an afterthought. That’s the key lesson.
Before going deeper, it’s worth being clear about what makes FTS different from other 24/7 approaches.
| Factor | Traditional Rotation | Follow-the-Sun |
|---|---|---|
| Who does night shifts? | All agents rotate through nights | No one — everyone works days |
| Team geography required | Single region (or willing to rotate) | Multiple regions across timezones |
| Handoff complexity | Low (same team, next shift) | Higher (different teams, cultures, tools) |
| Agent wellbeing | Night rotation causes burnout risk | Higher — no circadian disruption |
| Minimum team size | ~4–5 agents | ~6–8 agents across 2–3 regions |
| Documentation burden | Moderate | High — async handoffs require written context |
| Best for | Single-location or small distributed teams | Genuinely global distributed teams |
If your “global team” is really just agents in two timezones four hours apart, FTS probably isn’t the right model yet — a simple overlapping shift pattern works better. FTS pays off when you have agents spread across at least two continents with 8+ hours of timezone separation.
No overnight shifts. The most obvious benefit: every agent works during their local daytime. This eliminates the single biggest driver of burnout in 24/7 support operations. Agents sleep normally, perform better, and stay longer.
Higher quality at every hour. When a customer hits your chat queue at 2 AM UTC, they’re talking to an APAC agent for whom it’s 10 AM. That agent is alert and at peak performance — not running on four hours of sleep like they would be under a rotation model.
Natural redundancy across regions. A regional disaster, local holiday, or infrastructure outage in one location doesn’t take down your whole operation. The other regions can absorb load while the affected region recovers.
Faster escalation paths. When an issue can’t be resolved during one region’s window, it gets passed to the next region with fresh context rather than sitting in a queue overnight. For engineering incidents and complex customer escalations, this is a significant advantage.
Attracts global talent. Agents who want normal working hours — but happen to live in Manila, Dhaka, or Nairobi — become viable hires. You’re no longer limited to agents willing to work nights.
Handoffs are the Achilles’ heel. Every region transition is a potential failure point. If context isn’t transferred cleanly, issues fall through the cracks. The better your handoff process, the better your FTS model. The worse it is, the more problems you’ll have than you would with a single-team rotation.
Documentation burden is high. FTS runs on async communication. Every outgoing team must leave written context — what’s open, what’s urgent, what the customer was told last. Teams with weak documentation habits will struggle.
Cultural and language coordination. When APAC hands off to EMEA, you may be crossing language, communication style, and cultural norms. What’s considered urgent in one region may be triaged differently in another.
Timezone overlap windows are expensive. Those 1–2 hour overlaps where two regions are both staffed are your most expensive hours per coverage unit. You’re paying for two teams when you only need one.
Management complexity multiplies. Running three regional teams with three team leads, three holiday calendars, and three communication norms is significantly more complex than managing one team doing rotations. You need strong regional leads and consistent tooling.
The first step is deciding which regions you’re running and what UTC window each one covers.
The most common three-region FTS model looks like this:
| Region | Example Locations | UTC Window | Local Time (Approx.) |
|---|---|---|---|
| APAC | Philippines, India, Australia | 22:00–09:00 UTC | 06:00–17:00 local |
| EMEA | UK, Poland, South Africa | 07:00–18:00 UTC | 08:00–19:00 local |
| Americas | EST, CST, PST | 14:00–01:00 UTC | 09:00–20:00 local |
Notice the overlaps: APAC and EMEA overlap from 07:00–09:00 UTC. EMEA and Americas overlap from 14:00–18:00 UTC. These are your handoff windows.
If you’re running a two-region model (common in earlier-stage distributed teams), a typical split looks like:
| Region | Example Locations | UTC Window |
|---|---|---|
| APAC | Philippines, India | 22:00–12:00 UTC |
| Americas | US East/West Coast | 12:00–22:00 UTC |
This works but leaves less redundancy. A three-region model is more resilient.
Each regional team needs enough agents to cover their window including days off and leave absorption. Use this formula as a starting point:
FTE needed per region = (Hours covered per day × 7) ÷ 40 hours per agent × 1.2 buffer
For a standard 10-hour window, 7 days a week:
Realistically, most teams want 2–3 agents per active shift to handle volume, not just fill the seat. That means 4–6 agents per region is the practical minimum for a working FTS model.
The handoff window is the most critical design decision in any FTS schedule. Get it wrong and your whole system leaks.
A good handoff window:
Sample Handoff Note Template:
HANDOFF: APAC → EMEA
Date: [DATE]
Outgoing team: [NAMES]
Incoming team: [NAMES]
OPEN TICKETS REQUIRING ACTION:
- Ticket #1234: Customer waiting on billing refund. Escalated to finance 2h ago. No response yet. Follow up.
- Ticket #5678: Technical bug reproduced. Waiting on engineering. ETA unknown.
ESCALATIONS IN PROGRESS:
- Ticket #9012: P1 incident — customer down. Eng team aware. Check for update every 30 min.
WAITING ON CUSTOMER:
- Ticket #3456: Asked for logs 4h ago. Chase if no response by 12:00 UTC.
UPCOMING SPIKES / KNOWN ISSUES:
- Planned deployment at 10:00 UTC — may generate config-related tickets.
CONTEXT FOR INCOMING TEAM:
- High-volume day — US holiday marketing campaign ends today.This note gets written by the outgoing team at the start of the handoff window, reviewed together, and filed in your shared documentation system.
The overlap between two regional windows is more nuanced than just “two teams are both online.” You need to decide how to manage it.
Option A: Clean baton pass (recommended for mature teams)
One region hands off completely at a set time. The outgoing region finishes their notes and steps off new ticket assignments. The incoming region starts fresh from the queue. Overlap is used only for sync, not parallel coverage.
Pros: Clean accountability, no “whose ticket is this?” confusion Cons: Requires discipline to actually step away from new work
Option B: Shared queue overlap
Both regions work the same queue during the overlap window. More agents on deck = faster response times during a typically busy period.
Pros: Surge capacity during overlap, good for high-volume periods Cons: Duplication risk, confusion over ticket ownership, communication overhead
Option C: Tiered handoff
Complex/escalated tickets are handed off explicitly; simple new tickets go to the incoming team only. This works well when your ticket complexity is highly variable.
For most teams starting out, Option A is cleanest. Once your handoff process is mature and your tooling is solid, move to Option B or C for higher-volume windows.
Here’s a full weekly schedule template for a three-region FTS team with 12 total agents:
| Agent | Region | Mon | Tue | Wed | Thu | Fri | Sat | Sun | UTC Window |
|---|---|---|---|---|---|---|---|---|---|
| Maria | APAC | ✅ | ✅ | ✅ | ✅ | ✅ | — | — | 22:00–08:00 |
| Jose | APAC | ✅ | ✅ | ✅ | ✅ | — | ✅ | — | 22:00–08:00 |
| Rashed | APAC | — | ✅ | ✅ | ✅ | ✅ | ✅ | — | 22:00–08:00 |
| Priya | APAC | ✅ | — | ✅ | ✅ | ✅ | — | ✅ | 22:00–08:00 |
| Stefan | EMEA | ✅ | ✅ | ✅ | ✅ | ✅ | — | — | 07:00–17:00 |
| Layla | EMEA | ✅ | ✅ | — | ✅ | ✅ | ✅ | — | 07:00–17:00 |
| Adebayo | EMEA | — | ✅ | ✅ | ✅ | ✅ | — | ✅ | 07:00–17:00 |
| Carlos | Americas | ✅ | ✅ | ✅ | ✅ | ✅ | — | — | 14:00–00:00 |
| Mei | Americas | ✅ | ✅ | ✅ | — | ✅ | ✅ | — | 14:00–00:00 |
| Ahmed | Americas | — | ✅ | ✅ | ✅ | ✅ | — | ✅ | 14:00–00:00 |
| Nadia | Floating | Variable | Variable | Variable | Variable | Variable | Variable | Variable | Fills gaps |
| Tariq | Floating | Variable | Variable | Variable | Variable | Variable | Variable | Variable | Fills gaps |
Coverage result:
Floating agents fill gaps created by leave, OT events, and weekend surge periods.
“The next team will figure it out” is the death of a good FTS operation. If outgoing teams don’t write handoff notes consistently, the incoming team starts from zero on every escalated issue. Trust erodes fast.
Fix: Make the handoff note a non-negotiable end-of-shift task. Build it into your scheduling tool as a required step before logging off. Review compliance in your weekly team leads meeting.
What APAC considers a P2 (respond in 4 hours), Americas might treat as a P3 (respond in 24 hours). When priority definitions aren’t standardized globally, issues get downgraded in handoff and SLAs get missed.
Fix: Write a global priority matrix that every region operates from. P1 means the same thing in Manila as it does in Austin. Review it quarterly.
Your APAC team has different public holidays than your EMEA or Americas team. Forcing a global calendar creates situations where agents are expected to work on national holidays or, worse, are given days off they don’t observe.
Fix: Maintain separate holiday groups per region. Schedule coverage for regional holidays using agents from non-observing regions with appropriate compensation. A tool like Manage Roster handles this natively — you assign each agent to their regional holiday group and the system applies the right calendar automatically.
It’s tempting to cut the overlap to save cost. “EMEA clocks out at 16:00, Americas clocks in at 16:00, clean transition.” This sounds efficient but removes your error-correction buffer. Staggered start/end times exist for a reason.
Fix: Protect your 60-minute handoff overlap. It pays for itself in avoided dropped tickets and missed escalations.
Three regional teams that never interact become three separate teams, not one global team. Culture diverges, processes drift, and knowledge doesn’t transfer.
Fix: Run a weekly all-hands (rotating the time so it’s not always inconvenient for the same region). Maintain a shared knowledge base. Celebrate wins globally, not just regionally.
APAC is typically covering UTC late evening and overnight for Western customers. That window often handles lower absolute volume — but the tickets that arrive are disproportionately high-urgency (outages, billing emergencies, time-sensitive requests from customers who are awake when everyone else is asleep).
Fix: Don’t under-staff your APAC team based on raw ticket volume. Staff for ticket severity, not just count. Ensure your highest-tier agents are distributed across all regions, not concentrated in EMEA or Americas.
Once your FTS model is running, the operational challenge shifts from design to maintenance. This is where most teams either systematize or spiral.
What you need to manage on a daily basis:
What you need to manage weekly:
A follow-the-sun schedule has more moving parts than a standard rotation. You’ve got three regions, three holiday calendars, floating agents, handoff windows, and shift overlaps to manage simultaneously.
Spreadsheets were not designed for this. When you’re managing 12+ agents across three time zones:
The cost shows up in scheduling errors, missed coverage, and manager burnout — all of which compound.
Manage Roster is purpose-built for exactly this problem. The features that matter most for FTS teams:
| Feature | Why It Matters for FTS |
|---|---|
| 24-Hour Day View | See all three regional windows on one screen — instantly spot uncovered hours between handoffs |
| Regional Holiday Groups | Assign APAC, EMEA, and Americas agents to their own holiday calendars — no more global calendar conflicts |
| OT Event Management | Publish gap slots for floating agents to self-select; fills leave coverage without manager firefighting |
| Shift Overlap Visualization | See exactly which hours have two regions active — manage your handoff windows precisely |
| AI Schedule Assistant | Ask the AI to flag coverage gaps, suggest FTE changes per region, or rebalance after a leave request |
| CSV Bulk Import | Stand up a new region’s schedule in minutes, not hours |
The free tier supports up to 10 agents across any number of regions. For a two-region FTS model, that’s enough to run your full operation. For three regions, paid tiers unlock the additional agent slots and advanced analytics you need as you scale.
Use code BETA2026 at checkout for 20% off your first 3 months on any paid plan.
👉 Start free at app.manageroster.com
How many agents do I need to start a follow-the-sun model?
The practical minimum is 6–8 agents spread across at least two regions with 8+ hours of separation. Below that threshold, you don’t have enough redundancy per region to cover days off and leave without the model breaking. A two-region model with 3–4 agents per region is a solid starting point.
Does follow-the-sun work for engineering teams, not just support?
Yes — GitLab, Atlassian, and many others use it for software development. The same handoff principles apply: written context, clear ownership transfer, and documented escalations. For engineering, “work in progress” notes replace “open ticket” handoffs.
What UTC windows should each region cover?
A common starting point: APAC covers 22:00–09:00 UTC, EMEA covers 07:00–18:00 UTC, Americas covers 14:00–01:00 UTC. Adjust based on where your agents actually are — a team based in Manila has a different center of gravity than one based in Sydney.
How do I handle tickets that are still open at handoff time?
Tickets open at handoff are listed in the handoff note with their current status and next action. The outgoing agent retains ownership on in-progress tickets until the next handoff; the incoming team picks up new assignments from the queue. Complex escalations are verbally briefed during the overlap window.
What if one region is significantly smaller than the others?
Use floating agents to buffer smaller regions. A region with 2 agents instead of 4 is fragile when one person is sick or on leave. Float agents should be scheduled with enough region overlap that they can realistically step into any window.
How do I build a global team culture when teams never overlap?
Schedule a weekly cross-regional sync at rotating times (so the time burden rotates too). Maintain a shared team channel with daily wins and updates. Use asynchronous video updates (Loom, etc.) for announcements that everyone needs to hear. Culture is built in the systems and rituals you design — it doesn’t happen by accident.
Can follow-the-sun work with just two time zones?
It can, but it’s less resilient. Two regions with a 12-hour split gives you clean 24/7 coverage but no buffer if one region has a bad day. A third region doesn’t need to be large — even 2 floating agents in a bridging timezone significantly improves resilience.
Follow-the-sun scheduling is one of the best operational decisions a distributed support team can make — but only if the handoffs are designed deliberately, the documentation culture is built from day one, and you have the tooling to see across all three regions without living in a spreadsheet.
The teams that get this right — Atlassian, GitLab, Automattic — treat it as an engineering problem. Every handoff is a protocol. Every escalation has a path. Every region knows exactly where the baton is.
The teams that get it wrong treat handoffs as informal, documentation as optional, and wonder why issues keep falling through.
Manage Roster is free for teams up to 10 agents — with the 24-hour day view, regional holiday groups, OT event management, and AI scheduling assistant your FTS team needs to run without chaos.
Use code BETA2026 for 20% off your first 3 months on any paid plan.
👉 Get started free at app.manageroster.com
Related guides: