Follow-the-sun support: the hours arithmetic nobody shows you

A week has 168 hours. A full-time analyst, on a standard 40-hour week, covers about a quarter of it. Follow-the-sun support is just the arrangement of shifts across time zones that fills the rest of that week without anyone working through their own night. The arithmetic is not complicated. Most vendor pages skip it anyway, because the honest version of it sometimes says you need fewer shifts than they're selling.

This matters because the shape of coverage — two shifts or three, how they overlap, where the handover sits — is a different decision from price. You can get the price comparison in the in-house-vs-outsourced-it-help-desk post. This one is about what each shift shape actually buys you in the client's local day, and where a third shift stops earning its keep.

The 168-hour week, and the 40-hour slice

Twenty-four hours times seven days is 168 hours, every week, no exceptions. A full-time employee under the standard US workweek definition works 40 of them — the threshold the Fair Labor Standards Act uses for overtime, and a reasonable proxy for what one analyst's roster actually contributes. Divide 168 by 40 and you get 4.2: the theoretical minimum number of full-time-equivalent staff needed to have someone on duty at every hour of the week, with zero slack.

In practice nobody runs at 4.2 FTE, because that number assumes no weekends off, no sick days, no annual leave and no training time. Real 24/7 rosters tend to sit closer to five or six FTE once you build in rotation and cover. That gap between the theoretical 4.2 and the practical 5–6 is the first place vendor maths gets fuzzy, because it's where the cost of a roster actually lives — not in the hourly rate, in the headcount needed to hold the shift pattern together.

But filling every hour with a body isn't the goal. Follow-the-sun exists because most support needs aren't evenly spread across 168 hours — they cluster around when the client's users are awake, plus a bit either side. The job is matching shift timing to that pattern, not maximising headcount.

What one offshore shift actually buys you in the client's day

Take a standard India day shift: 9:30am to 6:30pm IST. IST runs UTC+5:30. US Eastern Standard Time runs UTC-5. The gap between the two is 10.5 hours. Subtract that from each end of the shift and 9:30am IST becomes 11:00pm the previous day Eastern, and 6:30pm IST becomes 8:00am Eastern. One shift, no schedule changes, no night work for anyone — and it lands squarely on the hours a US client's own staff are asleep.

That's the entire trick for a US client: you don't need a night shift anywhere in the world. You need one day shift, in India, timed to fall on the client's overnight. For a UK client the same shift (UTC+0 or +1) lands at roughly 4am to 1pm UK time — covering the start of the UK day rather than the night, which is a different value and usually means an earlier India start if the goal is overnight cover instead.

This is why shift windows are a design choice, not a fact of geography. The named shift windows on the it-staff-augmentation and offshore-software-development pages exist because the right start time depends on what you're trying to cover in the client's day — overnight monitoring, early-morning triage before the client's own team logs on, or genuine round-the-clock coverage. Pick the target hours first, then work backwards to the shift.

When two shifts beat three

Most support needs aren't true 24/7 — they're extended hours. If the actual requirement is coverage from, say, 7am to 11pm client-local (16 hours), two 8-hour shifts tile it exactly: the client's own team covers the day, one offshore shift covers the evening and early hours. One handover each way. That's the whole roster.

True 24/7 needs a third shift to close the remaining 8 hours. A third shift means a third rostered headcount (see the FTE arithmetic above — it's not a third of one roster, it's its own roster sized the same way), a third daily handover, and round-the-clock pay for however many tickets actually fall in that gap.

• Count tickets logged in the proposed gap window over the last 30 days, not a guess
• If it's low single digits a week, a rostered third shift is an expensive way to answer a pager that rarely rings
• On-call escalation — one person reachable, not a seat staffed — usually beats a third shift at that volume
• If the gap window regularly carries real ticket volume, the third shift earns its cost

The test is arithmetic, not instinct: measure the gap-hour volume before you buy a third roster to cover it.

The handover is where the cost actually sits

Every shift boundary is a place a ticket can be re-explained, left untouched for an hour, or quietly dropped. Two shifts means one meaningful handover per cycle. Three shifts means three. The defect rate doesn't scale with headcount — it scales with the number of boundaries.

A handover that depends on two people talking live forces someone to stay late or arrive early just to overlap, which quietly turns a day shift into a half-night shift and defeats the point of running follow-the-sun in the first place. Across a 10-hour offset, that overlap call is rarely sustainable — it survives the first week and then starts getting skipped.

The version that actually works: the handover is a written artefact in the ticket system — status, owner, next action, what's blocking it — logged before the outgoing shift signs off, not spoken across a call. That's what makes service-desk-agents and system-administrators roles function across an offset: the incoming analyst picks the ticket up cold, from the notes, inside the first five minutes of their own shift.

If your handover design assumes a live call across a 10-hour-plus offset, you've built a shift pattern that won't survive contact with the calendar. Write it down instead.

Three shifts, correctly: the true follow-the-sun roster

For work that genuinely can't wait anywhere — a production system with users spread across regions, an incident queue with no safe idle hours — three 8-hour shifts tile the full 168-hour week without anyone ever working their own night. India covers one leg, a UK or European team picks up where India ends, a US or Canada team picks up where that ends, and the queue hands back to India to close the loop.

This is the pattern behind round-the-clock builds using devops-services, it-help-desk-outsourcing or system-administration capacity: each shift works a normal local day, and what moves between people is the ticket queue, not anyone's circadian rhythm.

The cost detail that gets missed: three shifts isn't 1.5 times the cost of two. Each shift still needs its own cover for leave, weekends and sickness, so the FTE multiple from the first section applies three times over, not once across the whole roster. Price it as three separate 4.2-to-6 FTE problems, not one big one divided by three.

When the answer is no

If the real need is business-hours support with occasional overflow, follow-the-sun is the wrong shape at any price. A single shift plus a documented on-call escalation covers it with one fewer roster, one fewer handover, and no idle seats paid for hours nobody uses.

If the work genuinely can't be handed off in writing — deep knowledge sitting in one person's head rather than in a runbook — a follow-the-sun model will fail at every boundary regardless of how clean the shift maths is. That's a documentation problem, not a headcount problem, and it needs fixing before any shift pattern is built around it.

We staff the offshore leg of these rosters ourselves — service-desk-agents, system-administrators, devops-engineers — so we have a direct commercial interest in you buying more shift coverage. The honest version of that interest: when the gap-hour ticket count is low, the right answer is on-call or a single shift, not a second roster. If the arithmetic in this piece says two shifts, buy two.

Sahil Dubey

Group Managing Director

Runs engineering and compliance across the group. Twenty years in infrastructure, most of it on the operations side of systems that were already in production when he inherited them.

• CISA
• AWS Solutions Architect – Professional
• Microsoft Certified: Azure Administrator Associate