What does 3CX multi-site configuration actually do?

3CX multi-site configuration is the planning and technical work used to make business calling operate predictably across more than one physical location. It can help branches dial one another, share or coordinate business numbers, apply location-aware call handling, connect remote IP phones to a central 3CX system, or link separate 3CX systems where a distributed design is justified. Businesses should consider it when opening branches, consolidating telephone systems, replacing disconnected PBXs, standardising extension plans or correcting an existing multi-location setup that is difficult to manage. Before work is confirmed, the customer should provide the number of sites, users, current 3CX topology, extension ranges, trunks, DIDs, phone models, internet links, firewall details, office-hour requirements, current problems and available administrator access. Final design and quotation depend on assessment, licensing, connectivity, security requirements, third-party telecom services and the approved change scope.

Choosing the right multi-site 3CX architecture

The first design question is not simply how many branches the organisation has. The more useful question is where call control should live, how each location reaches it and what should happen when one dependency becomes unavailable. A company with several branches and a strong central or cloud-hosted 3CX deployment may prefer remote-site phones to register back to one system through supported 3CX remote connectivity options. This can simplify user administration and create one logical environment, but it also makes branch internet quality, DNS, firewall policy and local survivability important design considerations.

Another organisation may already operate more than one 3CX phone system or may have business reasons to keep call control separated between sites. Current 3CX documentation supports connecting two 3CX systems through Bridges, using a master and slave relationship, an outbound routing prefix or a coordinated numbering plan, and optional presence exchange. Bridge design is not the same as placing every remote user inside one local ring group or queue. It creates a controlled relationship between separate phone systems, so call handling expectations must be checked rather than assumed.

Remote offices that use a central 3CX deployment can also use the 3CX Session Border Controller, often called the SBC, or supported router-phone functionality depending on the site size, phone models and current 3CX guidance. The SBC is a software service placed in the remote network to combine signalling and media traffic toward the 3CX system and to simplify phone connectivity through typical firewall and NAT environments. Whether this is appropriate depends on the number and type of phones, the local network, resilience needs, supported operating platforms and whether the site can host an always-available SBC service.

A third possibility is that the customer is not actually asking for multiple physical sites at all. Some businesses use the phrase multi-site when they mean several departments, brands or companies sharing one PBX. Current 3CX versions include department and multi-company capabilities that can separate administrative scope, office hours, phonebooks and call-handling objects in specific ways. That is a different design problem from connecting branch networks. FourTeck therefore begins by defining the business relationship between locations, companies, departments and users before recommending a topology.

The objective is to choose an arrangement that can be understood and supported after deployment. A technically possible configuration is not automatically the best operational design. Extension numbering should remain intuitive, branch calls should route intentionally, emergency and external calling rules should be reviewed, security boundaries should be clear, and administrators should know which system controls each user, trunk, queue, IVR and office-hour schedule. A short discovery stage can prevent the organisation from building a multi-site design that works initially but becomes confusing as new branches and users are added.

Business situations that commonly trigger a multi-site review

Why unresolved multi-site design problems affect the wider business

A poorly planned multi-location phone environment rarely fails in only one visible way. Users may start working around extension dialling because the numbering plan is confusing. Reception teams may transfer callers through external numbers because branch routes are unreliable. Queues may send calls to the wrong location after office hours. A remote site may depend on an internet circuit that was never assessed for voice. New employees may receive inconsistent extensions because no allocation standard exists. When support is requested, the lack of diagrams and route documentation can lengthen the diagnostic process because administrators first need to reconstruct how calls are supposed to travel.

The commercial impact can include delayed customer response, unnecessary carrier charges, missed internal calls, reduced collaboration, inconsistent call handling and repeated support effort. The goal of a multi-site configuration project is therefore broader than making one test call between branches. It should establish a predictable architecture, controlled routing, suitable network dependencies, clear administration and a repeatable process for adding or changing locations without reintroducing the same uncertainty.

Possible 3CX multi-site configuration scope

Service-fit matrix: which assistance matches the situation?

3CX multi-site service information

