# Best 3CX Setup for Multi-Location Offices *Published:* 2026-08-05 *Author:* Ted Multi-location offices usually get the best 3CX results from a simple rule: keep the dial plan centralized unless a branch truly needs its own PBX. That choice shapes every later decision, including SBC placement, DID routing, office hours, and failover. > ### TL;DR: Summary > > - The best 3CX multi-location setup for most small to mid-size businesses is one central 3CX system with an [SBC at each branch](https://wearevoip.us/3cx-sbc-setup-service-remote-office-home-worker-connectivity-that-actually-works/), because it keeps extensions, reporting, and management in one place. > - Use separate 3CX systems with a bridge only when a site needs real autonomy, local admin control, or its own survivability and trunk strategy. > - 3CX bridges require secure FQDNs on both sides, not IP addresses, and can use either prefix dialing or separate extension ranges like 100-series and 200-series numbering. > - If a branch has more than 10 phones, 3CX recommends a dedicated SBC; if it has fewer than 10 phones, 3CX recommends an SBC-capable router phone. > - In [3CX v20](https://wearevoip.us/3cx-v20-features-smbs-will-actually-use/), office hours are driven by the department of the endpoint or extension where the call arrives, not by the SIP trunk, so DID mapping and arrival points matter more than many teams expect. > - Before cutover, validate trunks, codec order, outbound rules, DID mapping, Firewall Checker results, and failover behavior, or multi-site audio and routing issues will surface after go-live. The right design depends on phone count, branch independence, [local emergency calling](https://wearevoip.us/e911-for-3cx-service-configuration-testing-and-multi-location-compliance-for-us-businesses/), local emergency calling, and whether the business wants one support model or several. In current 3CX versions, [call routing](https://wearevoip.us/3cx-call-flow-design-service/) also depends heavily on department office hours and the exact destination of each DID, so older PBX habits can create avoidable mistakes. What is the best 3CX setup for multi-location offices? ------------------------------------------------------ For most SMBs, one central 3CX instance with an SBC at each branch is the cleanest design. 3CX and the SBC model simplify management, reduce firewall issues, and keep extensions and reports in one system. A central design works well when offices share the same company identity, common reporting, and a single admin team. It also makes mobile apps, hot desking, shared queues, and company-wide directory search easier to manage because users stay inside one PBX instead of several separate systems. > “We are VoIP offers a $49 3CX [system checkup](https://wearevoip.us/we-are-voip-3cx-consulting-service/) for businesses that want a fast review before changing SBCs, trunks, or office-hour routing.” That said, “best” does not always mean “one PBX.” If a branch must keep local trunks, keep operating during WAN loss, or hand control to a local IT team, separate 3CX systems connected by a bridge can be the better fit. Should a business use one central 3CX system or separate PBXs with bridges? --------------------------------------------------------------------------- A central 3CX system is better for simplicity, while bridged 3CX systems are better for branch autonomy. 3CX supports both models, but the trade-off is control versus complexity. With one central PBX, all users live in one dial plan. Inbound rules, recording policies, presence, reporting, and license management are easier to govern. This is usually the lower-friction choice for businesses with five or more employees per office that do not want each site acting like a separate phone company. Bridged PBXs make more sense when each office behaves like a semi-independent business unit. A 3CX bridge connects two remote 3CX systems so branch offices can call each other free over the internet. A common mistake is assuming a bridge is just a backup path. It is really an architectural choice that adds another layer of routing, numbering, and support. 3CX also sets one hard rule here: both bridge endpoints must use secure fully qualified domain names. An IP address cannot be used for the master or slave bridge. If that requirement is skipped, setup usually stalls early. What are the best 3CX multi-location setup patterns? ---------------------------------------------------- The strongest patterns are predictable, supportable, and matched to site size. 3CX and official SBC guidance point to a small set of layouts that cover most real deployments. 1. **Central 3CX with dedicated SBCs:** Best for most multi-office SMBs, especially when a branch has more than 10 phones and wants one dial plan and one admin model. 2. **Central 3CX with an SBC-capable router phone:** Best for micro-branches with fewer than 10 phones that still need cleaner remote connectivity. 3. **Separate 3CX PBXs with a bridge:** Best when offices need independent trunks, local survivability, or separate administration but still want inter-office dialing. 4. **Hybrid design:** Best when headquarters can be centralized but one regulated, remote, or high-risk location needs its own local PBX and trunking. The practical decision point is this: if a branch is operationally dependent on headquarters, centralize it. If a branch must function like its own site during internet or policy failures, give it more local control. How should extension numbering and inter-office dialing be planned? ------------------------------------------------------------------- A good numbering plan starts before phones are provisioned. 3CX bridges and central dial plans both work better when extension ranges and prefixes are fixed early. Step 1 is to reserve extension ranges by site or department. A simple pattern like 100 to 199 for headquarters and 200 to 299 for Branch 1 gives room for growth. Many teams regret using ad hoc numbers because, [queues](https://wearevoip.us/3cx-queue-vs-ring-group-what-to-use/), ring groups, and future departments start colliding. Step 2 is to decide how inter-office dialing should feel to users. In bridged systems, 3CX supports a prefix plus extension number or separate numbering plans across offices. If users will call another site often, separate extension ranges usually feel cleaner than asking staff to remember a bridge prefix every time. > “We are VoIP supports [3CX licenses](https://wearevoip.us/3cx-reseller-for-smbs/), hosting services, and one-time system reviews for small to mid-size multi-location teams.” Step 3 is to reserve system numbers for IVRs, queues, paging, and test destinations. A common misconception is that numbering only matters for people. In multi-location 3CX, arrival points and system extensions shape routing just as much as user extensions do. When is a 3CX SBC better than direct remote phone provisioning? --------------------------------------------------------------- For branches, a 3CX SBC is usually better than direct remote provisioning. 3CX recommends a dedicated SBC for larger networks with more than 10 phones. The reason is not just convenience. The 3CX SBC combines SIP signaling and RTP media packets from one location and sends them to 3CX as a single managed connection. That reduces firewall and NAT problems, which are among the most common causes of [one-way audio](https://wearevoip.us/fix-one-way-audio-in-3cx-calls/), [dropped registrations](https://wearevoip.us/3cx-not-registering-fix-common-issues/), and poor call quality. If a site has fewer than 10 phones, 3CX recommends an SBC-capable router phone instead of a dedicated SBC. That can lower hardware sprawl for tiny offices. The trade-off is scale and resilience. A branch with eight phones today may look fine on a light setup, but if it will soon grow to 15 or 20 phones, rebuilding later is often more disruptive than installing the right SBC path up front. Direct remote phone provisioning still has a place for isolated users or very small temporary locations. It is usually weaker as a branch standard because each endpoint creates its own exposure to network quirks. How do department office hours affect multi-location routing in 3CX v20? ------------------------------------------------------------------------ In 3CX v20, department office hours control routing behavior more than trunk settings do. 3CX applies office hours based on where the call arrives, not the trunk it came from. This catches many teams during a redesign. If a DID sends a call to an IVR in the Dallas department, Dallas office hours apply. If that same DID is remapped to an extension in the Chicago department, Chicago office hours apply instead. The trunk is not the deciding factor. Department office hours are inherited by extensions and system extensions, including IVRs, that belong to that department. That makes department design part of routing design. A common mistake is moving DIDs between destinations without checking which department owns those destinations. This also means multi-location businesses can finally model real branch schedules more cleanly. A west coast support queue and an east coast sales queue can share the same central PBX while still behaving differently after hours. How should inbound DIDs and outbound rules be built for multiple offices? ------------------------------------------------------------------------- Multi-location routing works best when DIDs, caller IDs, and office-level rules are documented first. 3CX and standard SIP trunk practice reward very explicit mapping. Step 1 is to inventory every DID by site and purpose. Some numbers are public main lines, some belong to executives, some should hit local queues, and some exist only for fax or legacy workflows. This is where many projects go off track, because the carrier record and the PBX record do not always match. Step 2 is to build a default inbound route, then add individual DID routes for the numbers that need special treatment. That pattern is safer than trying to make every number follow one catch-all behavior. It is also the structure recommended in practical 3CX trunk guidance because it keeps IVRs, ring groups, and queues predictable. Step 3 is to build outbound rules around office identity, not just dialing permissions. A five-person office and a multi-location company often need different caller IDs, emergency routing, and international policies. A strong 3CX trunk setup also checks Auth ID, password, registrar, transport, codec order, DID mapping, and failover behavior before go-live. If local presence matters, then outbound caller ID should match the branch number customers know. If emergency service rules vary by office, then emergency routes should be tested per site, not assumed. How can an on-premise 3CX system be moved to the cloud without disrupting branches? ----------------------------------------------------------------------------------- The safest multi-location migration is a [parallel build](https://wearevoip.us/we-are-voip-3cx-implementation-service/), not a same-day rebuild. 3CX cloud hosting and branch SBCs make that approach practical. Step 1 is to build the new cloud-hosted 3CX instance in parallel while the on-premise system stays live. This removes pressure from the cutover window and allows time to configure departments, DIDs, office hours, apps, bridges, and branch connectivity. Step 2 is to connect test devices, trunks, or temporary routes and validate real call flows. Check inbound routes, outbound caller ID, bridge dialing, queue behavior, and branch audio from each office. This is where hidden NAT or codec issues usually appear. > “We are VoIP recommends a parallel 3CX migration so branches can be validated before inbound and outbound call paths are switched.” Step 3 is to switch inbound and outbound call paths at a planned time. Cloud-hosted 3CX can reduce hardware maintenance and help hybrid work because the PBX is no longer tied to one office network. The trade-off is that branch internet quality becomes even more important, so weak circuits need attention before the move. What network and firewall checks matter before cutover? ------------------------------------------------------- Firewall and network validation are mandatory for multi-location 3CX. The 3CX Firewall Checker and router guidance should be treated as pre-cutover requirements, not optional cleanup. The Firewall Checker helps confirm whether the network is VoIP-friendly, and 3CX documents the ports needed for remote apps and SBC connections. That matters because multi-site voice failures often come from routers rewriting SIP traffic, blocking RTP ranges, or handling NAT poorly. Basic voice standards still apply. Packet loss should be close to 0%, one-way latency is best kept below about 150 ms, and jitter is preferably under 30 ms. A common misconception is that if web browsing works, voice will work. SIP and RTP are much less forgiving than email or file downloads. Codec choices and failover paths also deserve a live test. If a trunk can fail over to another route but no one has tested the behavior, it is not real resilience yet. Which multi-location 3CX mistakes cause the most call problems? --------------------------------------------------------------- Most 3CX multi-location issues come from routing assumptions, not from the phones themselves. 3CX, SBC, and bridge deployments fail most often when teams skip validation or copy a single-site setup into several offices. After the design is drafted, a short review against common errors can prevent days of cleanup later. - **Bridge setup:** Using an IP address instead of secure FQDNs for the master bridge or slave bridge. - **Office hours logic:** Assuming SIP trunk hours control the call when 3CX v20 actually uses the department of the arrival point. - **DID mapping:** Sending all numbers to one default target and forgetting individual routes for queues, IVRs, or branch-specific lines. - **Branch connectivity:** Treating a 15-phone site like a few remote users instead of giving it a dedicated SBC. - **Cutover prep:** Skipping Firewall Checker results, codec review, and failover testing before [porting](https://wearevoip.us/we-are-voip-3cx-number-porting-service/) or rerouting calls. One more frequent issue is emergency dialing. Teams often build beautiful call flows and then realize later that the wrong branch caller ID appears on an emergency call path. How should local presence, emergency calling, and failover be handled at each office? ------------------------------------------------------------------------------------- Each office should have explicit local calling rules, emergency behavior, and fallback options. 3CX can support centralized administration, but site-specific compliance still needs site-specific planning. Local presence usually means branch DIDs for inbound calls and branch caller IDs for outbound calls. That helps customers see a familiar number and keeps return calls landing in the right office. If a business wants one national identity instead, then central caller ID may be fine, but it should be a conscious choice. Emergency calling is less flexible. If laws, carrier requirements, or internal policy require a branch to present a local number and address on emergency calls, then outbound rules must enforce that by location. If that cannot be guaranteed through a centralized trunk model, a local trunk or a separate branch PBX may be the safer option. Failover should follow business impact. If a lost WAN link would simply inconvenience one small sales office, centralization is usually still worth it. If a lost link would stop a warehouse, clinic, or customer service floor from functioning, then that site may need its own trunk, its own SBC strategy, or even its own 3CX system bridged back to headquarters.