On this page
A multi site phone system connects users, extensions and call flows across multiple offices, branches or facilities through one coordinated telephony architecture. The key design question is whether staff can dial, transfer and reach colleagues at another site as easily as they can at the same site.
Instead of treating every office as an isolated phone system, a multi-site design creates a shared dial plan while preserving the operational rules each location needs. Depending on the business, this may use one cloud PBX, interconnected local phone systems, or a hybrid architecture.
How does a multi site phone system work?
A multi site phone system links phones and call-processing services across locations so that internal calls can be routed using extensions rather than public telephone numbers. A call between sites typically involves call signalling to establish the connection and voice traffic carrying the conversation across the organisation’s network or hosted platform, as described in Mitel’s Multi-Site Management operating manual (Mitel, 2024). (mitel.com)
In a cloud arrangement, phones at different sites register to the same hosted phone platform. The platform identifies the destination extension, applies the dial plan and connects the call without requiring the caller to dial the other office’s external number.
In a distributed or hybrid arrangement, each site may retain local call-processing equipment while the systems exchange routing information across a private WAN, site-to-site VPN or managed voice connection. This can provide greater local independence, but it introduces more components to design, monitor and maintain.
The architecture should be documented before deployment. At minimum, document each site, extension range, public number, call-processing location, internet connection, local survivability method and emergency-calling configuration.
Can employees dial extensions between different office locations?
Yes. Inter-site dialling allows an employee at one location to call an extension at another location using a short extension, a site prefix or a full internal number, depending on the dial-plan design.
For example, a business could use:
Cisco’s BE4000 Architecture and Design Considerations guide (Cisco, 2019) describes inter-site dialling for businesses with multiple locations, including the use of site-specific dialling patterns. (cisco.com)
The most important factor is consistency. Staff should not need to remember a different procedure for every branch, and the system should make it obvious whether a call is internal, external or being routed through another site.
What is the best extension numbering plan for multiple sites?
The best extension numbering plan is one that identifies the destination site, leaves room for growth and remains simple enough for everyday use. A business with two sites may manage with a shared extension range, while a larger organisation usually benefits from site prefixes or reserved extension blocks.
| Numbering approach | How it works | Strengths | Risks to manage |
|---|---|---|---|
| Shared extension range | Every user has a unique extension across the organisation | Simple directory and user experience | Can become difficult to manage as sites and users grow |
| Site prefix plus extension | Users dial a site code followed by the local extension | Makes the destination clear and supports expansion | Requires staff to learn the site codes |
| Separate extension blocks | Each site receives a reserved range, such as 200–299 or 300–399 | Easy to understand and administer | Moving users between sites may require renumbering |
| User-based extension | A person keeps the same extension while devices or locations change | Works well for mobile and hybrid staff | Shared phones, rooms and temporary workstations need a separate plan |
| Directory-first dialling | Staff search for names, teams or locations | Reduces reliance on memorised numbers | Directory data must be accurate and maintained |
A numbering plan should distinguish between people, departments, queues, meeting rooms and shared devices. Giving every physical handset a personal extension can create confusion when employees move between offices or when several people use the same desk phone.
A practical design may reserve one range for users, another for departments and another for site functions. For example, extensions 2xx could represent users at one site, 3xx another site, and 8xx shared services such as reception, security or after-hours support.
Should every site have its own phone system?
Not necessarily. The choice depends on the required level of centralisation, the reliability of each site’s connectivity and whether locations need to continue operating independently during a network failure.
| Architecture | Where call processing happens | Inter-site dialling | Site outage behaviour | Administration |
|---|---|---|---|---|
| Single cloud phone system | Hosted platform | Shared internal dial plan | Depends on internet, handsets and failover design | Centralised |
| Centralised on-premises PBX | One primary business location | Routed across WAN or VPN | Other sites may depend heavily on the central site | Centralised, with local network work |
| Separate PBX per site | Local system at each site | Requires inter-PBX trunks or federation | One site can remain locally operational | More complex and distributed |
| Hybrid architecture | Combination of hosted and local components | Requires mapped routes between platforms | Can provide selected local survivability | Highest design complexity |
A single cloud platform usually gives the cleanest user experience when the business wants one directory, one dial plan and central administration. Separate systems can make sense where sites have independent operations, unreliable wide-area connectivity or existing equipment that cannot yet be replaced.
The distinction is not simply “cloud versus on-premises”. It is whether the chosen design gives the business a controlled path for extension registration, call routing, failover and administration across all sites.
How should inter-site calls be routed?
Inter-site calls should be routed through the private or hosted voice architecture whenever the destination is an internal user, queue or service. The dial plan should recognise the number as internal and send it to the correct site or platform without sending it out to the public telephone network and back again.
A typical routing sequence is:
Mitel’s multisite documentation identifies signalling and voice as separate traffic requirements that must be exchanged between sites. (mitel.com)
This distinction matters during troubleshooting. A call may fail because the systems cannot exchange signalling, or it may connect with poor audio because the voice media path is blocked, congested or incorrectly prioritised.
The design should also specify whether voice media travels directly between sites or is anchored through a central service. Direct media may reduce unnecessary traffic paths, while centralised media can simplify policy control, recording and security inspection.
What internet and network design does inter-site dialling need?
Inter-site dialling needs dependable connectivity between each location and the phone system, with enough capacity and suitable treatment for real-time voice traffic. Bandwidth alone is not a complete test: latency, jitter, packet loss, congestion and firewall behaviour can all affect call quality.
ITU guidance on packet-network voice quality identifies packet delay, delay variation and packet loss as important influences on perceived speech quality. (itu.int)
A multi-site readiness check should include:
Cisco’s site-management guidance notes that voice allocation and QoS configuration need to be considered separately for each site, rather than assumed to work uniformly across the network. (cisco.com)
Do not size the network only from the number of handsets. Estimate the maximum number of simultaneous calls between and within sites, then account for conferencing, video, backups, cloud applications and other traffic that shares the connection.
How can a business keep calling when one site loses internet access?
A multi site phone system needs an explicit outage plan because a hosted phone platform cannot make a phone at an offline site reachable through that site’s normal connection. The usual controls are local survivability, mobile or alternate-network failover, call diversion and the ability for staff to work from another registered device.
Possible measures include:
These are design options, not automatic features. Each must be tested under realistic conditions, including a failed primary internet connection, a failed power source and a failure of the central phone service.
A resilient design should define what still works during an outage. For example, local extension-to-extension calls may continue, while external calls divert to mobiles; or the entire site may fail over to another office. Document the expected behaviour so staff know what to do rather than discovering the process during an incident.
How should emergency calling be configured across multiple sites in Australia?
Emergency calling must be configured so the service provider and internal administrators can identify the caller’s relevant location, particularly when users can move between offices or use softphones remotely. In Australia, 000 is the primary emergency number, and ACMA states that VoIP callers may be asked to provide the town and state because they may not be calling from their service address. (acma.gov.au)
ACMA’s emergency-details guidance explains that current address information held by the telco can be important when emergency services need to identify where assistance is required. (acma.gov.au)
For a multi-site deployment, confirm:
Emergency calling should be treated as a separate workstream in the deployment plan. It should not be assumed that a shared extension or centralised phone account automatically communicates the caller’s physical location.
Businesses using Microsoft Teams Phone or another integrated calling platform should also review site and network-location controls. Microsoft’s emergency calling policy documentation describes assigning policies to network sites and handling users who work outside the corporate network. (learn.microsoft.com)
What should be tested before launching a multi site phone system?
A multi site phone system should be tested from every location, not just from the head office. The test plan should confirm both normal inter-site dialling and the behaviour of the system when a site, link, phone or user is unavailable.
Use this commissioning checklist:
| Test area | Example test | Expected result |
|---|---|---|
| Internal dialling | Site A calls an extension at Site B | Destination rings using the planned internal number |
| Call transfer | Reception transfers an external caller to another site | Call reaches the correct person or queue |
| Busy and unavailable states | Destination is busy, offline or in Do Not Disturb | The documented fallback rule applies |
| Shared directory | User searches for a colleague at another site | Correct name, extension and site appear |
| Caller identity | Staff call between sites and externally | Caller ID follows the approved policy |
| Voice quality | Several sites make simultaneous calls | Audio remains usable during normal peak traffic |
| Internet failure | Disconnect the primary link at one site | Failover or diversion behaves as documented |
| Power failure | Remove power from local network equipment | UPS or outage process works as intended |
| Emergency calling | Test according to provider and regulatory requirements | Location and notification behaviour are understood |
| New-site expansion | Add a test site or extension | Numbering, permissions and routing scale without redesign |
A failed test should produce a documented action, owner and retest date. “The phones work” is not enough; the important question is whether calls behave correctly across site boundaries and during exceptions.
What questions should you ask a multi site phone system provider?
Ask the provider to show the proposed architecture, not only the handset catalogue or feature list. The design should explain where call processing occurs, how sites are identified, how extensions are assigned and what happens when connectivity fails.
Use these questions during evaluation:
A provider should be able to express the answer as a diagram and a dial-plan example. If the explanation depends on vague terms such as “the locations are connected” without showing routing, media paths and failure behaviour, the architecture is not yet specific enough for approval.
For related planning, use.
What are the most common multi-site phone system mistakes?
The most common mistakes are treating multiple sites as separate installations, assigning extensions without a growth plan and failing to test the network and outage paths between locations.
Other recurring problems include:
The fix is to make the dial plan, network assumptions and failure behaviour explicit before installation. A concise design document is more valuable than a long feature list because it gives the business something to test and maintain.
Frequently asked questions about multi site phone systems
Can phones at different offices call each other for free?
They can usually be handled as internal calls when the sites share the same phone platform or are connected through configured inter-site trunks. Whether there is a separate carrier charge depends on the provider, architecture and contract.
Do all sites need the same phone numbers?
No. A shared platform can support separate public numbers for each site while still giving staff one internal directory and dial plan. The number strategy should be decided separately from the extension strategy.
Can one employee use the same extension at different sites?
Yes, if the system assigns the extension to the user rather than permanently to one physical handset. The deployment still needs rules for shared phones, emergency location, caller ID and simultaneous device registration.
Is a VPN required for inter-site dialling?
Not always. Some hosted systems connect sites through the provider’s platform, while other designs use a private WAN, VPN or direct inter-PBX connection. The required method depends on the phone platform, security model, media path and network design.
Talk to Nexgen about your phone system
Get a like-for-like comparison against a managed cloud phone service.