How the discovery and assessment process can work

1. Define the business outcome. Establish what the organisation wants to change. Examples include adding a branch, enabling inter-office extension dialling, centralising call control, keeping separate systems connected, standardising numbers or fixing unstable branch calling. This prevents technical work from drifting away from the actual operational objective.
2. Inventory sites and users. Record each location, approximate user count, phone count, local business hours, receptionist or queue workflows, critical numbers and any users who move between sites. Multi-site telephony should reflect how people work rather than only where equipment sits.
3. Map the existing 3CX environment. Identify the current 3CX systems, hosting model, version, license level, administrators, extension ranges, departments, trunks, DIDs, bridges, SBCs, router phones, apps, supported desk phones and relevant integrations. Separate confirmed facts from assumptions inherited from old documentation.
4. Review the number plan. Overlapping extension ranges are common in organisations that have grown site by site. A future plan should consider user convenience, bridge routing, outbound rules, reception workflows and how additional locations may be added without renumbering the entire business again.
5. Trace inbound and outbound calls. Document where each public number terminates, which destinations answer during and after business hours, what queues or IVRs participate, which carrier route handles outbound calls and what identity should be presented. This is especially important when branches have local DIDs or different SIP providers.
6. Assess branch connectivity. Review internet circuits, public addressing, firewalls, DNS, VLANs, switching, PoE, DHCP and any VPN or other WAN design that interacts with voice. The review should focus on measured or observable behaviour where possible, including packet loss, latency variation, instability or firewall events rather than assuming bandwidth alone determines voice quality.
7. Confirm security and access boundaries. Identify who is authorised to make 3CX and firewall changes, how administrators authenticate, what remote management paths exist and whether changes need customer approval. Current 3CX network guidance includes proper firewall configuration and avoidance of problematic SIP ALG behaviour, but actual network policy remains environment specific.
8. Review backups and rollback readiness. Before material changes, confirm that the 3CX configuration can be backed up in a way appropriate to the current deployment and that related network settings are recorded. A rollback plan should explain what can be reversed, who approves reversal and which external carrier changes may not be instantly reversible.
9. Agree the change sequence. Decide whether the work can be staged by branch, by user group or by call-flow component. A pilot location can be useful when many similar branches will follow, but the suitability of a pilot depends on the actual project and cannot be assumed.
10. Define acceptance tests and documentation. Before implementation, agree what successful calling looks like. Tests should reflect real workflows such as branch-to-branch calls, transfers, queue calls, after-hours treatment, outbound caller ID, reception handling and remote-user operation. Documentation should then record the approved final state and any known dependencies.

Planning implementation without turning a branch rollout into a risky one-step change

A multi-site change can affect many users at once, so implementation should be broken into understandable control points. The first control point is configuration ownership. Someone should know which 3CX instance is being changed, which branch devices will be affected and who has authority to approve the work. The second control point is backup and configuration capture. Where appropriate, existing 3CX and network settings should be recorded before adjustments are made. The third is the maintenance window: work that could interrupt registration, routing or trunk connectivity should be coordinated with business operations rather than performed casually during peak calling periods.

If a central 3CX design is being extended to a new site, preparation can include the site subnet, voice VLAN, DHCP options where relevant, DNS resolution, firewall path, phone provisioning method and SBC or router-phone arrangement. Phone models and firmware support should be checked against current 3CX guidance. User records, extensions, roles and call handling can then be created according to the approved numbering plan. The branch should be tested with a small controlled set of users before the full rollout where that approach is practical.

If separate 3CX systems are being linked, Bridge planning must be coordinated at both ends. Current 3CX documentation describes master and slave bridge roles, secure FQDN use, route prefixes or compatible numbering logic, configurable simultaneous-call limits, optional tunnel transport and presence publication or receipt. The service engagement should decide which of these capabilities are actually required instead of enabling every option. Bridge routes must also fit the existing country-code security settings and outbound rules so that remote extension numbers are not misinterpreted.

