Once It’s Running:Optimizing Your Follow the Sun Model

Most writing about Follow the Sun focuses on implementation: how to map the centres to GMT, how to design the handoff windows, how to get leadership to commit to the model before the first shift change. That’s the right place to start. But the organisations I’ve seen struggle with Follow the Sun aren’t the ones that failed at implementation. They’re the ones that succeeded at it — got the model live, declared victory, and then stopped actively managing it.

A Follow the Sun model that isn’t continuously optimised deteriorates. The handoffs get sloppy. The cross-regional reporting becomes stale. The teams start operating like four separate shifts again rather than one continuous operation. The seams come back. And because the model technically works — coverage exists, cases are being picked up — the deterioration isn’t always visible until a customer escalation makes it unmistakable.

This is the companion to the post on designing and implementing Follow the Sun. It’s about what comes after go-live: the metrics that tell you whether the model is healthy, the cultural work that turns four centres into one team, and the optimisations that matter most once the initial implementation is stable.

The Metrics That Tell You Whether It’s Actually Working

The first thing most teams measure after a Follow the Sun launch is coverage — whether cases are being picked up across all hours. That’s necessary but not sufficient. Coverage tells you the model is running. It doesn’t tell you whether it’s running well.

The metrics that actually diagnose the health of a mature Follow the Sun model are about handoff quality and cross-regional consistency, not just uptime.

Handoff pickup time. From the moment a case becomes the responsibility of the incoming centre, how long before a substantive action is taken? A healthy handoff produces a case action within the first 15–20 minutes of shift start. A centre that’s spending the first hour reconstructing context from the previous shift’s notes — or worse, contacting the outgoing centre to ask questions — is a signal that the handoff document isn’t doing its job.

First contact resolution by centre. When FCR is tracked globally, regional performance differences disappear into the average. Tracking FCR by centre in a Follow the Sun environment reveals which centres are resolving cases on first contact and which ones are consistently creating multi-touch cases that get passed on to the next shift. Persistent FCR gaps between centres are either a skills problem, a knowledge base problem, or a handoff problem — but you can’t diagnose which without the per-centre breakdown.

Escalation origin vs. resolution centre. In a healthy Follow the Sun model, the centre that escalates a case and the centre that resolves it don’t need to match — but you should be able to track the handoff chain. If escalations consistently originate from one centre and require resolution by a specific other centre, that’s a knowledge concentration problem. Certain skills or product knowledge are living in one timezone and the model is routing around them rather than distributing them.

Coverage tells you the model is running. Handoff pickup time tells you whether it’s running well. Most teams measure the first and ignore the second.

The Handoff Document: What Mature Looks Like

At go-live, most teams have a handoff document that covers the basics: open cases, their current status, any actions taken, and next steps. That’s enough to get the model running. It’s not enough to keep it healthy for two years.

A handoff document in a mature Follow the Sun operation has three characteristics the initial version typically lacks.

It flags risk, not just status. “Case open, customer waiting on engineering” is a status update. “Case open, customer waiting on engineering, this is their third escalation in 60 days, they have a renewal in 90 days” is risk context. The incoming centre needs to know which cases require a different quality of attention, not just which cases are open. This requires the outgoing centre to make a judgment call in the handoff, not just copy-paste the ticket status.

It has an owner, not a rotation. When handoff documentation responsibility rotates across the outgoing shift team without a named individual accountable for completeness, quality degrades. One person — typically the most senior agent finishing their shift — should own the handoff document. That ownership should be explicit in the operating model, not informal.

It gets audited, not just submitted. Build a weekly review of handoff document quality into your operating cadence. The review doesn’t have to be exhaustive — spot-checking 3–4 handoffs per week across centres is enough to identify patterns. If one centre is consistently producing thin handoff documents, the audit surfaces it before it becomes a customer-facing problem.

The Cultural Problem Nobody Warns You About

The hardest Follow the Sun optimisation isn’t operational — it’s cultural. Getting teams in four countries to think of themselves as one continuous operation rather than four separate teams that happen to share a ticket queue takes longer than the technical implementation and requires deliberate, ongoing effort.

At Tyco/JCI, the Echt team was the hardest to bring into a “one team” mindset. They’d served as the backup to North America before the model was formalised, covering all four products with genuine expertise. That history made them proud — and somewhat resistant to operating as one node in a global coverage model rather than the centre of a hub-and-spoke. The expertise was real. The identity attached to it was the obstacle.

What worked wasn’t top-down messaging about global teamwork. It was making cross-regional contribution visible. When an Echt engineer resolved a Shanghai-originated escalation, that handoff success got acknowledged in the weekly cross-regional call. When the North American centre had a knowledge gap on a European product and an Echt engineer filled it remotely, that contribution was named. The “one team” identity builds from accumulated specific recognitions, not from general communications about collaboration.

The cross-regional performance call is the single most effective cultural mechanism in a mature Follow the Sun model. Not because of what gets discussed — though the performance data matters — but because of what it signals: that every centre’s performance is visible to every other centre, that the operation is measured as a whole, and that each team’s contribution to that whole is explicitly acknowledged. The implementation details of how we structured this at Tyco/JCI are in the case study — but the cultural logic applies regardless of the specific organisation.

The Three Optimisations That Have the Most Impact

Once a Follow the Sun model is stable — roughly 6–12 months post-launch — there are usually three levers that produce the most meaningful improvement in model performance. Not all of them are obvious at go-live.

The Most Common Mistake Once the Model Is Live

The single biggest mistake I see organisations make once Follow the Sun is running is stopping the active management of it. The model gets launched, the coverage exists, leadership declares success and moves on to the next initiative. The cross-regional performance calls get less frequent. The handoff audit cadence fades. The reporting stays at the level it was at go-live.

A Follow the Sun model needs a designated owner — someone whose job includes watching the cross-regional metrics, running the handoff audits, facilitating the cross-regional calls, and raising flags when the model starts to deteriorate. That role is often informal at launch (it tends to fall to whoever led the implementation) and needs to be formalised once the model is stable. Without it, the natural entropy of a distributed operation will gradually erode the quality of what was built.

The organisations that get the most out of Follow the Sun are the ones that treat it as an ongoing operating model requiring active management — not a project with a go-live date and a completion checkbox. The implementation is the beginning of the work, not the end of it.