The Ultimate 3CX Setup Checklist for New Deployments

A new 3CX deployment can feel deceptively simple: install the software, add a SIP trunk, provision phones, and start calling. The teams that end up happiest with their system usually treat it more like a production service rollout than a quick app install. A checklist keeps the project steady, reduces rework, and helps avoid the classic “everything works except inbound calls” moment on go live day.

What this checklist is built to prevent

Most early 3CX issues trace back to a few repeat offenders: DNS that is correct externally but wrong internally, firewall rules that look right but fail under NAT, SIP ALG quietly rewriting packets, or a server that is doing too many jobs. A setup checklist keeps those risks visible when changes are still cheap.

It also creates a shared reference between operations, IT, and any outside provider, so call flows and responsibilities are not living only in someone’s inbox.

Phase 0: Decisions to lock down before touching the installer

Before the PBX host is built, the project needs clear answers on hosting, identity, and call capacity. These choices affect DNS, certificates, firewall policy, phone provisioning, and user experience.

A practical pre-install snapshot should cover:

• Expected extension count and peak concurrent calls
  
• On prem vs cloud hosting, and who owns patching and backups
  
• SIP trunk provider selection and DID inventory
  
• The system name (FQDN) that phones and apps will use everywhere

After the basics are agreed, many teams find it helpful to write down a “definition of done” for go live: what call paths must work, what reports must be available, and what “good call quality” means in measurable terms.

Host and OS readiness (the stuff that saves hours later)

A stable host beats a powerful host that is misconfigured. 3CX performs best when it is not competing with unrelated server roles or security tools that interfere with real-time traffic and file access.

A typical readiness pass includes:

• Dedicated VM or physical host that matches 3CX sizing guidance
  
• Static LAN IP and consistent gateway configuration (especially on multi-NIC systems)
  
• SSD storage with headroom for voicemail and recordings
  
• Power plan set to High Performance on Windows hosts
  
• Antivirus exclusions for 3CX folders where required by vendor guidance

This is also the right time to confirm that the PBX will not be a DNS server, DHCP server, or general-purpose application box. Keeping the role focused tends to reduce both performance surprises and troubleshooting complexity.

Network planning: VLAN, QoS, and “can the LAN behave?”

Voice is sensitive to jitter, latency, and packet loss. Many networks look fine for browsing and file transfers while still producing choppy audio during busy periods. Planning for predictable behavior matters more than raw bandwidth alone.

A straightforward approach is to isolate phones on a voice VLAN and apply QoS end to end, including switch ports, uplinks, and WAN edges. When a separate VLAN is not possible, DSCP marking and queueing policies can still make a meaningful difference.

After the plan is in place, validate it with real traffic. A few test calls across busy network segments will reveal more than a diagram.

DNS, FQDN, and certificates: the identity layer 3CX depends on

3CX expects consistency between the PBX FQDN, DNS records, and certificates. When that identity story breaks, the symptoms can look random: apps fail to connect, provisioning links misbehave, or remote phones “sometimes” register.

A common best practice is split DNS:

• Internally, the PBX FQDN resolves to the LAN IP
  
• Externally, the same FQDN resolves to the public IP (or reverse proxy endpoint)

Certificate planning is part of the same decision. Many deployments use Let’s Encrypt during setup, which works well when DNS and public reachability are clean. If a company must use its own certificate, it should be ready before the wizard starts.

Firewall baseline: open what 3CX needs, refuse the rest

Firewall work is where good installs become reliable installs. The goal is not “open a bunch of ports and hope.” The goal is precise allowances, verified with the 3CX Firewall Checker, and paired with policies that reduce exposure.

A quick reference table helps keep implementation and review aligned:

| Purpose | Common ports | Notes | |—|—:|—| | SIP signaling | UDP 5060 (varies by trunk) | Provider requirements may differ | | RTP media | UDP 9000 to 10999 | Plan for peak concurrent calls | | 3CX tunnel (SBC, apps) | TCP/UDP 5090 | Useful for remote phones and some topologies | | HTTPS / provisioning | TCP 443 (or custom) | Used for web client, provisioning, certificates | | 3CX cloud services | Outbound HTTPS | Activation, updates, PBX services |

After rules are applied, SIP ALG (or “SIP helper”) should be disabled on the firewall. Many one-way audio and registration issues disappear as soon as ALG is off and the checker is green.

A short hardening pass often includes restricting management access to trusted IPs, limiting who can reach the admin console, and confirming that outbound access is only what the PBX truly needs.

Installation and first-login configuration

Once the host and network are ready, the actual install is usually the easy part. The setup wizard choices still matter, though, because they lock in the system identity and initial security posture.

Right after installation, the highest value steps tend to be:

• Apply updates appropriate to the chosen release strategy
  