For migrations, there may be a period when old and new call paths coexist. DIDs might still terminate on an existing trunk while users are gradually moved. Some phones may be reprovisioned while others remain on the old system. Reception staff may need a temporary call-handling procedure. A controlled runbook can show the intended sequence, dependencies, decision points and rollback triggers. This is especially useful when carrier-side changes or DNS updates have timing outside the direct control of the 3CX administrator.

After configuration, validation should go beyond checking that the admin console shows green status indicators. Test real inbound and outbound calls from representative branches. Transfer calls between locations. Confirm queue or ring-group behaviour where those objects are in scope. Verify audio in both directions. Check caller identity. Test office-hour outcomes. Confirm phone registration after a restart where safe. Review whether remote users can access the expected presence or directory information. The exact test list should come from the business workflow and the confirmed design.

Finally, handover should leave the organisation with enough information to operate the environment. Useful records include site names, subnet and voice VLAN notes, extension ranges, bridge prefixes, SBC locations, trunk ownership, DID routing, critical queue or IVR destinations, vendor contacts, backup method, change date and known limitations. Passwords should not be embedded casually in shared documents. Credentials should remain in an approved secure management process. Good handover reduces the chance that the next branch change starts again from incomplete memory.

Dependencies and customer inputs that should be confirmed

The exact 3CX configuration scope depends on information and access that may sit with different teams. The business owner may define how branches should answer customer calls, while internal IT controls the network and firewall, a telecom provider controls the SIP trunk and DIDs, a hosting provider controls the server platform, and a building contractor manages branch cabling. Multi-site work becomes more predictable when these responsibilities are identified before the change window.

• Business objective, branch list, site contacts and the expected user experience between locations.
• Current 3CX system details, hosting method, version, license information and authorised administrator access.
• Extension ranges, service extensions, DIDs, SIP trunks, queues, ring groups, IVRs and office-hour requirements.
• Phone models, user counts, mobile or desktop-app usage and any SBC or router-phone devices already deployed.
• Branch network diagrams where available, including subnets, VLANs, switches, PoE, firewalls, DNS, DHCP and internet links.
• Recent changes, fault timestamps, sample call details and screenshots or logs where troubleshooting is part of the scope.
• Carrier and ISP contacts, account references where appropriate and any pending number-porting or trunk changes.
• Backup status, maintenance-window restrictions, user communication needs and a person authorised to approve significant changes.
• Security approval for remote access. Credentials should be supplied only through a secure authorised method, not placed in public forms or shared documentation.

Risks, limitations and exclusions to understand before configuration

Multi-site telephony depends on more than the 3CX application. A correct PBX setting cannot compensate for a failing ISP circuit, damaged cabling, an unsupported phone, an expired third-party service or a firewall policy that blocks required traffic. Some findings therefore need action from the customer’s carrier, ISP, hosting provider, equipment vendor or internal network team. FourTeck can help isolate and document the affected layer, but third-party completion times and commercial terms remain outside the configuration scope unless specifically included.

Configuration changes can also affect active users. Reprovisioning phones, altering routes, changing office hours, modifying trunks or moving users between systems may interrupt calls if performed without coordination. Appropriate backups, a maintenance window and rollback planning should be used where the risk justifies them. A successful test immediately after a change does not guarantee that every possible carrier route, user behaviour or future network condition has been covered, so ongoing observation may be required after a material rollout.

Legacy systems create additional uncertainty. Older 3CX versions, unsupported operating systems, outdated phone firmware, discontinued devices or undocumented integrations may limit the available options. The safest approach may be upgrade or replacement planning rather than forcing new functionality into an unsupported environment. License-dependent features should also be confirmed against the customer’s current 3CX entitlement and current vendor documentation before they are included in the final design.

The quotation should identify what is included: platform configuration, network changes, on-site work, phone installation, carrier coordination, user migration, documentation, testing and any post-change support. Hardware replacement, new licenses, new internet circuits, third-party professional services and carrier fees should not be assumed to be part of the configuration labour unless they are explicitly listed.

Business environments where multi-site 3CX planning can be useful

Operational, security and maintenance considerations after rollout

