What counts as a dispatchable location for remote and hybrid workers?

By Michael Obraitis, Managing Partner, and Michael Dale, CEO · Published August 17, 2026 · Last reviewed August 2026 · ADAM Pulse Knowledge Base · Emergency Calling Series

Short answer

A dispatchable location is the caller's street address plus whatever additional detail a responder needs to actually find them — floor, suite, room, apartment.

For remote and hybrid staff, the hard part is not the definition. It is that business phone identity stopped being a location signal. The same extension, the same direct number and the same softphone can be used from a headquarters desk on Monday and a kitchen table in another state on Wednesday. The emergency address has to follow the person. The payroll record does not.

Zoom Phone addresses this through nomadic emergency services and personal emergency addresses, which associate a user with a location based on detected network data rather than a static profile field. That machinery works. What defeats it is a short list of specific conditions covered below, and a consent problem that is organizational rather than technical.

What "dispatchable" actually demands off site

The FCC's plain-language guidance describes dispatchable location as "the street address of the caller and additional information, such as room or floor number, necessary to adequately locate the caller."

That is a summary, not the rule. The binding definition sits at 47 CFR § 9.3, it requires the validated street address, and it carves out Commercial Mobile Radio Service providers — both of which the summary omits. We quote it in full in [the pillar](/articles/karis-law-mlts-911-compliance#dispatchable-definition). Use the summary to orient; cite the CFR when it matters.

Either way, the word doing the work is necessary, and it is an environment question rather than a policy one.

That last note is the one people get wrong. Internal labels are only useful if a responder can act on them. "Pick Zone 7-C" means nothing to a paramedic at the loading dock. If your facility naming is internal shorthand, translate it before it goes in an emergency address.

Why remote work broke the old model

Fixed telephony carried an implicit assumption: the phone sat at a desk, the desk sat in a building, the building had an address. Every layer of that stack was static, so one address per user was correct by construction.

Cloud calling removed the first two layers and kept the third. A user profile still carries an address; it just stopped meaning anything about where the person is.

Consider a hybrid week. Monday and Tuesday at headquarters on the fourth floor, Wednesday and Thursday at home in another state, Friday at a branch office. Same extension all five days. Three genuinely different emergency addresses, and one of them is not a company property at all. Any design that reports a single static address is wrong on three days out of five.

The three conditions that defeat location detection

Zoom's detection hierarchy handles ordinary movement well. These are the cases where it does not, and the first two are not covered by Zoom's documentation at all.

VPN, particularly always-on

An always-on corporate VPN can present the user's traffic as originating from a corporate egress point. Any location logic that leans on IP data can therefore read a home worker as being inside a company building — and the failure is silent, because the system is confident rather than confused. It will not raise an undefined-location prompt. It will report an address, and the address will be wrong.

This is worse than having no location, because no location triggers the clearinghouse process where a human establishes where the caller is. A confidently wrong address sends responders to the wrong building.

Higher-priority signals in the detection hierarchy — switch MAC and port, wireless BSSID — are not tunneled, so a well-built configuration degrades more gracefully. But if your design depends materially on IP or subnet matching and you run always-on VPN, test that specific combination before you rely on it.

Virtual desktops and VDI

In a virtual desktop deployment the session runs somewhere the user is not. Where the softphone executes, where the media terminates and where the human is sitting can be three different places, potentially three different states.

Do not assume the hosted desktop's location is the employee's location. Validate what your actual architecture reports, with a real device in a real remote location, before production.

Temporary and undefined locations

Hotels, coffee shops, airports, a client site visited once. These are legitimately hard because there is nothing to pre-configure.

Zoom's desktop client can prompt a user on an unrecognized network to add or confirm an emergency address, which is the correct behavior. But the prompt only works if the user engages with it, which makes this a training problem more than a technical one.

Where nothing resolves, Zoom documents the fallback for US and Canadian users: report the confirmed default emergency address if the user has selected, created or confirmed one. If they never have, the location reports as unknown, which routes the call through a nationwide emergency services clearinghouse that establishes the caller's location verbally before passing it to the appropriate PSAP.

That is a genuine safety net and it should never be the plan.

The consent problem

For most organizations this, not configuration, is what stalls remote E911.

Accurate remote location requires two things from the employee: a device location permission, and a home address. Both are personal. Neither can be silently taken. And the request lands badly if the first time staff hear about it is a pop-up asking to share their location with a work application.

Zoom's Emergency Services dashboard reports how many users accepted the location prompt, and lets administrators re-trigger it for users who have not opted in — "find users who haven't opted in and choose to re-trigger the prompt for all users or for a selected group or groups." Re-triggering a prompt that someone has already declined, without explaining why, converts a solvable conversation into a policy dispute.

Get ahead of it by settling and publishing:

• what location information is collected, and what is not
• that it exists to route emergency help, not to monitor working hours
• who can see it
• how long it is retained
• how an employee updates or removes it
• what happens if they decline

Personal emergency addresses help here structurally: the employee's home is associated with their own user record rather than modeled as a company office in the corporate location tree.

Consult HR before the rollout, not after the first complaint. In some jurisdictions and under some works council arrangements, collecting home addresses and device location carries obligations of its own.

What to tell employees

Most training on this fails by explaining the feature instead of the stakes. Something close to this, sent before the permission prompt appears rather than after:

Your work phone travels with you. Emergency services cannot see where you are the way your mobile carrier can — they only get the address our phone system has on file. If you use Zoom Phone anywhere other than the office, please set a personal emergency address for that location, and answer the prompt if Zoom asks you to confirm where you are. It takes about a minute. We use this only to send help to the right place. It is not attendance tracking and it is not visible as a live location. One thing to know: calls from the Zoom mobile app do not use this system at all. They go through your phone's own carrier, the same as any mobile call.

That last point is the one people get wrong in an emergency, and it is worth repeating in onboarding.

Measuring readiness

Remote E911 is not a project that completes. Zoom's Emergency Services dashboard reports six things, and they split into two useful groups.

Coverage — are people locatable right now?

Enablement — is the machinery switched on?

Enablement is the leading indicator; coverage is the lagging one. Enablement gaps show up in coverage weeks later, when someone travels.

We deliberately do not publish target percentages, because we have no defensible source for an industry benchmark and neither does anyone else quoting one. What is defensible is the shape of the goal: treat users in unknown locations as a work queue with an owner, not a statistic in a monthly report. The dashboard's real-time location section lets an administrator "find the user, and either assign an existing address or create a new one that matches their current location", which makes that queue actionable.

Where remote deployments go wrong

1. Every user left on the headquarters address.
2. Treating the phone number as evidence of physical location.
3. Personal emergency addresses never enabled.
4. Undefined-location warnings visible in the dashboard and unworked.
5. Location permission requested with no explanation, then re-triggered after refusal.
6. Assuming a corporate IP proves the user is in a corporate building.
7. VDI or always-on VPN never tested from an actual remote location.
8. Company desk phones taken home with no process.
9. Mobile app behavior never explained to staff.
10. Remote work handled as an exception rather than as the normal operating model.

Lifecycle: onboarding and offboarding

Onboarding is the cheapest moment to do this well. A new hire has no habits to break and expects to be told how things work. Cover direct 911 dialing, personal emergency addresses, what the location prompt is for, what an undefined location means, and that mobile behaves differently.

Offboarding is where stale configuration is created. Reassigning devices, removing personal location associations, recovering relocated desk phones and updating common area devices all belong on the leaver checklist. A desk phone that went to someone's house in 2024 and never came back is still reporting an address to somebody.

Also re-check on: employee relocation, a new remote arrangement, an office move, a network redesign, a change in VPN architecture, device replacement, acquisition, and international assignment.

Frequently asked questions

Related articles

• Does Kari's Law apply to my phone system? — what the rules require, and the binding definition of dispatchable location.
• How long does Zoom Phone number porting take? — emergency calling belongs in the migration plan, not after it.
• How do you configure Zoom Phone for Kari's Law and RAY BAUM's Act? — the build this policy hands off to.
• Zoom topic hub — every live Zoom Phone, E911 and Zoom administration article in one place.

References

Primary sources first. The CFR is the rule; the FCC's web pages are summaries of it.

1. 47 CFR § 9.3 — the binding definition of "Dispatchable location"
2. FCC — 911 Dispatchable Location — plain-language guidance. Summary only; cite the CFR for the rule.
3. FCC — Multi-line Telephone Systems: Kari's Law and RAY BAUM's Act 911 requirements
4. FCC Report and Order 19-76 — PS Docket Nos. 18-261 and 17-239, GN Docket No. 11-117.
5. Zoom — Deploying a nomadic emergency services solution
6. Zoom — Monitoring emergency services readiness with Zoom Phone
7. Zoom — Viewing the Zoom Phone Emergency Services dashboard (KB0063054)
8. Zoom — Setting up nomadic emergency services (KB0062169)

ADAM Pulse reviews Zoom Phone nomadic emergency services for hybrid and remote staff: personal addresses, VPN and VDI detection, and the dashboard queue of undefined locations.