VICIdial vs 3CX

The fastest way through this decision is to write down what the system has to do, in the language of your business rather than the language of either vendor. Two or three sentences is usually enough, and the answer tends to be visible in them.

If the sentences are about people being reachable, then this is phone system work. Everyone needs an extension. Calls to the main number need to reach the right department. People need voicemail, and to see who is on a call, and to transfer to a colleague. Staff working from home need the same number to follow them. There is a queue for support and somebody wants to see how long people wait in it. That is a PBX requirement from start to finish, and 3CX addresses it directly and completely.

If the sentences are about working through numbers, this is campaign work. There is a list. Agents work it. Somebody cares how many dials it takes to reach a contact, how long agents wait between calls, what proportion of calls are abandoned, which dispositions come back and when a lead should be tried again. There are rules about the hours a person may be called and numbers that must never be dialled. That is a dialling requirement, and it needs a platform built around lists and pacing rather than around extensions.

The clearest single test we know is this: does anybody in your organisation care what the abandonment rate is? If nobody has ever asked, and nobody would know why it mattered, you almost certainly do not need a predictive dialler and a phone system will serve you better. If it is a number your operations manager watches daily because a regulator cares about it, you are in campaign territory and a PBX will not take you there.

It is worth being specific about the ground 3CX covers, because engineers who spend their time in contact centres sometimes undervalue it. A business phone system has to give an identity to every person in the organisation: an extension, a place voicemail arrives, a presence state colleagues can see, and a number that reaches them. It has to route calls to the main line through an auto attendant to the right department at the right time of day. It has to handle hold, transfer, pickup, ring groups and the small conventions that make internal telephony feel normal.

It also has to work wherever people are. Desktop and mobile applications that carry the extension outside the office are not a luxury for a distributed workforce, they are the reason a modern phone system is bought at all, and they need to be maintained against operating system releases, which is a real ongoing product commitment. Video meetings and chat in the same place remove a separate tool. Support for physical desk phones matters more than software people expect, because reception desks, warehouses, workshops and clinical settings frequently need a handset rather than a headset and an application.

None of that is VICIdial’s territory, and the gap is architectural rather than a missing feature. VICIdial organises the world around agents, campaigns and leads. A member of your finance team is not an agent, does not belong to a campaign, and has no lead record. Attempting to express ordinary company telephony inside that model produces a system that technically places calls and is unpleasant for everyone who has to use it.

The queueing question deserves an honest answer too, because it is where the products genuinely touch. A support queue with a handful of people in it, ring strategies, an IVR in front of it and a supervisor watching the wait time is well within what a PBX with contact centre capability does. If that is the extent of your contact centre requirement, adding a campaign dialling platform gives you a second system to operate for no capability you needed.

The reverse case is just as clear and gets understated because outbound sounds simple from outside. Placing a call is trivial. Deciding which call to place, when, and how many at once is not, and that decision is the entire substance of a dialling platform.

Start with the list. Leads have to be loaded, filtered, ordered and recycled, and the rules for all of that change frequently because operations staff learn what works. Every call produces a disposition, and the disposition determines whether the lead is finished, retried later, passed to someone else or suppressed. Calling hours have to be enforced against the contact’s timezone rather than yours, and do-not-call suppression has to be reliable rather than mostly reliable, because a failure there is a regulatory matter and not a defect report.

Then there is pacing, which is the part that separates a dialler from a phone system that can make outbound calls. A predictive dialler places more calls than it has free agents, on the basis of measured answer rates and handle times, so that an agent is available at the moment somebody says hello. Tuned properly it keeps a floor productive. Tuned badly it fails in two directions at once, leaving agents idle while abandoning connected callers, and the second of those has a legal ceiling attached in most jurisdictions. This is a feedback control problem with a compliance consequence, and it is why campaign platforms exist as a category.

A PBX does not attempt any of that, and it is not a criticism to say so. Asking 3CX to run sustained predictive outbound across a large floor is asking it to grow a second product internally. The symptoms when organisations try are consistent and recognisable: campaign structure ends up in spreadsheets, retry rules become a convention somebody has to remember, calling-hour compliance depends on human discipline, and the reporting an operations manager needs has to be assembled by hand every week.

A great many organisations genuinely need both systems, and recognising that early saves a lot of wasted evaluation. A lender has a contact centre chasing arrears and also a head office where two hundred people need phones. An insurer has an outbound retention team and a claims department. A field services business has a dispatch operation and a sales floor. In each case one requirement is phone system shaped and the other is campaign shaped, and the two loads have almost nothing in common.

The pattern that works is separation with a deliberate connection. The phone system serves the organisation, sized for the traffic ordinary staff generate. The dialling platform runs as its own system, on its own infrastructure, with its own database and its own carrier capacity sized for the concurrency the campaigns will actually produce. That separation is the point rather than an inconvenience: a campaign floor at full pace generates a load profile that no phone system should be asked to absorb, and you do not want a busy dialling afternoon to be the reason nobody can reach your accounts department.

Where the two need to meet, connect them explicitly at the SIP layer and treat that boundary as designed rather than accidental. Transferring a campaign call to a named person inside the business, routing overflow from an internal queue, sharing a carrier or a set of numbers where that makes commercial sense: each of those is a specific integration with its own failure mode, and each is far easier to reason about when both sides were built as separate systems from the start than when one has been slowly stretched to cover the other.

