Overview
An answering destination is useful only if the caller can reach it. Before relying on after-hours coverage during a Zoom Phone outage, have the phone administrator explain the failure path for the specific public number. A normal forwarding test does not establish what will happen when connectivity is lost.
Identify which forwarding feature is being proposed
Zoom’s Local Survivability forwarding documentation describes a configured on-site deployment with associated carrier numbers and network equipment. It is not a setting that forwards to any arbitrary answering-service number. The document also excludes the main company number from this particular forwarding configuration. Ask the administrator to identify the supported route for the number your customers actually dial.
Record the public number, its normal destination, its outage destination, and the person authorized to activate or change that route. Keep ordinary after-hours scheduling separate from outage handling in this record.
Check the activation path and shared dependencies
The Zoom forwarding instructions describe administrator activation through the web portal during an outage. They also warn that the local internet connection and public telephone network service must not depend on the same local-loop infrastructure. Ask how the administrator will reach the controls and what remains available if the office connection fails.
Treat activation as an assigned task until your administrator has demonstrated the behavior of your configuration. A saved destination is not evidence that the outage route has been enabled. Do not infer a universal automatic recovery process from the name of the feature.
Test an interrupted call separately from a new call
Zoom’s getting-started guide states that active calls are not preserved when cloud access is lost: the user must wait for failover and manually re-establish the call. It also distinguishes the reduced survivability feature set from normal cloud operation. A successful new call after failover does not show that a conversation already underway would continue.
Agree on who should attempt a callback after a disconnected conversation and where any unfinished message belongs. Test that handoff with a planned, non-customer scenario so staff do not mistake a dropped call for a completed request.
Record an acceptance result for the complete path
Use an administrator-approved test window and a non-production configuration where possible. Do not disconnect a working business line just to demonstrate the checklist. These are proposed checks, not results from an AnSer or customer deployment.
- Confirm the tested number and failure condition; distinguish office connectivity loss from a wider provider outage.
- Place a new inbound test call and verify the intended recipient can answer and deliver the message.
- Check an interrupted conversation separately and record the agreed callback owner.
- Verify what happens if the fallback destination does not answer.
- Restore normal routing and confirm the temporary route is no longer intercepting calls.
