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.
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 2026 | UTC, 15 Jul 2026 |
|---|---|---|
| Manila (UTC+8, no daylight saving) | 01:00โ09:00 | 01:00โ09:00 |
| London (GMT / BST) | 09:00โ17:00 | 08:00โ16:00 |
| New York (EST / EDT) | 14:00โ22:00 | 13:00โ21:00 |
| Uncovered | 22: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.
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 response | Status updates | Who covers the gap |
|---|---|---|---|
| P1 Critical: service down | 30 minutes, 24/7 | Every hour | Paid on-call rotation, all hubs |
| P2 High: major feature broken | 4 clock hours | At each hand-off | On-call only if the 4 hours fall in the gap |
| P3 Normal | 12 clock hours | Daily | Next hub on shift |
| P4 Low / questions | 2 business days | When changed | Next 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.
- Created: 16:30 EST = 21:30 UTC Wednesday. New York closes 30 minutes later.
- Deadline: 21:30 UTC + 12 h = 09:30 UTC Thursday, which is 17:30 in Manila and 09:30 in London.
- Gap: nobody is on shift from 22:00 to 01:00 UTC, so the ticket waits 3.5 hours.
- 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.
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
Sources
- "Follow the Sun" Workflow in Global Software Development (Carmel, Espinosa, Dubinsky, 2010) โ Journal of Management Information Systems
- Follow-the-sun โ Wikipedia
- Checklist Incident Priority (ITIL) โ IT Process Maps
- 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 โ