There is also an ownership question that organisations answer too late. Two telephony systems mean two sets of numbers, two places a customer’s contact history could be recorded, and potentially two views of whether somebody has asked not to be called. Decide at the beginning which system is authoritative for customer contact history and for do-not-call state, and make the other one follow it. That is a small decision on day one and an expensive reconciliation project two years later.

We are deliberately not quoting prices, tier names or licence limits here. Vendor licensing changes, and a comparison page that hard-codes today’s packaging is misleading within a year. What is durable is the shape of each model, and the shape is what should inform the decision.

3CX is licensed commercially. The mechanism worth understanding is that it is fundamentally a PBX, with contact centre capability positioned in the higher tiers, so the price moves as you climb the feature ladder rather than tracking your call volume. That has a practical consequence: a company that only needs a phone system pays for a phone system, and a company that wants queueing, richer agent handling and supervisor tooling pays more for it. Check the current packaging directly with the vendor before you build a business case, because where exactly each capability sits is the thing most likely to have moved since anything you read about it was written.

VICIdial has no licence fee, at any agent count. That is genuine and it is the reason large floors adopt it. What replaces the licence is infrastructure sized for real concurrency, storage for recordings with a retention policy that is actually implemented, carrier contracts and channels, and the engineering capability to install, harden, tune, patch, monitor and diagnose the platform, whether that is salary or a retained partner. The important property is that this cost tracks call volume and complexity rather than headcount, so it flattens as the floor grows while a per-agent model does not.

Which means the two models cross somewhere, and where they cross depends on your seat count, your call volume, your retention needs and what competent telephony operations genuinely costs you. Below the crossover the licence is a modest cost against a real operational burden. Above it the burden is roughly flat while the licence keeps climbing. Our editorial piece on dialler cost models sets out why the curves behave that way and is the better place to read the argument in full. The one number people leave out of both sides is the cost of running a system badly, and on the self-hosted side that number is large: an unowned, untuned deployment degrades in specific and expensive ways long before anybody admits it needs attention.

This difference is easy to overlook during an evaluation and impossible to overlook six months in, so it deserves a section of its own.

3CX is designed to be administered as a product. A capable IT generalist installs it, provisions phones, configures the auto attendant and queues, adds and removes users as people join and leave, and applies updates. That is deliberate design, and it is a large part of why the product is chosen: the organisation does not have to acquire a new discipline in order to have working telephony. Support and documentation come from a commercial vendor with a licence relationship behind them.

VICIdial expects genuine telephony capability. Somebody has to size servers against real concurrency, keep the database serving live dialling and reporting without one starving the other, tune dial pacing against measured answer rates, manage a carrier relationship including provisioning enough concurrent channels ahead of demand, and diagnose faults that can originate in Asterisk, in the database, in the operating system, in the network or at the carrier. That diagnosis is breadth, not depth in one tool, and it is a specific skill rather than general IT competence.

Security belongs in the same paragraph because it is the responsibility most often deferred. Asterisk-based systems are scanned and targeted continuously for toll fraud, and an exposed, weakly configured server can be used to route expensive international traffic overnight with the carrier still expecting payment. Locked-down SIP and management surfaces, strong credentials, rate limiting, brute-force protection, carrier-side dialling restrictions and spend alerts, and monitoring that notices abnormal call patterns are not optional. Any self-hosted telephony system carries some version of this obligation, and it is a standing posture rather than a task you complete once.

Contracting the operations is a normal answer and it is a large part of what we do. What does not work is choosing a self-hosted platform for the absence of a licence fee and then leaving it unowned. An unowned dialler fails at peak, accumulates fraud exposure quietly, and eventually costs more than the licensed product it was meant to replace.

The most common real-world version of this is not a migration at all, it is an addition. An organisation runs 3CX happily as its phone system, then a part of the business starts doing serious outbound and discovers that campaign work is straining a system that was never built for it. The right move there is usually to add a dialling platform for the campaign floor and leave the phone system doing the job it does well, rather than replacing working company telephony because one department has a new requirement. Scope it as a new system with its own infrastructure, its own carrier capacity and its own owner, and connect it to the existing phone system deliberately at the SIP layer where the two genuinely need to meet.

Where a genuine replacement is on the table, moving campaign work from a PBX to VICIdial is a build rather than a migration, because very little maps across. Extensions do not become agents and an auto attendant does not become a campaign. What does transfer is your telephony knowledge and, often, your carrier relationship, which is a real head start over a team arriving from a hosted platform with no telephony experience at all. The work is sizing infrastructure against the concurrency the campaigns will produce, hardening it before it faces the internet, modelling campaigns, lists, dispositions and dial rules properly, porting or provisioning the numbers the outbound operation will present, and training agents on a denser interface than they are used to. Number porting runs on carrier and regulator timelines, so it belongs at the front of the plan rather than the end.

Moving in the other direction happens too and is worth naming without embarrassment. Some organisations are running VICIdial because somebody chose it years ago, and what they actually operate today is a phone system with a small support queue attached. If nobody has looked at a dial ratio in two years, if there is no list being worked, and if most of what the system does is get calls to the right person, then the honest recommendation is a phone system. Moving that way is mostly a configuration and change management exercise: rebuild the routing, provision handsets and applications, port the numbers, plan the export and retention of historical recordings before cutover rather than during it, and retire the servers.

Whichever direction you are going, cut over in stages. Move one team or one campaign, leave the existing system carrying the rest, and compare what actually matters before committing: call quality, whether people can reach each other, queue wait times, and for outbound the connect rate, abandonment and agent utilisation. Telephony cutovers done in a single step tend to find their problems at the busiest hour of the week, and everybody in the organisation notices when the phones are the thing that broke.