Follow-the-sun scheduling is a way of organising work so that a task never sits idle overnight. One team works on it during their normal day, then hands it to a team in another time zone that is just starting theirs. Nobody works a night shift, yet the work keeps moving.
It began in global software development and support, but it now fits any team whose customers sit on another continent. You do not need three offices either: two locations, or even staggered start times inside one country, already stretch coverage by several hours a day.
This guide covers how the model works, what the research shows about the speed gains, whether your team is ready, and how to run the daily handoff.
Key Takeaways
- Work passes from one daytime team to the next, so progress continues without night shifts.
- The speed benefit is real in theory but depends almost entirely on handoff quality.
- Small teams can start with two sites or staggered starts instead of new offices.
- Prezi and Zuora show two documented versions: 18 hours a day, and full 24/7 cover.
- Single ownership plus a short daily overlap window prevents most rework.
What Follow-The-Sun Scheduling Means
The model rests on a simple rule: at any moment, exactly one team owns the task. That team works on it during local business hours, then writes a handoff note and passes ownership to the next region before logging off. The customer sees continuous progress; the staff see an ordinary working day.
Most companies map this onto three regional blocks: the Americas, EMEA (Europe, the Middle East and Africa) and APAC (Asia-Pacific). Three sites roughly eight hours apart cover the clock, and two sites cover a long stretch of it.
The reason to bother is that customer service expectations no longer stop at your local closing time. A buyer in Singapore who reports a broken checkout at 9am should not wait for Denver to wake up. Follow-the-sun closes that gap without asking anyone to work at 3am.
- One owner at a time keeps accountability clear when something goes wrong.
- A short daily overlap window lets the two teams ask questions live.
- The model scales gradually: staggered starts, then a second site, then full 24/7 cover.
This is a coordination model, not a staffing trick. It works when cross-border teams share the same tools, definitions and idea of what “done” looks like.
Core Principles of the Follow-The-Sun Model
Three principles do most of the work. Get them right and the rest is tooling.
Continuous day-shift coverage
Teams in different zones pick up where the previous one stopped. As San Francisco signs off, Budapest is mid-morning. The point is not to squeeze more hours out of people but to stop the clock running while nobody works.
Structured handoffs and single ownership
Exactly one team owns an item at a time. The handoff note is the product of that ownership period, so treat it as a deliverable. A workable template covers four things: status, blockers, the next concrete step, and urgency.
Vague notes are the biggest failure mode. If the receiving team has to ask a question and then wait for an answer, you have not saved a day, you have lost one.
Planned overlap windows
Reserve a short window each day when both teams are online, typically one to two hours, and use it for open questions and quick decisions rather than status reports. Anything that can be written down should be written down, which is why asynchronous work habits matter more here than in a co-located team.
What the Evidence Actually Shows About the Speed Gain
Round numbers get quoted a lot in vendor material: “up to 30% faster delivery”, “15 to 20% more productivity”. These circulate without a traceable study behind them, so treat them as marketing. The most cited academic work is more cautious. Carmel, Espinosa and Dubinsky modelled follow-the-sun workflow in the Journal of Management Information Systems in 2010. Their starting observation is striking: a single-site team uses only about 17.9% of the available calendar time in a week, while an idealised four-site setup reaches roughly 71.4%.
That is the theoretical ceiling, and their central finding is that almost nobody reaches it. Duration falls only when reduced coordination inside each site outweighs the extra coordination needed between sites. Where handoff quality drops, adding more sites brings steadily smaller improvements.
Two conclusions follow. Hand over work that is small and self-contained rather than one interdependent lump. And treat handoff discipline as the mechanism that decides whether the model saves time at all, not an implementation detail.
Benefits that are easier to defend
Some advantages do not depend on modelling assumptions:
- Shorter waits for customers. A ticket raised at 6pm gets worked on that night by someone whose day has just begun.
- No permanent night shifts. You buy round-the-clock cover without the retention and health costs of night work.
- Better written records. Every handoff has to be documented, so the team builds a usable history instead of tribal knowledge.
That last point matters. Teams that adopt the model usually end up with better written communication than before, because it does not tolerate anything else.
How to Tell Whether Your Team Is Ready
Before you change anything, look at when your work actually arrives.
Map demand by region and hour
Plot incoming tickets by hour and region for a full month, looking for hours where volume is real but nobody is on duty. Record issue type as well as volume: a queue of password resets is a different problem from a queue of production outages.
Choose your coverage level
Full 24/7/365 cover makes sense when you support systems that fail expensively at any hour. For steadier demand, extended hours through scheduling tools and staggered starts cost far less for nearly the same result. Let the hourly ticket data decide.
Right-size the solution
For a small company the cheapest coverage extension is often not a new team. A good help centre and AI chatbots for routine questions absorb a large share of out-of-hours volume. Add a remote colleague in a distant zone before an office.
“Start where demand is highest and scale with proof, not guesswork.”
- Segment customers so live help goes to the cases that need a person.
- Set service level targets you can meet, then measure against them.
- Check that handoff habits work inside one office before stretching them across three.
How to Implement the Model Step by Step
Design the coverage pattern
Decide between three regional hubs roughly eight hours apart and a two-site starter that extends your day rather than filling it. Map peak hours against each site’s working day, then assign ownership for every handoff point. Check public holidays in each country now: a hub closed for a week creates a gap your plan has to cover.
Build the handoff ritual
Write the template once and make it mandatory: status, blockers, next step, priority. Add escalation paths and paging rules so urgent work does not wait in a queue for the next region. Documented standard operating procedures turn intent into habit.
Standardise tools and records
Every region needs the same ticketing system, project tracker and knowledge base. If one site keeps notes in a private document, the chain breaks there. Consistent naming and version control let anyone reconstruct what happened without asking.
Plan overlap and appoint regional leads
Schedule the daily overlap window and protect it. Give each region a lead who owns escalations, training and quality there. Leading a distributed team takes different habits from leading a co-located one, so staff the role deliberately rather than by seniority.
- Pilot one queue or project before rolling the model out widely.
- Define success up front, in measurable outcomes rather than activity.
- Train every region on the same playbook so handoffs look identical in both directions.
Tools That Make Handoffs Visible
The tooling question is simple: can anyone see who owns each item, what happened to it and when it moved? If yes, the stack is good enough. A searchable knowledge base and complete work logs carry context that would otherwise live in someone’s head. Ticketing systems such as Zendesk add private internal comments, which is exactly where handoff notes belong: attached to the item, not buried in a chat thread. Beyond that, four things earn their place:
- Time zone visibility. A shared view of who is online, so overlap windows are planned rather than guessed at.
- Automated alerts. Queue health and breached targets should surface on their own.
- Structured written updates. A consistent notes template beats free-form messages.
- Shift planning. Shift scheduling tools keep staggered starts from drifting into gaps.
Pick tools that integrate, and set access rules early so every region can act without waiting for permission.
Common Challenges and How to Handle Them
The barriers in multi-region work are rarely technical. They are cultural cues and unclear writing.
Communication and culture
Video calls are always inconvenient for someone, so rotate the meeting time rather than leaving one region dialling in at 10pm. Differences in how directly people give feedback cause more confusion than language does. Translation tools help with words, not norms, so make the norms explicit.
Watch the boundary too. A model designed to avoid night work recreates it if people feel obliged to answer messages after hours. Several countries have right to disconnect rules, and even where they do not apply, the expectation needs stating.
Handoff friction
Handoffs bottleneck when the receiving team cannot act on what they were given. Standardised templates fix most of it, and a two-minute screen recording fixes much of the rest, because showing a half-finished state is faster than describing it.
Measure the friction rather than guessing: how often the receiving team asks a follow-up question, how long until they acknowledge the item, and how much work gets redone. Reviewing a sample of notes weekly catches problems before customers do, and a written silent-meeting style review suits it well.
Two Documented Examples
Zendesk has published details of two setups that show the range.
Zuora runs 24/7/365 cover using staggered starts rather than night shifts. A team in Colorado begins at 8am Mountain Time, California teams start in waves at 7am, 8am and 9am Pacific, and the Beijing office starts at 7am, 9am, 1pm and 2pm China Standard Time. Open and pending items pass to the next team at the end of each shift, with the details in private comments on the ticket.
Prezi takes the simpler route. Teams in San Francisco and Budapest together cover about 18 hours a day, which Zendesk describes as meeting the company’s global support goals without aggressive hiring. Two sites, chosen well, get you most of the way. What to track:
- Cycle time from first contact to resolution, against your pre-rollout baseline.
- Follow-up question rate after each handoff, a direct measure of note quality.
- Rework: items reopened or redone after changing hands.
- Service level attainment, broken down by the hour the request arrived.
- Team satisfaction, which tells you whether the model is sustainable.
Conclusion
Follow-the-sun scheduling is worth testing when you have real demand outside your working hours and work that divides into pieces small enough to hand over cleanly. Run a pilot on one queue, with a written handoff template and a protected overlap window, then compare cycle times against the month before.
Be realistic about the payoff. The published research says the calendar efficiency on offer is large, and that most of it is lost to poor handoffs. The teams that benefit treat the handoff note as the job, not as paperwork at the end of it. As distributed work has settled into normal practice, that discipline pays off well beyond formal follow-the-sun rotas.
Found this useful?
Make SmartKeys a preferred source on Google, and our articles will surface more often in your Top Stories, AI Overviews, and AI Mode.
Add as Preferred Source