Multi-site 3CX configuration is not a one-time collection of settings that never needs review. Branches gain and lose users, telecom carriers change, internet circuits are upgraded, firewalls are replaced and phones reach the end of support. A maintainable environment should therefore have a process for routine change. New users should receive extensions from the approved range. New branch phones should follow the same provisioning pattern. Changes to queues or office hours should be documented so users understand the operational effect.

Security requires equal attention. Administrative roles should be limited to appropriate people, remote management paths should be controlled and branch networks should follow suitable firewall policy. 3CX security and anti-hacking features should be reviewed in context rather than bypassed to make a difficult route work. If IP allow-listing or other exceptions are considered, the business should understand why they are required and what exposure they create. Broad security weakening is not an acceptable substitute for correct network design.

Backups should be included in the operating process and tested according to the business’s recovery expectations. Documentation should identify where the active configuration is hosted and how recovery would be coordinated if that platform becomes unavailable. Multi-site resilience may also require a discussion of branch internet diversity, local calling requirements, carrier architecture and what users should do during an outage. The answer varies by business and should not be replaced with a generic promise of continuous service.

Periodic review can also identify configuration drift. An extension prefix that once represented one branch may later be reused incorrectly. Old bridges may remain enabled after a consolidation. DIDs may route to destinations no longer in service. An SBC host may be aging or undocumented. A maintenance review gives administrators an opportunity to reconcile the live environment with the intended design and update records before the next urgent incident.

Before you contact FourTeck for 3CX multi-site work

You do not need a perfect network diagram before requesting an assessment, but the following information helps define the first step and reduces time spent reconstructing basic facts.

• List each office, branch or operational location that needs to participate.
• Estimate the number of 3CX users and desk phones at each site.
• Describe the main goal: new deployment, connection between systems, consolidation, troubleshooting or standardisation.
• Provide current extension ranges and note any overlapping numbers between branches.
• Identify public DIDs and SIP trunks that have location-specific routing requirements.
• Note whether each site uses one central 3CX system or separate 3CX instances today.
• Record any existing Bridge, SBC or router-phone arrangement that you know about.
• List representative IP phone brands and models, especially at remote sites.
• Describe internet and network issues that may affect voice, including intermittent outages or one-way audio.
• Share the approximate time and frequency of faults, with example calls if troubleshooting is required.
• Confirm whether authorised 3CX and network administrator access can be made available.
• State any office-hour, queue, reception or after-hours behaviours that differ between branches.
• Confirm whether recent 3CX, firewall, ISP, trunk or network changes have been made.
• Identify the preferred maintenance window and any periods when phone changes must not occur.
• Confirm who can approve configuration and who will be available to test at each location.
• Describe the expected result in business terms, including what users should be able to do after the project.

Service evaluation checklist for quotation planning

A quotation is clearer when the engagement boundaries are agreed before work begins. The following points can be confirmed during discovery rather than assumed to be included automatically.

• Exact number of sites and target users.
• Centralised, bridged or other approved target architecture.
• 3CX licensing or upgrade requirements.
• Phone provisioning and physical installation scope.
• Bridge, SBC or router-phone configuration scope.
• SIP trunk, DID and carrier coordination responsibilities.
• Firewall, VLAN, switch or network changes included.
• Remote versus on-site activities for each location.
• User migration and extension renumbering requirements.
• Queue, IVR, ring-group and office-hour changes.
• Test cases and user acceptance responsibilities.
• Documentation and administrator handover requirements.
• Post-change observation or support period, if required.
• Known exclusions such as hardware supply, carrier fees or third-party engineering.

How FourTeck can assist with a controlled 3CX multi-site project

FourTeck can begin by clarifying whether the requirement is a new multi-site design, a branch addition, a bridge between existing systems, a remote-phone connectivity problem, a consolidation project or an administrative standardisation exercise. That distinction matters because each path has different dependencies. The assessment can then connect 3CX configuration with the branch network, firewall, carrier and user workflow instead of treating the phone system as an isolated application.

