Follow-the-Sun Customer Support That Doesn't Drop Tickets at the Handoff

Every support leader has heard the pitch: hire in three regions, hand off at the boundary, and you have 24/7 coverage at the cost of one team. Then the first P1 of the new model lands at 5:55 AM Manila time. The Manila agent has already started shutting down their queue. Dublin is not online for another 35 minutes. The ticket sits unanswered for 47 minutes. The customer churns.

Follow-the-sun support is the right model for a global product. It just needs to be designed, not assumed. Here is what actually works.

What "follow-the-sun" actually means

Three regions, staffed during their local business hours, with explicit handoffs between them. The shape most teams use:

APAC region: Manila or Sydney, covering roughly 9 AM to 6 PM local.
EMEA region: Dublin, Lisbon, or Cape Town, 9 AM to 6 PM local.
AMER region: Austin or Toronto, 9 AM to 6 PM local.

If the regions are picked well, the live coverage is roughly 22 hours a day with two short overlap windows where one region is winding down and the next is winding up. The two overlaps are where everything goes right or wrong.

The handoff is the entire problem

A follow-the-sun model is not a 24/7 rotation. It is six handoffs a day (three boundaries, two directions each). If those handoffs are sloppy, you have not built 24/7 support. You have built three separate eight-hour shifts that pretend to be one team.

The four things that go wrong at the boundary:

Tickets in flight. The Manila agent was actively replying to a customer when their shift ended. The reply sat as a draft. The customer waited 9 hours.
Context loss. Dublin opens the queue and sees 18 tickets they have never read. They start triaging from scratch.
Pinned customers. A VIP escalation was being handled by a specific APAC agent. They went to bed. The customer pinged again at 7 AM Dublin time and got a generic reply.
Sev-1 in the gap. A P1 alert fires during the 30-minute gap before Dublin clocks in. Nobody catches it.

Each of these is solvable. None of them solve themselves.

Step 1: define overlap windows that actually overlap

The most common design mistake: scheduling regions back-to-back with zero overlap. Manila signs off at 6 PM (Dublin 11 AM), Dublin starts at 9 AM (Manila 4 PM). On paper that is fine, but in practice the Manila agent stops picking up new tickets around 5:30 PM and Dublin spends their first 20 minutes drinking coffee and reading the queue.

Build in 30 to 60 minutes of real, paid overlap at every boundary. Dublin starts at 8:30 AM Dublin time, Manila ends at 6:30 PM Manila time, and both regions are live for an hour. That hour is when the actual handoff happens.

If your team is small enough that you cannot afford full overlap, at least schedule the senior agent in each region to overlap. Junior agents can stick to their core hours.

Step 2: write the handoff in a structured doc, not Slack

Slack handoffs degrade fast. By the second week, "anything I should know?" becomes "nothing crazy" and the receiving agent walks into a queue blind.

Use a structured handoff doc in your help-desk tool (Zendesk, Intercom, Front, HelpScout all support this in some form). One per region per day. Four sections:

## Handoff: Manila to Dublin, 2026-07-10

### In flight
- TKT-1834 (Acme Corp, Pro plan): waiting on customer for logs. SLA timer
  paused. Owner: stays Manila on return.
- TKT-1841 (Globex, Enterprise): drafted reply, needs second pair of eyes
  before sending. Dublin to review and send.

### VIP escalations
- Globex: outage incident, see PagerDuty INC-552. Customer expects an
  update by 11 AM Dublin time.

### Patterns / known issues
- Spike in login errors from EU customers since 14:00 UTC. Engineering
  notified, no fix yet. Reply template: SAVED-LOGIN-ISSUE-072.

### Quiet pile (no action needed)
- Standard onboarding tickets, low priority, can wait until tomorrow.

The Dublin agent skims this in 5 minutes and starts the day with full context. The Manila agent leaves clean.

Step 3: name a rolling on-call inside each region

Not every ticket gets handed off. Some need to stay with the same agent for continuity. The most common case: a customer mid-incident, where switching agents resets the trust and slows down resolution.

