A Postcode Is Not a Plan: Verifying Emergency Call Routing in Cloud Telephony

When a UK organisation moves its phone system to the cloud, much of the planning focuses on call quality, number porting and user adoption. Emergency calling is usually mentioned once, agreed to be important, and then left to a configuration screen that few people revisit. That is a fragile arrangement. In a cloud telephony estate, the address associated with a user, device or site is not simply an HR record. It is an operational input that can determine where an emergency call is presented and what location information the provider is able to pass on.

The practical risk is not that cloud phones cannot support 999 or 112 calls. It is that the information behind those calls drifts as people move, sites change and devices multiply. A postcode in a spreadsheet is not a plan. The plan is a repeatable process for checking that every route to the emergency services carries the right location, the right call-back number and the right internal escalation.

Location is a configuration item

In a traditional fixed-line estate, the link between a handset and a building was physical. In a cloud estate, the link is logical. A user may work from home three days a week, use a desk phone on the other two and take calls on a softphone when travelling. Each of those contexts can have a different registered location, or none at all if the configuration has not kept pace.

That makes emergency location a configuration item in the same family as call routing, permissions and voicemail. It needs an owner, a change process and a periodic check. Without that discipline, the organisation is relying on the hope that the address entered during onboarding is still correct months or years later.

Three addresses, one call

It helps to separate three layers of location data. The first is the site address: the physical building or campus where a group of users normally works. The second is the user address: the location registered against an individual, which may be their home or a hybrid work address. The third is the device address: the location associated with a particular handset, softphone or conference phone, which matters when devices are shared, moved or used by visitors.

A cloud phone system may use one or more of these layers to determine emergency routing. The exact behaviour depends on the provider and the configuration, which is precisely why assumptions are dangerous. A reception phone that is moved to a temporary office may still carry the old site address. A new starter who works mainly from home may be registered to head office because that is where their contract sits. A hot-desk user may inherit the location of the previous occupant.

Finance, HR and IT each see part of the problem. HR holds the contractual and home address data. IT holds the telephony configuration and device inventory. Finance holds the supplier relationship and the assurance that the service is being delivered as agreed. None of them can resolve emergency routing alone.

Where cloud telephony introduces drift

The most common causes of drift are ordinary business events. An office move changes the site address, but the phone system may retain the old one until someone updates it. A hybrid working policy creates a population of remote users whose registered locations need to be captured and maintained. A number porting exercise may bring across numbers with legacy address data attached. A temporary site or pop-up office may be set up with phones but without a corresponding location record.

Softphones and mobile apps add another dimension. A user may make an emergency call from a laptop in a different town from their registered office. Where the provider supports dynamic location, the system may be able to use the device's current location; where it does not, the registered address may be the only information available. The organisation needs to know which mode it is operating in and what that means for its people.

There is also the question of call-back. If an emergency call is dropped or the responder needs to reach the caller, the number presented must be one that can be answered. A direct-dial number that routes to a shared voicemail box is not a reliable call-back route. This is a small detail with significant consequences.

A practical verification programme

A sensible programme does not need to be elaborate, but it does need to be documented and repeated. The following sequence gives finance, HR and IT a shared basis for assurance.

1. Agree ownership and scope. Name a single accountable owner for emergency call routing, with named contributors from HR, IT and finance. Define which users, sites and device types are in scope, including home workers, temporary sites and shared devices.

2. Build a location register. List every site with its full postal address and main call-back number. Then list every user and device that can make an outbound call, with the location that should be registered against them. Reconcile this against HR records and the telephony inventory.

3. Check the configuration against the register. Confirm that the provider's platform holds the correct site, user and device addresses. Look specifically for leavers whose profiles remain active, new starters who have inherited an old profile and devices that have moved without an update.

4. Test the routing without dialling 999. Never place a test call to the emergency services. Ask the provider whether it offers a test facility, a nominated test number or a routing simulation. Where no test facility exists, review call logs and configuration reports to confirm the expected path. Record what was tested, by whom and when.

5. Confirm internal escalation. Check that an emergency call triggers the agreed internal alert, whether that is a reception notification, a manager email or a security desk call. Confirm that the call-back number is answered by a person or a monitored queue.

6. Document the change process. Add emergency location to joiner, mover and leaver checklists. Include it in office move plans and temporary site set-ups. Make clear who updates the provider platform and who checks the update.

7. Review periodically. Set a review cadence that matches the organisation's rate of change. A quarterly check may be enough for a stable estate; a business with frequent moves or a large remote workforce may need monthly checks.

Questions for procurement and finance

Emergency routing should also be addressed in the supplier relationship. When renewing or procuring cloud telephony, ask how location data is captured, updated and reported. Ask what happens when a user moves site or works remotely. Ask whether the provider offers an audit trail of location changes and whether it can produce a report of users without a valid emergency address.

Finance teams should be particularly interested in the assurance model. A provider that treats emergency location as a one-off set-up task is offering a different risk profile from one that exposes location data for regular review. The contract should make clear where responsibility sits for maintaining accurate addresses and what service credits or remedies apply if the service does not perform as described.

The test is the control

The uncomfortable truth is that many organisations will not know whether their emergency call routing works until they need it. That is not a acceptable position for a service that underpins duty of care and business continuity. The 999 test is not a single call. It is a control: a documented, repeatable check that the cloud phone system knows where people are, which number to call back and who inside the organisation needs to know.

For UK businesses, the move to cloud telephony brings flexibility and resilience. It also moves emergency location from the building into the configuration. Treating that configuration as an asset, with an owner and a review cycle, is the difference between a system that is assumed to be ready and one that has been verified.