Enterprise communications have changed dramatically, but in too many places, 911 still looks like it was assembled with duct tape, good intentions, and a purchase order from 1998. As companies consolidate networks, merge platforms, and modernize UC environments, maybe it is time to ask a simple question: why are we still building emergency calling like every call server lives on its own little island?
Today we’ll be talking about 911 as a Service, or 911aaS, in the enterprise network — and whether modern businesses should start thinking about emergency calling as a centralized, intelligent, resilient network service instead of a separate compliance project bolted onto every call server.
Recently, Metrigy President and Principal Analyst Irwin Lazar brought up an interesting point about 911 in the enterprise.
Irwin wondered what happens when modern companies, especially large enterprises, keep consolidating networks, merging businesses, and inheriting multiple communications platforms. One company may have Cisco here, Avaya there, Microsoft Teams everywhere, Zoom Phone in one division, Webex Calling in another, and a few “temporary” legacy systems that have somehow been temporary since the Bush administration.
And every one of those platforms may come with its own 911 solution.
That means its own location database.
Its own routing logic.
Its own carrier relationship.
Its own notification workflow.
Its own compliance checklist.
Its own testing process.
Its own support model.
And, because the universe has a sense of humor, its own mysterious failure mode that only shows up during budget season or an actual emergency.
I have known Irwin for more than a decade, and I have always admired his work and dedication to the emergency services space within corporate America. He understands that enterprise 911 is not just a regulatory checkbox. It is an employee safety issue, an operational risk issue, and, whether some folks like it or not, a public safety issue.
His recent article sparked a few neurons in my thick head, which, I will admit, still happens occasionally when coffee and irritation reach the proper ratio.
The question that kept bouncing around was this:
Why does every single call server require its own 911 solution?
Now, before everyone starts sharpening their vendor-branded pitchforks, let me be clear. I understand the architectural argument.
A multiline telephone system, or MLTS, often knows a lot about its users. It knows the phone, the extension, the device, the client, the subnet, maybe the Wi-Fi access point, maybe the room, maybe the building, and sometimes even whether Bob from accounting has once again decided to work from a conference room he did not reserve.
That system may be in a very good position to understand where a user is when they dial 911. It may also be able to pass that information to the correct emergency service provider, route the call appropriately, and notify internal security, reception, or a central alerting point.
That is a valid model.
For a single-site business, or even a moderately sized enterprise with one communications platform, that can make perfect sense. Keep the 911 logic close to the call server. Keep the routing simple. Keep the location management aligned with the platform that owns the endpoint.
But that model starts to get a little wobbly when the enterprise is no longer simple.
And most enterprises are no longer simple.
Today’s corporate communications environment often looks less like a neatly designed architecture diagram and more like a junk drawer with SIP trunks. There is a merger over here, an acquisition over there, a cloud migration in progress, a legacy PBX still hanging on because one factory phone in Ohio depends on it, and a UCaaS deployment that was supposed to simplify everything until everyone realized “cloud” does not magically remove complexity. It just moves the complexity somewhere with a better logo.
In that environment, every platform having its own 911 solution can become expensive, redundant, and operationally fragile.
It is like having twenty smoke detectors in your house, but each one reports to a different monitoring company, uses a different battery, has a different app, and one of them only works if someone remembers the admin password from 2017.
That may technically count as coverage.
It does not necessarily count as strategy.
This is where 911 as a Service starts to get interesting.
If a company has multiple call servers, multiple UC platforms, multiple locations, multiple carriers, and multiple administrative teams, maybe emergency services should not be treated as a feature of each individual phone system. Maybe it should be treated as a core network service.
In other words, instead of asking every platform to solve emergency calling independently, maybe the enterprise should centralize the emergency services logic at the core or regional level.
That does not mean the call server becomes irrelevant. The MLTS, UC platform, or collaboration service may still provide critical information. It may still identify the user, the endpoint, the network attachment point, the building, the floor, or the room. But rather than having twenty separate emergency call handling architectures, that information could feed into a common emergency services layer.
That layer could make routing decisions.
It could normalize location information.
It could manage notifications.
It could integrate with security operations.
It could support hybrid workers.
It could provide better audit trails.
It could apply consistent policy across the enterprise.
And, perhaps most importantly, it could be built with NG911 in mind instead of pretending the world stopped evolving in 1968.
Because let’s talk about that for a second.
If budgets are supposedly so tight — and we are told constantly that budgets are tight — why do enterprises continue to spend critical dollars maintaining emergency services technology and architecture based on ideas that were born before modern communications even existed?
1968 was a fine year for some things. But if your enterprise emergency calling strategy is still spiritually wearing bell-bottoms and waiting for the rotary dial to come back, we may have a problem.
Modern communications are no longer fixed, predictable, and neatly tied to a desk. Employees work from offices, homes, hotels, airports, shared workspaces, branch locations, temporary locations, and occasionally from places where the Wi-Fi password is written on a chalkboard next to the oat milk.
Devices move.
Users move.
Applications move.
Networks move.
But 911 still has to work.
Not “mostly work.”
Not “work if the spreadsheet is current.”
Not “work unless the user is on VPN, softphone, hotel Wi-Fi, or that one subnet nobody documented.”
It has to work when someone is scared, injured, threatened, confused, or unable to explain where they are.
That is a very different design requirement from ordinary business calling.
If a normal call fails, someone gets annoyed.
If a 911 call fails, someone may not get help.
That distinction matters.
Network resiliency, reliability, and redundancy are much easier to build today than they were even a decade ago. We have software-defined networking, cloud services, regional data centers, multiple access paths, automated failover, intelligent routing, and now even space-based connectivity from companies like Starlink and others.
When terrestrial infrastructure is damaged or completely wiped out by a hurricane, wildfire, flood, or other natural disaster, communications may not be limited to whatever wire is still hanging from the pole. Connectivity from above is becoming part of the resilience conversation.
That does not mean space-based services magically solve everything. They do not. Let’s not turn every satellite into a superhero with a cape and a monthly subscription. But they do create new options for backup, continuity, and restoration when local infrastructure takes a beating.
So if we can modernize connectivity, why not modernize emergency services architecture?
The larger the enterprise network becomes, and the more complex its communications environment becomes, the stronger the argument becomes for centralizing emergency services across the ecosystem.
Put something newer and more modern in place.
Build it with NG911 functionality.
Design it to transport relevant information from inside enterprise campus environments directly to the public safety entities that need it.
Think beyond just voice.
Think location.
Think identity.
Think floor plans.
Think building security.
Think responder access.
Think real-time notifications.
Think audit trails.
Think operational awareness.
Think about how information moves from the enterprise to emergency communications centers, first responders, security teams, and eventually across jurisdictions.
Today, that may mean supporting emergency calling across the United States. Soon enough, large multinational enterprises will need to think internationally as well. The concept of emergency services as a common enterprise service is not going to get less relevant as businesses become more distributed.
And yes, I know what some people are thinking.
“Fletch, you are dreaming again.”
Correct. Guilty as charged.
I am a dreamer. I will admit it. I like thinking past tomorrow, next week, and next year. That does not mean everything I imagine is easy. It does not mean every enterprise can flip a switch and suddenly have a perfect 911aaS architecture by lunchtime.
But it does mean we should stop pretending that yesterday’s architecture is automatically good enough for tomorrow’s risk.
The smart businesses will understand this.
They will recognize that there is value in centralizing common services.
Why buy twenty different versions of the same core capability when you can buy one good one for the core? And if you are nervous, buy two. Just to be sure. Redundancy is not paranoia when people’s lives are attached to the outcome.
This is not about removing responsibility from UC platforms or local systems. It is about recognizing that emergency services may be too important, too complex, and too cross-functional to be scattered across every communications island in the enterprise.
A modern 911aaS model could create a more consistent experience for users, better operational visibility for the enterprise, and better information flow to public safety.
It could also make compliance easier to manage.
Kari’s Law requires direct 911 dialing and notification to a central location. RAY BAUM’S Act requires dispatchable location with 911 calls. Those requirements are not going away. If anything, expectations around emergency calling will continue to rise as technology improves and users assume that location-aware systems should actually know where they are.
And that is not an unreasonable expectation.
If my pizza app knows which side of the building I am standing on, it is hard to explain why my emergency calling environment needs three databases, a carrier ticket, and a prayer candle to find the right dispatchable location.
Yes, I know the underlying systems are different.
Yes, I know public safety-grade accuracy and routing are not the same as consumer convenience apps.
Yes, I know 911 is more complicated than ordering extra cheese.
But that is exactly my point.
If it is that important and that complicated, why are we still treating it like an afterthought glued onto the back of each call server?
Emergency calling should be designed, governed, tested, and monitored as a critical enterprise service.
Not a feature.
Not an add-on.
Not a checkbox.
Not a “we passed the last audit, so please stop asking questions” item.
A service.
A real one.
One with architecture, ownership, monitoring, failover, testing, security, and accountability.
That is what 911aaS should mean.
Not just cloud-hosted 911 routing with a shiny dashboard. Not just another acronym that vendors can place on a slide and charge extra for. It should mean a thoughtful, modern emergency services layer that supports the full enterprise communications environment and connects intelligently to public safety.
Will this aggravate a whole bunch of vendors who have their own platform-specific solutions?
Probably.
But aggravating vendors with logical questions is kind of what I have been doing for several decades now. At this point, it may be less of a habit and more of a public service.
And to be fair, vendors should not see this only as a threat. They should see it as an opportunity. The enterprise market is changing. UCaaS, CCaaS, mobility, hybrid work, mergers, cloud migrations, and NG911 are all pushing emergency services toward something more integrated and more intelligent.
The vendors who understand that will build better solutions.
The ones who cling to old models may still sell boxes, licenses, and annual maintenance for a while.
But the direction of travel is obvious.
911 needs to become more centralized, more contextual, more resilient, and more aligned with how modern networks actually operate.
So yes, maybe 911 as a Service belongs in your network.
Maybe not everywhere.
Maybe not all at once.
Maybe not in the exact way I have described here.
But the conversation is worth having.
Because when someone dials 911 from inside your enterprise, they do not care which UC platform they are on. They do not care which business unit owns the call server. They do not care whether the company inherited the system through a merger. They do not care whether the location database was updated last quarter.
They care that help gets to the right place.
Public safety cares about that too.
And if we can build networks that route global video meetings, support hybrid work, fail over across clouds, and connect to satellites, then we can probably do better than a patchwork of emergency calling solutions duct-taped to every call server.
I think the smart businesses will agree.
Build for tomorrow.
Centralize what makes sense.
Redundantly protect what matters.
And remember that emergency calling is not just another communications feature.
It is the moment when your network stops being a business tool and becomes a lifeline.
Don’t forget to leave a comment and let me know. If you have any questions or want to suggest a topic of your own, reach out to me at Fletch911.