{"id":72,"date":"2026-06-08T17:07:23","date_gmt":"2026-06-08T17:07:23","guid":{"rendered":"https:\/\/datadrivenops.co\/blog\/?p=72"},"modified":"2026-06-08T17:07:24","modified_gmt":"2026-06-08T17:07:24","slug":"optimizing-your-follow-the-sun-model","status":"publish","type":"post","link":"https:\/\/datadrivenops.co\/blog\/optimizing-your-follow-the-sun-model\/","title":{"rendered":"Once It\u2019s Running:Optimizing\u00a0Your Follow the Sun Model"},"content":{"rendered":"\n

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\u2019s the right place to start. But the organisations I\u2019ve seen struggle with Follow the Sun aren\u2019t the ones that failed at implementation. They\u2019re the ones that succeeded at it \u2014 got the model live, declared victory, and then stopped actively managing it.<\/p>\n\n\n\n

A Follow the Sun model that isn\u2019t 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 \u2014 coverage exists, cases are being picked up \u2014 the deterioration isn\u2019t always visible until a customer escalation makes it unmistakable.<\/p>\n\n\n\n

This is the companion to the post on designing and implementing Follow the Sun<\/a>. It\u2019s 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.<\/p>\n\n\n\n

The Metrics That Tell You Whether It\u2019s Actually Working<\/h2>\n\n\n\n

The first thing most teams measure after a Follow the Sun launch is coverage \u2014 whether cases are being picked up across all hours. That\u2019s necessary but not sufficient. Coverage tells you the model is running. It doesn\u2019t tell you whether it\u2019s running well.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Handoff pickup time.<\/strong> 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\u201320 minutes of shift start. A centre that\u2019s spending the first hour reconstructing context from the previous shift\u2019s notes \u2014 or worse, contacting the outgoing centre to ask questions \u2014 is a signal that the handoff document isn\u2019t doing its job.<\/p>\n\n\n\n

First contact resolution by centre.<\/strong> 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 \u2014 but you can\u2019t diagnose which without the per-centre breakdown.<\/p>\n\n\n\n

Escalation origin vs. resolution centre.<\/strong> In a healthy Follow the Sun model, the centre that escalates a case and the centre that resolves it don\u2019t need to match \u2014 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\u2019s 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.<\/p>\n\n\n\n

\n

Coverage tells you the model is running. Handoff pickup time tells you whether it\u2019s running well. Most teams measure the first and ignore the second.<\/p>\n<\/blockquote>\n\n\n\n

The Handoff Document: What Mature Looks Like<\/h2>\n\n\n\n

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\u2019s enough to get the model running. It\u2019s not enough to keep it healthy for two years.<\/p>\n\n\n\n

A handoff document in a mature Follow the Sun operation has three characteristics the initial version typically lacks.<\/p>\n\n\n\n

It flags risk, not just status.<\/strong> \u201cCase open, customer waiting on engineering\u201d is a status update. \u201cCase open, customer waiting on engineering, this is their third escalation in 60 days, they have a renewal in 90 days\u201d 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.<\/p>\n\n\n\n

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

It gets audited, not just submitted.<\/strong> Build a weekly review of handoff document quality into your operating cadence. The review doesn\u2019t have to be exhaustive \u2014 spot-checking 3\u20134 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.<\/p>\n\n\n\n

The Cultural Problem Nobody Warns You About<\/h2>\n\n\n\n

The hardest Follow the Sun optimisation isn\u2019t operational \u2014 it\u2019s 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.<\/p>\n\n\n\n

At Tyco\/JCI, the Echt team was the hardest to bring into a \u201cone team\u201d mindset. They\u2019d served as the backup to North America before the model was formalised, covering all four products with genuine expertise. That history made them proud \u2014 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.<\/p>\n\n\n\n

What worked wasn\u2019t 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 \u201cone team\u201d identity builds from accumulated specific recognitions, not from general communications about collaboration.<\/p>\n\n\n\n

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 \u2014 though the performance data matters \u2014 but because of what it signals: that every centre\u2019s performance is visible to every other centre, that the operation is measured as a whole, and that each team\u2019s contribution to that whole is explicitly acknowledged. The implementation details of how we structured this at Tyco\/JCI are in the case study<\/a> \u2014 but the cultural logic applies regardless of the specific organisation.<\/p>\n\n\n\n

The Three Optimisations That Have the Most Impact<\/h2>\n\n\n\n

Once a Follow the Sun model is stable \u2014 roughly 6\u201312 months post-launch \u2014 there are usually three levers that produce the most meaningful improvement in model performance. Not all of them are obvious at go-live.<\/p>\n\n\n\n

\n
\n
1<\/div>\n
\n
Shift overlap design<\/div>\n
The overlap window between shifts \u2014 typically 30\u201360 minutes when both the outgoing and incoming centres are active \u2014 is where the most valuable optimisation happens. Most teams treat overlap as a handoff window. The mature use of overlap is joint case work: the incoming centre picks up a complex case while the outgoing centre is still available to brief them live. This is particularly valuable for Tier-2 escalations where written context can\u2019t fully substitute for a direct conversation. Map which case types benefit most from live handoff and design the overlap window to accommodate them.<\/div>\n

<\/p><\/div>\n

<\/p><\/div>\n

\n
2<\/div>\n
\n
Knowledge base distribution<\/div>\n
In most support organisations, knowledge base contribution is concentrated in the most senior agents. In a Follow the Sun environment, knowledge concentration becomes a coverage risk: if the agents who know how to resolve a particular class of issue are all in the same timezone, cases that require that knowledge will sit unresolved until that timezone is active. Deliberately redistributing knowledge base ownership \u2014 requiring each centre to own and maintain documentation for specific product areas or case types \u2014 distributes the institutional knowledge across the operation. This is the fix for the escalation origin\/resolution mismatch problem described above.<\/div>\n

<\/p><\/div>\n

<\/p><\/div>\n

\n
3<\/div>\n
\n
Reporting maturity<\/div>\n
The reporting infrastructure built at launch typically gives you centre-level performance data and global aggregates. What it usually doesn\u2019t give you is handoff-level data: how long cases sit between shifts, which handoffs produce smooth pickups and which produce delays, and how case age correlates with the number of centre transitions it\u2019s been through. Building this layer of reporting \u2014 which requires your ticketing system to log handoff events explicitly, not just case updates \u2014 is the investment that makes the other optimisations possible. You can\u2019t improve what you can\u2019t measure, and handoff quality is rarely measured well at go-live. Atlassian\u2019s incident management frameworks<\/a> and the Google SRE Book\u2019s on-call chapter<\/a> both address this reporting layer from different angles \u2014 worth reading alongside your own operational data.<\/div>\n

<\/p><\/div>\n

<\/p><\/div>\n<\/div>\n\n\n\n

The Most Common Mistake Once the Model Is Live<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

A Follow the Sun model needs a designated owner \u2014 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.<\/p>\n\n\n\n

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 \u2014 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.<\/p>\n\n\n\n

\n

Related reading<\/h4>\n