RAY BAUM’s Act requires your phone system to deliver a “dispatchable location” with every 911 call. Most IT leaders can recite that sentence. Far fewer can answer the question that actually determines compliance: what, specifically, counts as one?
The term has a legal definition, and the gap between that definition and what most phone systems send today is where compliance quietly fails. This article breaks down what the FCC means by dispatchable location, how the requirement differs by device type, and how to build location data that would hold up on the worst day your building ever has.
The legal definition, and the phrase that does all the work
The FCC defines a dispatchable location as the validated street address of the calling party, plus additional information such as suite, apartment, floor, or room number necessary to adequately identify the location of the calling party.
The operative words are “necessary to adequately identify.” A street address alone is a dispatchable location only when the street address alone is enough to find the caller: a single-story branch office, a small storefront. The moment your environment has multiple floors, multiple buildings, or long hallways of identical doors, the address stops being adequate and the additional detail stops being optional. The standard scales with your building, not with your phone system’s convenience.
A useful gut check: if a paramedic who has never seen your facility were handed exactly the location string your phone system sends today, could they reach the caller without stopping to ask anyone? If the honest answer involves a security guard, a tenant directory, or luck, you don’t have a dispatchable location. You have an address.
What “validated” means
Dispatchable location has a second requirement that gets less attention: the street address must be validated: matched against the authoritative address data used for emergency routing so the call reaches the correct PSAP and the address renders correctly on the dispatcher’s screen. An address that’s accurate in the real world but formatted in a way emergency systems don’t recognize can misroute a call or display incorrectly. This is why enterprise E911 platforms validate every address at entry rather than trusting whatever was typed into a spreadsheet years ago.
Fixed vs. non-fixed devices: two deadlines, two standards
RAY BAUM’s Act phased in by device type, and the distinction still shapes what you owe:
- Fixed MLTS devices (deadline January 6, 2021): desk phones and other devices that don’t move must deliver an automated dispatchable location with every 911 call. No exceptions, no fallback options.
- Non-fixed and off-premises devices (deadline January 6, 2022): softphones, laptops on Wi-Fi, and remote workers must deliver a dispatchable location automatically where technically feasible. Where it isn’t, the rules permit alternatives: user-confirmed location, or as a last resort, routing to a national emergency call center. The alternatives are a fallback hierarchy, not a menu; you’re expected to provide the best information technically achievable, not the cheapest option on the list.
This is where “we prompt users to update their address” earns scrutiny. A user prompt satisfies the rules only when automatic detection genuinely isn’t feasible, and modern platforms can detect network changes and resolve locations automatically for most scenarios. An organization leaning entirely on self-reported location for a workforce of roaming laptops is making a feasibility claim it may not want to defend to a regulator.
How granular is granular enough?
The FCC deliberately didn’t publish a square-footage threshold, which leaves organizations asking how far to subdivide. The practical standard used across the industry is response-time granularity: divide space until knowing the zone gets a responder to the caller without searching. In practice that means:
- Multi-story buildings: floor level at minimum; wing, suite, or room where floors are large.
- Campuses: the specific building, always. A campus-wide address is the classic failure mode.
- Large open footprints (warehouses, manufacturing floors, retail): named zones tied to physical signage, so “Zone 4: North Dock” on the dispatcher’s screen matches a sign a responder can see.
- Dense office space: room or suite numbers that match what’s posted on doors, not internal facilities codes nobody has ever seen in a hallway.
That last point matters more than it seems: a dispatchable location is only useful if it’s expressed in language a stranger can follow. Location data written for your facilities database instead of for a responder fails at the exact moment it exists to serve.
Building the location database: a practical sequence
For organizations starting from a street address and good intentions, the path to defensible dispatchable location data follows a repeatable sequence:
- Inventory every calling endpoint: desk phones, softphones, conference rooms, analog devices behind gateways, and the remote workforce. Devices that were never inventoried are the ones that surface during incidents.
- Walk the space with facilities and define zones at response-time granularity, using the names actually posted on walls and doors. This is a site-walk exercise, not a spreadsheet exercise.
- Validate every address against emergency routing data before it enters the system, so calls route to the correct PSAP and display cleanly.
- Automate what moves: tie softphone and roaming-device location to network detection so the data updates itself instead of waiting on users.
- Prove it with test calls from a sample of every zone and a rotation of remote workers, and keep the results as your compliance evidence.
Organizations are often surprised that the site walk, not the technology, is the longest step. That’s the right lesson: dispatchable location is fundamentally a truth-about-your-building problem, and the platform’s job is to make maintaining that truth easy.
Where location data goes stale
Dispatchable location isn’t a project you complete; it’s data you keep true. The mapping that was accurate at deployment decays through ordinary IT life: office moves and desk swaps, network changes that re-map switch ports, construction that renames wings, platform migrations that rebuild the phone environment on a new system, and mergers that inherit someone else’s assumptions. Each is routine. Each can silently detach a phone from its real location, and nothing looks wrong until a dispatcher reads the old data out loud during an emergency.
Treat location data like any other production system: assign an owner, review it on a schedule, verify it after every move or network change, and test it: 933 test calls exist so you can confirm what a dispatcher would see without dialing 911.
Dispatchable location tells responders where. Not what.
It’s worth being honest about the boundary of this requirement. Perfect dispatchable location gets responders to the right door. It tells them nothing about what’s behind it: a medical event, a fire, a threat. That’s the gap 9Line built Echo to close: real-time transcription of the 911 call, delivered to your response team, so the people moving toward the emergency know what the dispatcher knows. Location is the legal mandate. Understanding is the operational advantage.
The bottom line
A dispatchable location is a validated street address plus whatever additional detail it takes to walk a stranger to the caller, automatically, on every call, from every device the law covers. If your current 911 location data wouldn’t pass the paramedic test, the fix is a known process: validate addresses, subdivide space to response-time granularity, automate location for everything that moves, and keep the data alive. 9Line’s platform does exactly that, across Cisco Call Manager, Microsoft Teams Direct Routing, and BroadWorks environments, with no software to install and the most affordable pricing in the market. See where your location data actually stands.