• Configure scheduled backups with off-box storage
  
• Confirm time settings and NTP behavior
  
• Run the Firewall Checker and correct findings immediately

That backup step should not be treated as “set it and forget it.” A backup that cannot be restored is just a file that takes up disk space, so restoration testing belongs in the rollout plan.

SIP trunk and DIDs: make routing predictable

Trunk setup is not only about registration status. It is also about making inbound identification and outbound presentation behave exactly as intended.

Many teams get the cleanest results by mapping each DID to a clear destination and documenting the intent. If multiple numbers share a trunk, caller ID matching rules become part of the design, not an afterthought.

After trunk setup, test inbound calls from multiple carriers and mobile networks. It is a fast way to catch DID mapping errors and provider-side routing problems before users do.

Extensions, phones, and remote users

A consistent extension plan saves time for reception, support, and reporting. Decide early on whether numbering will be three digits, four digits, or site-based blocks, and keep naming conventions consistent for directories and presence.

It helps to decide provisioning methods before phones arrive. Options range from LAN auto-provisioning to provisioning links to SBC-based approaches for remote sites.

Teams often standardize a few user device patterns to simplify support:

• Desk phone plus mobile app
  
• Desktop softphone only
  
• Common area phone with limited permissions

For remote users, test from outside the corporate network early. Waiting until go live week to validate NAT behavior and app connectivity is a common source of last-minute scrambling.

Call flow build-out: IVRs, queues, and time conditions

The call flow is what employees and customers experience, so it deserves careful design and real testing. Build it in layers: direct DID routes first, then receptionist logic, then queues and after-hours behavior.

A useful internal checklist paragraph to accompany the build is to define where calls go in every state: business hours, lunch, holiday, after-hours, and emergency closure. If a destination is “a manager’s cell,” confirm that the dial plan allows it and that caller ID presentation is correct.

Configuration reviews go faster when the call flow is written down. A simple diagram or a table of DID to destination can prevent accidental loops and misroutes.

A compact quality bar for call routing can be captured like this:

• Inbound rules: Every DID mapped and tested from an external caller
  
• Outbound rules: Least-cost and permission boundaries verified by role
  
• Time conditions: Business hours and holidays validated with a clock change test

Security and governance settings that pay off

3CX is a communications system, which makes it a tempting target for toll fraud and password guessing. Solid defaults and a few governance choices can reduce exposure without making the system painful to run.

After base configuration, many deployments include:

• Strong credentials: Admin accounts, extension PINs, and voicemail PIN policies
  
• Role-based access: Limit who can edit trunks, routing, and templates
  
• TLS/SRTP where practical: Encrypt signaling and media when trunks and endpoints support it
  
• Alerting: Email notifications for trunk status changes and suspicious activity

Security is also operational. Someone should own a monthly check of failed logins, trunk errors, disk capacity, and backup success.

Integrations, reporting, and the “make it useful” layer

A phone system becomes more valuable when it ties into daily workflows. Common examples include CRM screen pops, call journaling, voicemail to email, and reporting for queues and staff performance.

This is also where many teams want help with newer capabilities in 3CX, including AI-related features and analytics expectations. Planning matters because reporting and AI features are only as good as the data structure beneath them: clean ring group design, consistent user naming, meaningful queue definitions, and stable call routing.

We are VoIP often supports this stage for small and mid-size businesses that want their 3CX configuration tightened up, reporting made actionable, or an on-prem deployment moved into a hosted model. Their one-time system checkup option is commonly used to identify routing gaps, call quality risks, and security settings that need attention without committing to a full rebuild.

Go-live testing that catches the real-world issues

Testing should reflect how people actually call, transfer, park, conference, and use mobile apps. A go-live script that is too narrow tends to miss the problems that show up in the first week.

A practical test pass usually includes:

• Inbound call to each DID, then transfer to the correct team
  
• Queue overflow behavior and voicemail delivery
  
• Outbound dialing from each user role and each office
  
• Remote user registration and audio in both directions
  
• Call recording behavior and retention expectations, if enabled

If high availability or trunk failover is part of the design, those failover events should be tested intentionally. It is better to learn what “failover” really means during a scheduled window than during an outage.

When it makes sense to bring in a 3CX partner

Some teams have in-house IT and still prefer a partner for the telephony-specific parts: firewall rule validation, trunk normalization, dial plan design, and troubleshooting call quality. Others want to offload hosting, backups, and patching so the PBX is treated as a service, not another server to babysit.

We are VoIP operates as a 3CX reseller, hosting partner, and service provider, which fits organizations that want 3CX licensing and hosting options in one place, plus practical help tuning an existing deployment. For businesses that inherited a messy setup, a focused checkup can be a fast way to stabilize the system and set a clean path for growth.