How to track team availability across time zones

You run people across regions, and the same question keeps surfacing. Was the APAC window covered yesterday afternoon, your time or theirs? Did anyone overlap with the EMEA handoff on Thursday, or did the baton drop because the two people were never online together? These are coverage questions, and they are fundamentally about time and place: was each region staffed during the hours it is supposed to work, and where do the regions actually overlap.

Microsoft Teams looks like it should answer this. Every name carries a colored dot. But the dot is built for one moment in one place, and a coverage question spans many moments across several time zones. This post covers why the green dot falls short across regions, what "covered" means, and how to read availability per time zone without turning a scheduling question into surveillance.

The framing first, because it shapes everything below. Presence shows when someone was reachable in Teams, not what work they did or how hard they worked. Across time zones, treat it as a coverage and reliability signal about the team: evidence for a conversation about how the schedule is built, not a verdict on any one person. A thin window is a staffing fact, not an accusation.

Why a live green dot can't answer a coverage question

The dot tells you one thing: is this person reachable in Teams right now, in your current moment. That breaks down across regions for three reasons that compound.

• It is live only. There is no built-in way to ask what the EMEA team looked like at 3pm London time last Tuesday, or whether anyone in APAC was reachable during their own morning.
• It is one person at a time. You check dots one by one and rebuild the regional picture in your head. Across three or four zones that is guesswork, and it is gone the moment you look away.
• It is anchored to your clock, not theirs. This is the one that quietly defeats time-zone coverage. You read a teammate’s dot against your own working hours. Gray at what reads to you as mid-afternoon might be normal evening for them, or a real gap in their morning. A single dot cannot tell those apart, because it does not know whose business hours you are asking about.

So the dot answers "can I reach Mara now," but not "was the Singapore window covered during Singapore business hours this week," or "when do my New York and Berlin people actually overlap." Those are pattern questions about specific regions over time, and a snapshot, read against the wrong clock, cannot answer them.

What "covered" means when your team is spread across regions

Two ideas do most of the work here.

Per-region business hours. "Covered" only means something relative to the hours a region is meant to work. If your EMEA group works roughly 9 to 5 Central European Time, the question is whether someone was reachable inside that window, in that zone, not whether they were online when it happened to suit headquarters. Coverage has to be judged in each person’s local time, or you are measuring the wrong window.

Overlap windows. The other half is the seam between regions: the stretch where two zones are both inside business hours at the same wall-clock moment. That overlap is where live handoffs and quick syncs happen. If two regions never overlap, every handoff is asynchronous by force, and you want to know that on purpose, not discover it when something slips.

Put those together and a fuzzy worry ("are we covered?") becomes a pair of answerable questions: was each region reachable during its own business hours, and where do the regions overlap. Here is the shape of it, one region per row, read in each region’s local time:

Read across a row and you can see whether a region held its own window and where it touches the rest of the team. That is the view the green dot cannot assemble, because it has no memory and no notion of whose clock to use. For the broader version of the reachability question on a single team, see how to know when your remote team is available.

How to read availability per time zone

There is no setting in Teams that hands you presence history, let alone history sorted by region and judged in local time. To answer coverage across zones, something has to do three things together.

Capture and store each change. A collector reads the Teams presence state on a short, regular schedule and records each transition between available, away, busy, and offline. That stored stream is what lets you look back at a week or a month instead of squinting at a live dot.

Judge each person in their own time zone. This is the step that makes cross-region coverage honest. The same presence stream has to be read against each person’s local business hours, not a single company clock. "Reachable at 10am" should mean 10am where they are. Get this wrong and a perfectly covered region looks like a gap because you read it against headquarters’ afternoon.

Overlay business hours, per user, in local time. With presence stored and anchored to each person’s zone, a business-hours overlay turns the timeline into an answer: whether someone was reachable inside each region’s working window, and where regions line up at the overlap seam. "Was someone available in every region during business hours" stops being a hunch and becomes a number.

Done this way, the analysis stays a property of the schedule. You are looking for structural facts: a window that leans on one person, two regions that never meet, an after-hours stretch nobody covers. Those are staffing fixes, not performance findings.

What good looks like for a leader running regions

Once presence is captured and read in local time, the view a distributed-team leader needs is a few specific things:

• Per-person timelines in local time, with a business-hours overlay. Each person’s available, away, busy, and offline strip, drawn against their working window, so "they were online" becomes "they were online during the hours we cover," region by region.
• Online-time trends per person and per team. How reachable-hours are trending over weeks, rolled up per region, so a coverage window quietly thinning out shows up before a handoff breaks.
• Anomaly flags with the math shown. A nudge when a region’s pattern departs from its own baseline, with the calculation visible. The flag starts a scheduling conversation; it does not render a verdict on a person.

The payoff is structural. You can see that the APAC evening is thin, that EMEA and the West Coast barely overlap, that on-call across zones leans on one tired person. Each is a schedule you can fix, not a performance problem to litigate.

Doing this responsibly across regions

Keeping presence history is reasonable. Doing it quietly is the fast way to lose a distributed team, and spreading people across borders only widens the obligations. A few principles:

• Tell your team that presence is kept, in plain language, ideally in a written policy every region can read.
• Frame it as team coverage, not individual surveillance. The unit is the region and the window, not a scoreboard of people. Presence is reachability, never a way to "catch" anyone.
• Collect the minimum: presence and basic directory fields, nothing more, kept only as long as the coverage question needs it.
• Mind where people sit. Notice and consent rules differ by jurisdiction and change over time, and some regions you simply should not enroll. Confirm your specifics with your own counsel; this post is general information, not legal advice.

How Presify fits

Presify is built for exactly this coverage question across regions. It reads Teams presence (available, away, busy, offline) through the Microsoft Graph presence API on a short, regular schedule, stores each change, and turns it into presence timelines, online-time trends, and anomaly flags, per person and per team. Crucially for distributed teams, it carries a per-user time zone and draws a business-hours overlay in each person’s local time, so "was every region covered during its own hours" is something you can read, not guess.

What we are deliberate about:

• Local-time coverage, not a single company clock. Each person’s presence is judged in their own time zone, with a business-hours overlay per user, so a covered region never reads as a gap just because you are looking from headquarters.
• Read-only and minimal. Presify reads presence plus the basic directory fields it needs to label and scope users. It never touches message content, chats, calls, files, or calendars.
• No agent. Setup is a one-time, read-only Microsoft 365 admin consent. Nothing is installed on anyone’s device, and there are no screenshots and no keystroke logging, ever.
• Tenant-isolated, US-based, scoped responsibly. Your data stays scoped to your Microsoft tenant on US infrastructure, with bounded retention and per-user and workspace-wide deletion. Guest accounts are not monitored, and Presify does not enroll users in the EEA, the UK, Switzerland, or Canada. Anomaly flags always show the math, because presence is evidence for a conversation, not a verdict.

If you lead a team spread across time zones and "was each region covered" is the question you keep running into, the landing page for Presify for remote and hybrid teams walks through the use cases. When you are ready, see how Presify works or start with one Microsoft sign-in.