For an existing environment, assistance may include reviewing the live topology, identifying number conflicts, documenting routes, checking Bridge or SBC status, tracing sample call problems and highlighting configuration that no longer matches current business operations. For a planned deployment, the work can focus on target design, prerequisites, user and number migration, change sequencing, site readiness, test cases and handover. If another vendor controls the SIP trunk, firewall or hosting platform, FourTeck can help prepare the technical information needed for coordinated action.

Where on-site work is required, it can be scoped around branch readiness, phone installation, cabling checks, switching, PoE, VLAN verification, local testing and physical coordination. Remote work may cover platform administration, route changes, backup review, configuration validation and documentation. The combination depends on the site and approved quotation rather than a fixed package.

For information about the wider company service approach, visit FourTeck IT Services in the UAE. To review other business technology support areas, see the FourTeck IT support website. The final multi-site scope should be confirmed only after the environment, required access, licensing and third-party dependencies are understood.

Dubai and UAE service coordination

For Dubai businesses, multi-site 3CX work can often begin with remote discovery because the first questions concern topology, user counts, numbering, call flow and existing configuration. An on-site visit may then be recommended for a branch where phone installation, cabling, switching, PoE, local firewall access or voice-quality testing must be handled physically. The project plan should distinguish platform work from site work so each location receives only the support it actually needs.

Remote or on-site assistance depends on the issue, access, location, urgency and approved quotation. Service timing depends on engineer availability, customer access, building rules, required parts, maintenance windows, telecom-provider action and the confirmed work scope. A branch launch that also requires a new internet circuit, carrier number activation or building cabling cannot be scheduled accurately from the 3CX configuration alone.

Contact FourTeck to confirm the required service scope and scheduling options before setting an internal go-live date. This makes it easier to identify prerequisites that need completion by the customer, carrier, landlord, ISP or another vendor before the telephony work can be tested successfully.

Coordinating branches in Dubai, Abu Dhabi, Sharjah and Ajman

A UAE multi-location organisation may have its main office in Dubai and additional sites in Abu Dhabi, Sharjah or Ajman. The same 3CX design principles can be applied across those locations, but the service plan should still reflect each site’s network, phones, ISP, building access, local working hours and business function. One branch may need only remote provisioning, while another requires an on-site inspection because it has undocumented switching, poor voice quality or a new equipment rack.

FourTeck can coordinate remote troubleshooting, planned on-site visits, branch assessments, configuration, migration and project support according to the confirmed scope. Travel, site access, scheduling, equipment availability and third-party dependencies can affect the sequence. The presence of several emirates does not require repeating the entire phone system at each location; it requires a design that makes location-specific dependencies visible and controllable.

For a phased rollout, the business may choose to validate one representative branch first, capture what was learned and then use the approved pattern for later sites. Whether that approach is suitable depends on how similar the branches are and whether local carrier or network differences are significant. The project should remain flexible enough to adapt without losing the overall numbering, security and support standard.

Related FourTeck service areas

Why businesses contact FourTeck for multi-site telephony assistance

The value of external assistance is often the ability to look across several connected layers at once. A branch call problem may involve a phone, switch, firewall, internet path, SBC, 3CX route or SIP provider. Treating each layer separately can lead to repeated changes without clear evidence. FourTeck can organise the assessment around the business symptom, then narrow the investigation to the components that actually participate in the call path.

For planned projects, the same joined-up view helps expose dependencies before the change window. A number-porting request can affect inbound routing. A new voice VLAN can affect phone provisioning. A firewall replacement can affect remote registration. An extension-renumbering exercise can affect bridges and user instructions. Documenting these relationships improves decision-making and makes it easier to assign responsibilities to internal IT, FourTeck and third parties.

The engagement can also provide a clearer quotation boundary. Instead of describing the requirement simply as “configure multi-site 3CX,” the scope can identify sites, users, routes, phones, network work, testing, documentation and vendor dependencies. That clarity reduces assumptions and gives the customer a practical basis for approving the project.

Questions businesses ask before choosing a 3CX multi-site design

The following decision guidance addresses the questions that usually appear before a business is ready to request configuration work. Each answer is intentionally conditional because the correct technical choice depends on the current 3CX environment, network, phones, licensing and business workflow.