Each region has a rolling on-call slot. When a ticket is "sticky" (must stay with one agent), it is assigned to the on-call rather than the original agent. The on-call works the ticket through to resolution within their shift, or escalates it explicitly to the next region's on-call with a 5-min sync (yes, sync) call at the boundary.

This sounds heavy. It is not. The actual frequency of sticky tickets is one or two a week per region. Building a process for them prevents the "customer is panicking and three different agents have replied" failure.

Step 4: protect the boundary with auto-routing rules

Tickets that arrive within 30 minutes of a region's shift end should auto-route to the next region, not the current one. The Manila agent stops getting new tickets at 5:30 PM Manila time. The system queues them for Dublin, who gets them at the start of their shift.

Almost every help desk supports schedule-based routing rules. They are underused. Set them up region by region:

30-minute "wind-down" window before shift end: no new tickets to that region.
30-minute "ramp-up" window at shift start: normal routing.

This single rule eliminates the most common boundary failure: an agent starts a ticket, runs out of time, and leaves a draft.

Step 5: PagerDuty (or equivalent) for the 30-minute gaps

Even with overlap, there are 30 to 60 minutes per boundary where staffing is thin. P1 alerts that fire during this window need an escalation path that is not "the support inbox."

Pair every region with a paging rotation:

P1 in APAC hours: pages Manila on-call.
P1 in the APAC-to-EMEA boundary: pages both Manila and Dublin on-call.
P1 in EMEA hours: pages Dublin on-call.
And so on.

The boundary windows are double-paged on purpose. Yes, you will occasionally wake two people up. The cost of that is much lower than the cost of a P1 sitting in a queue for 35 minutes.

Step 6: know when each region is actually online

The whole follow-the-sun design assumes you know when each region's working hours actually are. In practice, regional schedules drift. A holiday in the Philippines, a heatwave that pushes Lisbon to a 3 PM siesta culture, a new hire in Dublin who works 8 to 4 instead of 9 to 5.

Maintain a single live view of when each agent and region is online. This is exactly what a Timezoners board is built for. Each agent's working hours go on the board. The board shows the green overlap windows between regions, makes regional gaps visible, and updates automatically as schedules change.

When a manager asks "do we have coverage at 4 AM UTC tomorrow?" the answer is on the board, not in three Slack threads.

Step 7: SLAs that account for the calendar, not just the clock

A naive 4-hour SLA is a trap when one region's shift is shorter than 4 hours. A ticket that arrives 30 minutes before a region's shift ends has a 4-hour clock that crosses two handoffs and three agents. By the time it breaches, nobody remembers who owned it.

Two SLA designs that work better:

Pause SLAs across handoffs that involve open questions to the customer. If you are waiting on the customer, the SLA stops. Most help desks support this; turn it on.
Tier SLAs by ticket type, not just plan. "Outage" gets a 30-minute SLA that operates 24/7, paged not queued. "Feature question" gets a 24-hour SLA that operates only during regional business hours.

Your customers do not actually care about a 4-hour SLA on a feature question. They care about a fast response on outages and reasonable responses on everything else. Design accordingly.

Step 8: weekly cross-region debrief

Once a week, all three region leads run a 30-minute debrief. Three things to review:

Handoff failures. Any ticket where the boundary slipped. Why. What to change.
Pattern detection. What is each region seeing that the others have not seen yet?
Coverage gaps. Holidays, vacations, hires, departures. Adjust the schedule before the gap arrives, not after.

Use the rotating-zone slot trick: schedule the debrief at 14:00 UTC one week, 21:00 UTC the next. Both slots are humane for two regions and inconvenient for one. Rotate fairly so the same region is not always the one staying late.

Where to go next

TL;DR

Build paid 30-to-60-minute overlap into every regional boundary.
Use a structured handoff doc, not Slack.
Auto-route tickets away from regions in their last 30 minutes.
Page across regions during boundary windows so P1s never fall in the gap.
Track regional coverage on a Timezoners board so the team can see (not guess) when each region is online.
Tier SLAs by ticket type. 24/7 only for outages, business-hours for everything else.