Remote Work

Asynchronous SLAs for Global Support Teams: Hand-offs, Gaps and Targets

A support team with people in New York, London and Manila can cover most of the day without anyone working nights. But the hubs barely overlap, and a ticket that arrives at 4:30 PM in New York will wait for Manila to wake up. An asynchronous SLA makes that wait explicit: instead of promising a live answer, it promises a response within a stated number of hours, timed so that the next hub can meet it.

This guide shows how to map the hand-offs between three hubs with real clock times, how daylight saving time changes the gaps, and how to write SLA targets that match the hours your team actually covers.

24-hour UTC clock ring showing Manila covering 01:00 to 09:00 UTC, London 09:00 to 17:00 and New York 14:00 to 22:00 in January 2026, with a three-hour gap from 22:00 to 01:00 UTC
Diagram: a three-hub follow-the-sun day in January 2026, each hub working 09:00โ€“17:00 local time, drawn on a 24-hour UTC clock.

Follow-the-sun in one paragraph

In a follow-the-sun model, teams in different time zones pass work to each other at the end of their day, so an open issue keeps moving around the clock. Research on follow-the-sun software teams by Carmel, Espinosa and Dubinsky (Journal of Management Information Systems, 2010) found that the hand-off itself is what makes or breaks it: success depends on efficient scheduling and handing off of work, and on coordination within and between sites. In support, the hand-off is the ticket. An SLA is only as good as the next hub's ability to pick that ticket up and act on it without a meeting.

Map the real clock times first

Before setting any target, write down when each hub is actually working, in UTC. The table below assumes each hub works 09:00โ€“17:00 local time, Monday to Friday. Times were computed with Python's zoneinfo module for a Wednesday in January and in July 2026.

Hub (09:00โ€“17:00 local)UTC, 14 Jan 2026UTC, 15 Jul 2026
Manila (UTC+8, no daylight saving)01:00โ€“09:0001:00โ€“09:00
London (GMT / BST)09:00โ€“17:0008:00โ€“16:00
New York (EST / EDT)14:00โ€“22:0013:00โ€“21:00
Uncovered22:00โ€“01:00 (3 h)21:00โ€“01:00 (4 h)

The UK is on summer time from the last Sunday of March to the last Sunday of October, and the US from the second Sunday of March to the first Sunday of November. The Philippines has not used daylight saving time since 1990.

Four things follow from the table:

  • London and New York overlap for 3 hours for most of the year (14:00โ€“17:00 UTC in winter, 13:00โ€“16:00 in summer), and 4 hours in the few weeks when only the US has changed its clocks. That is the only window for a live hand-off between them.
  • Manila hands to London with no overlap in winter and one hour of overlap in summer, when London's day starts at 08:00 UTC.
  • New York to Manila is the hard hand-off. When New York closes at 17:00, it is 06:00 the next morning in Manila in winter (a 13-hour difference) and 05:00 in summer, when New York is on EDT (12 hours). Either way there is a gap of several hours with nobody on shift.
  • Daylight saving makes the gap bigger in summer. The Philippines does not change its clocks, so when London and New York move forward an hour, the uncovered window grows from 3 to 4 hours.
Two 24-hour UTC bars comparing hub coverage in January and July 2026: the uncovered gap is 22:00 to 01:00 UTC in January and 21:00 to 01:00 UTC in July
Chart: the same 09:00โ€“17:00 local shifts on a UTC axis in winter and summer. Only Manila stays fixed.

Set targets the next hub can meet

An asynchronous SLA ties each target to the hand-off pattern above, not to an ideal of instant replies. Most teams set targets by priority, and ITIL-style service desks derive priority from two ratings: impact (how many users or how much business is affected) and urgency (how quickly it hurts). Here is an example priority table for the three-hub team. It is not an industry standard; your numbers depend on your contracts, staffing and customers.

Priority (example)First responseStatus updatesWho covers the gap
P1 Critical: service down30 minutes, 24/7Every hourPaid on-call rotation, all hubs
P2 High: major feature broken4 clock hoursAt each hand-offOn-call only if the 4 hours fall in the gap
P3 Normal12 clock hoursDailyNext hub on shift
P4 Low / questions2 business daysWhen changedNext hub on shift

Note the difference between first response and time to resolution. Response targets are easy to promise across hubs because any hub can respond. Resolution targets depend on the specialists who own the fix, who may all sit in one hub. Many teams publish response targets to customers and keep resolution targets internal. The IT Process Maps ITIL checklist gives example resolution targets of 1 hour, 4 hours, 8 hours, 24 hours and 1 week for five priority levels, and stresses that they are only examples.

Worked example: one ticket, two seasons

A customer opens a P3 ticket at 16:30 New York time on Wednesday 14 January 2026. The target is a first response within 12 clock hours.

  1. Created: 16:30 EST = 21:30 UTC Wednesday. New York closes 30 minutes later.
  2. Deadline: 21:30 UTC + 12 h = 09:30 UTC Thursday, which is 17:30 in Manila and 09:30 in London.
  3. Gap: nobody is on shift from 22:00 to 01:00 UTC, so the ticket waits 3.5 hours.
  4. Manila starts at 09:00 local (01:00 UTC) and has until the end of its day plus 30 minutes to respond: 8.5 working hours.