Should every branch use one central 3CX system?

A central system can simplify administration because users, call handling and many settings live in one environment, but it is not automatically the right design for every organisation. Branch phones still need dependable connectivity to that system, and local network conditions become part of the voice path. A central approach is often worth evaluating when the business wants common administration and consistent user experience. Separate systems may remain appropriate where business units, resilience requirements, existing investments or operational boundaries justify them. FourTeck can compare the current topology with the desired operating model before recommending consolidation.

When would 3CX Bridges be relevant?

Bridges are relevant when two separate 3CX phone systems need a supported connection for inter-system calling. Current 3CX documentation uses master and slave bridge roles and allows route prefixes, tunnel options and presence exchange. The practical design still requires non-conflicting extension logic, secure FQDN reachability, appropriate firewall paths and a clear understanding of what remains local to each PBX. A Bridge should not be treated as though all users from both systems become one shared local configuration. Call-flow expectations need to be tested against what Bridge functionality actually provides.

Do remote branches need a 3CX SBC?

An SBC can be useful when supported IP phones at a remote location connect back to a central 3CX system. 3CX also supports router-phone approaches in suitable environments. The best option depends on the number of phones, supported models, branch topology, always-on device availability and current 3CX guidance. An SBC can simplify signalling and media traversal, but it is not a cure for unreliable internet, failing switches or poor power. The branch network should still be assessed as part of the phone deployment.

Can multi-site problems be checked remotely?

Many configuration problems can be investigated remotely when secure access is available. Administrators can review routes, user settings, bridges, trunks, SBC status and other relevant configuration, and they can coordinate controlled test calls with users at each site. Remote work is less suitable when the suspected fault is physical, such as bad cabling, unstable PoE, an inaccessible firewall, local switching loops or a phone that loses power. The first assessment should decide which evidence can be gathered remotely and whether a site visit is justified.

What causes one-way audio between branches?

One-way audio can have several causes, so it should not be diagnosed from the symptom alone. NAT, firewall rules, asymmetric routing, SBC or tunnel behaviour, endpoint configuration, VPN design or carrier paths can all influence media flow. The useful starting point is to record a reproducible example: source extension, destination, site, direction, date and time. Engineers can then trace the expected call path and compare signalling and media behaviour with the network design. Randomly opening firewall ports without understanding the path can create security risk and may not solve the real problem.

How should extension numbers be planned across several offices?

The numbering plan should make destinations unambiguous and leave room for growth. Businesses often choose location-based ranges, but the exact structure depends on user count, existing numbers, bridge prefixes, service extensions and integrations. Renumbering hundreds of existing users just to achieve a neat pattern may create more disruption than value. A useful plan balances user familiarity, routing simplicity and future expansion. Before changes are made, identify where current extension numbers appear in printed material, CRM integrations, forwarding rules, queues and operational procedures.

Can every branch keep its own public telephone numbers?

Often the business can retain location-specific DIDs while changing the internal architecture, but the details depend on the SIP provider, trunk configuration, number ownership and target 3CX design. Some numbers may terminate on one central trunk and route internally to branches; others may remain associated with a location-specific carrier service. Number porting or carrier changes can introduce lead times and dependencies outside the PBX configuration. The project plan should therefore map every important DID to its current and target destination before users are moved.

What should be tested before a new branch goes live?

Testing should represent real branch workflows, not only one outbound call. Useful checks can include phone registration, internal calls to the head office, inbound DID routing, outbound calling, transfer between sites, queue or ring-group behaviour, IVR paths, office-hour treatment, caller identity, voicemail where relevant, directory or presence behaviour, and audio quality in both directions. If the branch depends on an SBC or router phone, its status and restart behaviour should be understood. The final test list should be agreed before the maintenance window so success is measurable.

How do office hours work when branches operate different schedules?

