How to know when your remote team is actually available

You run a distributed team, and you keep hitting the same wall. Someone needs a colleague in another time zone and cannot tell whether they are around. A customer issue lands at 4pm and you do not know who is still reachable to take it. A handoff between regions slips because the two people were never online at the same time. The underlying question is simple and operational: is my team reachable when we actually need them?

Microsoft Teams seems like it should answer that. Every name has a colored dot. But the dot is built for one moment, not for the question you are really asking. This guide walks through what "available" means in Teams, the honest ways to see it over time, and how to do it without turning a coverage question into a surveillance one.

First, the framing that matters. Presence shows when someone was reachable in Teams. It does not show what work they did, how hard they worked, or whether they were "productive." Treat it as a reachability and coverage signal: evidence for a conversation about how the team is structured, not a verdict on a person. Everything below assumes that lens.

Why the green dot can't answer your question

The dot tells you one thing: is this person reachable in Teams right now. That is genuinely useful when you are about to message someone. It falls apart the moment your question involves time.

Three reasons:

• It is live only. The dot reflects this instant. There is no built-in way to ask what someone's status was yesterday at 2pm, or what the team looked like last Tuesday afternoon.
• It scrolls away. Even if you watch it, you are watching one frame. Glance away and the information is gone. Nothing is recorded.
• It is one person at a time. You cannot see coverage across a team or across time zones in a single view. You are checking dots one by one, in the moment, and reconstructing the picture in your head.

So the green dot answers "can I reach Sam now," but not "is the EMEA window covered on Thursdays," or "when do my US and APAC people actually overlap," or "has anyone been reachable during our stated support hours this week." Those are pattern questions, and a snapshot cannot answer a pattern question.

What "available" even means in Teams

Before trusting presence over time, it helps to know what the states mean. Teams blends a few inputs (device activity, app state, calendar, calls) into a single status:

Two things trip up leaders. First, away does not mean gone. Yellow just means Teams saw no keyboard or mouse input for about five minutes. The person could be heads-down in another app, on a phone call, or reading. It is a narrow signal, not "left the building." Second, a single dot is a snapshot. One yellow at 2pm tells you almost nothing. Yellow every afternoon for two weeks tells you something worth discussing. The pattern over time is the signal, not the frame.

That is the whole game: presence becomes useful when you can see it as a timeline instead of a dot. If you want the deeper breakdown of each state and where the dots stop being reliable, we cover it in Teams away vs idle vs offline.

The honest options for seeing availability over time

There is no setting in Teams that hands you presence history. To see availability as a pattern, something has to capture each change as it happens and store it. There are three realistic ways to do that. None is wrong; they trade cost against effort and durability.

Option 1: Eyeball it manually

Watch the dots, keep a mental note, maybe jot times in a spreadsheet. For one person over one day, this is fine. As an operating approach it does not hold up. It does not scale past a handful of people, it produces no record you can look back at, and it depends on you being at your desk watching at the right moments. You also cannot reconstruct last week, because nothing was saved. Good for a quick check, useless for coverage planning.

Option 2: A PowerShell script against the Graph presence API

Microsoft Graph exposes a presence endpoint. A modest PowerShell script can read it on a schedule and write results to a file or spreadsheet. This is the cheapest way to start collecting real history, and if you have someone comfortable with scripting it is a legitimate path.

Be clear-eyed about what you take on:

• It runs wherever you run it. If that machine sleeps or reboots, you get gaps in the data and may not notice.
• You own all the upkeep: the storage, the formatting, the charts, retention, and fixing it when Microsoft changes something.
• There is no access control or audit trail unless you build it.
• It is easy to point at the whole directory by accident, which is the over-collection you generally want to avoid.

It is a real option with a real bill: cheap in dollars, paid in your time and attention. We lay out the trade-off in detail in Presify vs a PowerShell script.

Option 3: A maintained tool that polls and stores it

The third option is a service that reads the Graph presence API on a regular schedule, stores each change, and turns it into timelines and trends, with the storage, retention, and access controls handled for you. You trade a subscription for not owning the upkeep, the gaps, or the plumbing. When you evaluate one, the questions that matter are whether it is read-only, whether it needs anything installed on devices, what it retains and whether you can delete it, and who can see the data.

What good looks like for a leader

Once presence is captured over time, the view a leader actually needs is not a wall of live dots. It is a few specific things:

• Presence timelines per person. A readable strip of when someone was available, away, busy, or offline across a day, a week, or a month, so you can see their actual working rhythm instead of guessing.
• Online-time trends. How reachable-hours are trending over weeks, per person and rolled up per team, so a drift in coverage shows up before it becomes a problem.
• Coverage across time zones. Where your regions overlap and where they do not. This is the view that answers "is the handoff window real" and "is anyone reachable during our stated hours."
• Anomaly flags with the math shown. A nudge when a pattern departs from its own baseline, with the calculation visible so you can judge it. The flag starts a conversation; it does not render a verdict.

The point of all of this is structural: spotting that a coverage window is thin, that two regions never overlap, that on-call is leaning on one person. Those are scheduling and staffing fixes, not performance accusations.

Doing this responsibly

Keeping presence history is reasonable, and it is also the kind of thing that erodes trust fast if you do it quietly. A few principles keep it on the right side:

• Tell your team that presence is kept. Openly, in plain language, ideally in a written policy. Quiet monitoring is the bigger risk than the legal one.
• Use it as context, not a verdict. Presence shows when someone was reachable, not what they did or why. A flag is a prompt to ask, not a conclusion.
• Collect the minimum. Presence and basic directory fields, nothing more. No message content, no screen capture, no keystrokes. Keep it only as long as you need it.
• Remember what it is. This is reachability and coverage, not productivity. The instant you frame it as a productivity score, you are measuring the wrong thing and you will get the wrong behavior.

For the legal and notice side in plain English, see is it legal to track employee Teams status. It is general information, not legal advice, and your own counsel should confirm your specifics.

How Presify fits

Presify is built for exactly this question. 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. The result is the leader's view described above: who is reachable, when, and where coverage is thin, seen as a pattern instead of a live dot.

What we are deliberate about:

• 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 and US-based. Your data is scoped to your Microsoft tenant and processed on US infrastructure, with bounded retention you control and per-user and workspace-wide deletion built in.
• Scoped responsibly. Guest accounts are not monitored, and Presify does not enroll users located in the EEA, the UK, Switzerland, or Canada. Anomaly flags always show the math, because the data is evidence for a conversation, not a verdict.

If you lead a distributed team and reachability 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.