The follow the sun model for one client inbox across time zones

The follow the sun model hands work from one region to the next as the business day moves around the globe. A client inbox is always staffed by someone who is awake. For support queues it is a coverage model. For client email it is a context problem, because the person who read the thread is asleep by the time the reply is due.

What is the follow the sun model?

Follow the sun is a way of staffing work across time zones so that it passes from team to team as each one's day ends. A thread opened in London at 4pm is picked up in New York, then in Singapore, then back in London the next morning. The client gets replies in hours around the clock. The phrase comes from IT support and outsourcing, where tickets are interchangeable and any agent can take any one.

Client email differs from a ticket queue in one respect that breaks the model. The thread travels. What the person knew when they read it does not. Anything learned on a call, in a chat, or from a year of working with that client stays in one head, in one time zone. So follow the sun for client inboxes has to be built around the handoff, and the sections below cover how.

Why does client email break across time zones?

The failure looks like this. A client in London writes at 4pm about a change to a project. Someone in London reads it, understands the context, replies to acknowledge, and logs off. The follow-up work happens in the American afternoon, done by someone who has the thread but not the conversation the London person had on a call two weeks ago. The reply that goes out is technically correct and misses the point. Nobody did anything wrong.

Three specific things go wrong, and they need separating because the fixes differ.

• Context does not travel. The thread travels, and what the person knew when they read it stays behind.
• Ownership goes fuzzy at the boundary. A thread half-handled at the end of a shift belongs to nobody for the eight hours until the next region logs on, which is where threads get old.
• The client sees the seam. Different tone, different level of detail, an answer that contradicts something from last week. Clients cannot see your rota, so inconsistency reads as disorganization.

None of these is a speed problem, since a distributed team has someone awake when a co-located one does not. They are continuity problems, which need a different fix. We wrote separately about why reply speed is the wrong scoreboard for account teams for much the same reason.

The handoff note that gets read

Handoff processes fail when the note is either too long to write or too vague to use. The version that survives a busy Friday afternoon has four lines and takes a minute or two per thread.

• Where it stands, in one sentence. The next person can read the thread; they need to know what has happened since.
• What I said we would do, in the words you used, with the date you gave. This is the line that prevents contradictions.
• What I am waiting on, from the client or from someone internal, by name.
• What I would do next, marked as a recommendation so the next person can disagree without feeling they broke something.

Write it as an internal note on the thread itself. The note has to be in the place the next person will already be looking, which is the conversation. A handoff note in a chat channel or a document is one nobody reads.

The second line pays for the whole practice. Cross-timezone contradictions come from a commitment made casually in a thread that the next person never sees. If your tooling extracts commitments and due dates from the conversation itself, that line writes itself, which is the point of tracking commitments in email.

Can a shared inbox distribute email fairly across time zones?

Yes, if it assigns by rule. The three mechanisms that ship in shared inbox tools, including Sektra, are assignment by rule, round robin, and workload. A rule routes mail by who sent it or what it is about, so a client's mail goes to the people who own that account. Round robin hands each new thread to the next person in the rota, which is fair by count. Workload assignment hands it to whoever has the fewest open threads, which is fair by load.

Fairness across time zones is a rule problem more than a counting problem. Round robin across three regions sends a Singapore thread to someone in New York who is asleep. The working pattern is a rule that scopes assignment to the region on shift, with round robin or workload inside that region. Then nobody wakes up to a queue that was theirs all night. The assignment lives in the shared inbox and the mail stays in Gmail or Outlook, so the pattern is the same on either.

What to look for in a tool when nobody overlaps

Shared inbox tools are designed for teams in one office. A few features matter much more when your team is not.

The last three rows are where the common tools stop. Front, Hiver, Missive and Help Scout each include assignment, notes and status, and none keeps a record of what a client was promised. We build Sektra to add that record: commitments and open questions per client. A silence watch with a day count you set tells you the day an account goes quiet. A morning digest has a Waiting on them list of threads where the client owes a reply. That record is the thing a distributed team cannot reconstruct by tapping someone on the shoulder. The customer success page shows how it supports a team split across regions.

How should you split the inbox across regions?

Three models, and the right one depends on how much your clients care who they are talking to.

• Follow the sun in full. Every thread is available to whoever is awake. Fastest replies, weakest relationships. Works for support-shaped inbound where the question matters more than the person answering it.
• Owned accounts with cover. Each client has a named owner in one region, and other regions cover outside those hours with a clear rule about what they may answer and what they hold. This is the model account teams settle on.
• Regional books. Clients are assigned to the region closest to them and stay there. Best relationships, no coverage advantage, and it only works if your client base splits cleanly by geography.

The second one is the hard one to run and the one named-account teams need. The rule that makes it work is written and boring. Cover may answer anything factual, anything already promised, and anything urgent. Cover does not commit to new work, does not renegotiate scope, and does not answer a complaint. Everything in that second list waits for the owner, with an acknowledgment sent immediately so the client is never left in silence.

What to measure

Four numbers tell you whether the handoff is working. None of them is average response time, which looks fine even while this is failing.

• Threads crossing a boundary unresolved. Count them weekly. The trend matters more than the number.
• Threads with a handoff note against threads without. If fewer than eight in ten carry one, the note is too long. Cut a line.
• Contradictions per month: any time your team told a client two different things. Painful to track, and the most telling measure you have.
• Oldest waiting thread at the start of each region's day. This catches the thread that fell into the gap between shifts, which is the failure this whole playbook exists to prevent.

Run those for a month before changing anything else. Expect the problem to concentrate in a handful of accounts, and expect them to be the largest, because they generate the most threads and the most casual commitments. That is also the pattern behind client relationships that die in silence. Two people replying to the same email is its daytime cousin.