Elevator Emergency Phones for Government and Municipal Buildings

In many buildings, on-premises versus cloud is a preference. In government facilities, network architecture can become a procurement requirement. For facilities operating isolated or highly controlled networks, the ability to keep the system inside the agency's infrastructure may determine whether a solution can pass security review.

The constraint most vendors cannot meet

Government and municipal facilities may operate under network isolation or restricted-connectivity requirements. A cloud-hosted elevator phone can introduce an outbound dependency and a third-party data path that must be evaluated during security review.

An on-premises system removes the question. The PBX sits in your building, the calls stay on your network, and there is no external service in the path to assess, document or defend at review.

You own the equipment

Hardware is bought once and owned outright. It sits on your network, under your control, and it does not stop working because a contract lapsed or a vendor changed its hosting arrangements.

That matters more in public buildings than most places, because they are held for decades and their elevators are replaced on long cycles. Equipment you own and can service ages better than an arrangement you rent.

Someone has to answer, and it may be your own desk

Elevator emergency calls must be answered by trained personnel who can take action, without exception. Courthouses, city halls, agency headquarters, transit facilities, airports and public works buildings often already staff a security desk around the clock, and that desk can serve as the answering point where it is trained and resourced for it. Where that coverage does not exist, a monitoring provider is required, and the same equipment routes to them.

Which arrangement is acceptable is decided by your authority having jurisdiction. We work through that for your buildings rather than assert a general answer.

Elevator calls and 911 in the same platform

Where configured for PSAP operation, the platform can support elevator emergency calls and 911 within the same answering environment rather than through two disconnected processes. A call can be answered, assessed and escalated without the passenger being transferred, put on hold, or dropped between systems.

Know the phone works before anyone needs it

Emergency Communication Path Supervision, or ECPS, is the part of this that facilities teams notice first.

Verifying elevator phones used to mean sending someone to every car to press the call button and wait for an answer. In a portfolio of any size that is a day of work, done infrequently, and it only tells you the phone worked at the moment somebody stood in front of it.

LiftComm supervises the communication path automatically. Every elevator, every 30 seconds. If a path fails you get an alert immediately, not at the next inspection and not when a passenger is already stuck in the car.

One platform for every emergency point

Elevator phones are rarely the only emergency communication you run. Emergency help points, assistance points at gates, platforms and entrances, blue-light phones, parking structure call boxes. These are often separate systems from separate vendors, each with its own answering arrangement and its own failure modes.

They can be consolidated onto one platform. One place to answer them, one place to monitor them, one place to see what is working.

What the code asks, briefly

Elevator emergency communication is governed by ASME A17.1 and CSA B44, adopted state by state and city by city with local amendments. What applies to your building depends on which edition your authority having jurisdiction has adopted and on when the work is permitted, and current requirements apply to new installations and qualifying alterations rather than retroactively. In New York City the operative document is the NYC Building Code, Appendix K. We build to whichever edition governs your building, and we will tell you which one that is.

If you are writing the spec

Most of the government work we see starts with a specification rather than a purchase. If you are the person writing it, these are the lines that decide whether a compliant system can actually be delivered in your building:

• Architecture. If the project requires on-premises architecture, state it explicitly so a cloud-hosted product is not bid as an equivalent and security conflicts are identified before award.
• Answering point. Name who answers and require that coverage be continuous, with automatic fallback routing when the primary point does not pick up.
• In-car communication. Require voice plus visual and text messaging, so the system works for a passenger who cannot speak or hear.
• Supervision. Require automatic supervision of the communication path with immediate alerting, rather than periodic manual testing.
• Ownership. State that hardware is owned by the authority and remains operable independent of any external service.

We are happy to review a draft spec and tell you where it will cause you problems, whether or not we end up bidding it.

The products that go in

The surface mount unit is optional. It goes in place of the in-panel EAV where the car operating panel cannot be modified.

EAV Elevator Phone SeriesEAV Elevator Phone Surface MountMechanical Room | Security Desk Phone2Wire Network & POE ConverterOn-Premise PBX & Emergency Elevator Call System