The same ticket at 16:30 New York time on Wednesday 15 July 2026 is created at 20:30 UTC, because New York is on EDT. The deadline becomes 08:30 UTC, which is 16:30 in Manila. The ticket waits 4.5 hours with nobody on shift, and Manila has 7.5 working hours to respond. The SLA did not change, but the margin shrank by an hour because of a clock change in only one of the countries. If your targets are tight, re-check them each March and November.

The automated reply to that customer should match the target exactly: "We have received your request. A support engineer will respond within 12 hours." Promising 8 hours in the auto-reply while the SLA says 12 sets up a breach you never agreed to.

Timeline of a P3 ticket created at 21:30 UTC on 14 January 2026, waiting through the uncovered gap until Manila starts at 01:00 UTC, with the 12-hour deadline at 09:30 UTC
Diagram: the January example in UTC. The 12-hour clock starts in New York and ends in Manila's afternoon.
Odd but true: "PST" can mean Manila

Philippine Standard Time is officially abbreviated "PST" (or PhST), and the IANA time zone database prints PST for Manila: the same letters used for Pacific Standard Time (UTCโˆ’8), 16 hours away. A ticketing system that prints "05:30 PST" is ambiguous. Show times in UTC or with a city name, such as "05:30 Manila (UTC+8)".

Write the hand-off so nobody needs a meeting

Because New York and Manila never overlap, the ticket itself has to carry everything. A useful hand-off note has a fixed shape:

  • State: what has been tried and what the result was, with links to logs.
  • Next action: one specific step for the next hub, such as "ask the customer for the export file" or "re-run the sync after the fix deploys".
  • Deadline in UTC: the SLA due time, so nobody converts it in their head.
  • Owner: who is responsible until the next hand-off, by name or by queue.
  • Customer promise: what the customer was last told and when.

Store SLA timers in UTC. Fixed-length targets ("12 hours") do not change when clocks change, but anything tied to a local clock, such as "hand over at 17:00 London time", moves relative to the other hubs twice a year. Our guide to scheduling meetings across time zones covers the same daylight saving traps for live calls, and managing remote teams across time zones covers working agreements.

Holidays and the "business day" problem

Targets in business hours or business days need a holiday calendar for each hub. When Manila has a public holiday, the 01:00โ€“09:00 UTC block is uncovered for the day. Decide in advance whether the clock pauses, whether London starts early, or whether the on-call rotation covers it, and say which in the SLA. Count business days per hub, because a "2 business day" target may end on different dates depending on which hub owns the ticket. To check the current local time in New York, London and the other cities it lists, the timeandcal world clock shows ten clocks side by side with daylight saving applied. Manila is not one of the default cities, but any of the ten clocks can be switched to it, and it never changes from UTC+8 anyway.

Quick checklist

  • List each hub's working hours in UTC for both January and July.
  • Mark the uncovered window and decide who handles urgent tickets in it.
  • Use clock-hour response targets where hubs hand off; keep business-day targets for low priority.
  • Make auto-replies quote exactly the SLA target.
  • Use a fixed hand-off template with the deadline in UTC.
  • Re-check margins after the March and November clock changes, and for each hub's public holidays.

Frequently Asked Questions

What is the time difference between New York and Manila?+
Manila is on UTC+8 all year. New York is UTCโˆ’5 in winter and UTCโˆ’4 during daylight saving time, so Manila is 13 hours ahead in winter and 12 hours ahead from March to November.
Should SLA timers use business hours or clock hours?+
Clock hours are simpler across hubs because any hub can respond and they do not depend on holiday calendars. Business-hour targets suit low-priority work but need a working calendar and holiday list for each hub.
How do daylight saving changes affect an asynchronous SLA?+
A fixed target such as 12 hours does not change. But hubs in countries that change clocks shift by an hour against hubs that do not, so the uncovered window and the next hub's margin can change by an hour in March and November.
How do you handle public holidays in a follow-the-sun model?+
Decide in advance whether the SLA clock pauses, another hub extends its day, or the on-call rotation covers the missing hours, and write that choice into the SLA.

Sources

  1. "Follow the Sun" Workflow in Global Software Development (Carmel, Espinosa, Dubinsky, 2010) โ€” Journal of Management Information Systems
  2. Follow-the-sun โ€” Wikipedia
  3. Checklist Incident Priority (ITIL) โ€” IT Process Maps
  4. Philippine Standard Time โ€” Wikipedia

Check hub times side by side

The timeandcal world clock shows ten clocks side by side, preset to cities including New York and London, with daylight saving applied. Any of the ten can be switched to another city, such as Manila.

Open World Clock โ†’
Cecile Ancieux
Creator ยท Senior Web Developer & Data Privacy Advocate

Cecile is a software engineer with over a decade of experience building client-side JavaScript applications and open-source utilities. She writes and edits timeandcal's guides, checking dates, offsets and rules against the IANA time zone database and official sources.

More about Cecile โ†’