Current 3CX versions provide department and destination-based mechanisms for office-hour handling, but the correct design depends on how the customer’s users, trunks, queues and departments are organised. A branch may need local opening hours while a central reception or queue follows a different schedule. The configuration should be built from the desired call outcome: where should a customer call go at 7:00 p.m. in Dubai if one branch is closed but another team remains available? Answer that business question first, then map the relevant 3CX objects.

Is multi-company mode the same as multi-site configuration?

No. Multi-company mode addresses separation of companies or tenant-like administrative units within a supported 3CX deployment, while multi-site configuration addresses how users and calling operate across locations. A multi-site business may use departments without using multi-company mode. A group of separate companies may share infrastructure but require isolated administration. Because these concepts can overlap in everyday language, FourTeck should confirm whether the requirement is location connectivity, organisational separation or both before the design is approved.

Can we keep different SIP providers at different branches?

Potentially, but the arrangement must be evaluated against the target architecture and each provider’s supported 3CX configuration. Different carriers can create useful local number or resilience options, but they also add routing and support complexity. The business should document which provider owns which DIDs, how outbound calls should be selected, what caller ID should appear and who is responsible for fault escalation. Carrier changes should not be hidden inside a generic “multi-site” task because they may involve separate commercial and technical processes.

What information is most useful when requesting a quotation?

Start with the number of sites, approximate users and phones, current 3CX arrangement, main business goal and whether the work is new deployment, migration or troubleshooting. Add extension ranges, trunks, DIDs, phone models, branch internet details, existing SBC or Bridge use, and any known call-flow requirements. For a fault, include examples with times and affected endpoints. For a project, include the desired go-live window and any carrier, building or network work already scheduled. This gives FourTeck enough context to identify what must be assessed before a reliable quotation can be prepared.

What can affect the final multi-site service scope?

The final scope can change based on the number of 3CX systems, license level, current version, phone support, branch network condition, firewall ownership, SIP-provider requirements, number porting, user migration, office hours, integrations, recording needs, physical installation and documentation expectations. A project that appears to be “connect two offices” may expand if the branches use overlapping numbers or unsupported devices. Conversely, a well-documented central system may need only limited branch provisioning. Assessment prevents both under-scoping and unnecessary work.

Should the business choose one-time configuration or ongoing maintenance?

A one-time project can be appropriate when the environment is stable and the customer has internal administrators who will own future changes. Ongoing support may be more useful when branches are frequently added, user turnover is high, telecom vendors need regular coordination or the internal team prefers external assistance for upgrades and incidents. The choice should reflect operational responsibility, not a generic package. If recurring support is required, the agreement should state covered users, systems, locations, support channels, exclusions and how project work is handled.

Frequently asked questions about 3CX multi-site configuration

Request a 3CX multi-site assessment

If your business is adding branches, linking existing 3CX systems, moving remote phones to a central deployment or trying to correct inconsistent inter-site calling, begin with the current topology and desired business outcome. FourTeck can review the available information, identify the main technical dependencies and help define whether the next step should be remote assessment, on-site inspection, configuration work, migration planning or vendor coordination.

Provide the number of locations, users, extension ranges, main DIDs, phone models, internet links, current 3CX arrangement and any known symptoms. Do not send passwords through public contact fields. Once authorisation and a secure access method are confirmed, the environment can be reviewed in more detail. The final service scope, schedule and commercial terms depend on the approved quotation and the access, licensing, network and third-party requirements identified during assessment.

Request a Service Quotation

A practical next step for a multi-site 3CX project

The most useful first action is to describe the environment as it exists today rather than the configuration you think may be required. If you have two separate PBXs, say so. If all branches already use one 3CX server but remote phones are unstable, identify the affected sites and connection method. If you are opening new offices, provide the target user count and expected call flows. That gives the assessment a clear starting point and helps avoid recommending Bridge, SBC, department or routing changes that solve the wrong problem.

FourTeck can then help convert the business requirement into a controlled technical scope covering topology, numbering, connectivity, call handling, testing, documentation and responsibilities. The aim is not to make the environment more complex; it is to make multi-location calling easier to understand, support and extend. For service enquiries, use the FourTeck contact page and include the branch count, current 3CX arrangement and the result you want users to achieve.