How to Add a Predictive Dialer to Your Existing PBX (Without Replacing It)

If you already run Asterisk, FreePBX, 3CX, Cisco or Avaya, you have a working phone system, carrier contracts you negotiated, numbers your customers know, and a dial plan somebody spent months getting right. Then someone asks for an outbound campaign — a collections push, a renewal drive, a win-back list of forty thousand records — and you discover the phone system cannot really do it.

The usual advice at that point is to replace the phone system. That is an expensive answer to a narrow question, and it throws away infrastructure that is doing its job perfectly well. This guide covers the alternative: leaving the PBX exactly where it is and adding a campaign layer on top of it. What that architecture looks like, how the two systems connect, how to size it, where compliance has to live, and how to get there without putting the floor at risk.

Why your PBX cannot run outbound campaigns on its own

This is not a shortcoming of your PBX. It is a category difference. A PBX is a routing engine: a call exists, and the PBX decides where it goes. A dialer is a decision engine: it decides which call should exist in the first place.

Asterisk can originate a call — that is exactly what call files and the AMI Originate action do. But originating calls is perhaps a tenth of what a campaign needs. Four pieces are missing, and each one is substantial:

• A list and pacing engine. Which record is next, how many calls to have in flight for the number of agents currently free, when to retry a no-answer and how many times, which time zone the record belongs to, when to stop.
• Answering machine detection. Roughly two thirds of outbound attempts to mobiles reach voicemail. Without screening, your agents hear voicemail greetings all day and your pacing maths is meaningless.
• An agent state model. The dialer needs to know who is ready, who is on a call, who is in wrap-up and who has stepped away — continuously, in real time — because pacing is entirely a function of predicted availability.
• Dispositions and compliance logging. What happened on the call, what the customer agreed to, what was suppressed and why, and an audit trail that survives a regulator asking about a specific call eighteen months later.

None of that belongs in a dial plan. That is why bolting campaign logic into a PBX tends to produce something fragile that one person understands.

The three ways teams solve it — and what each really costs

Replace the PBX with an all-in-one platform. Clean architecture and a single vendor, at the cost of re-implementing your inbound routing, retraining agents, migrating or forfeiting numbers, and often moving to per-minute pricing on voice you were previously buying wholesale. This is the right answer if your PBX is genuinely end-of-life. It is an expensive answer if it is not.

Build the campaign layer yourself. Entirely viable on open-source telephony, and some strong teams run exactly this. The honest accounting is that you are not building a dialer once — you are maintaining pacing behaviour, detection accuracy, agent state, dispositions, recording, suppression enforcement and reporting, and carrying the on-call burden when pacing misbehaves during a Monday morning campaign. We wrote about that trade-off in more depth in build versus buy for dialer software.

Overlay a dialer over SIP. The PBX keeps doing what it already does well; the dialer adds only what is missing. No numbers move, no carrier contract changes, agents keep their extensions if you want them to. This is the path this guide covers, and it is what we call Pattern B — one of the three ways DialerBee connects.

How the overlay actually works

The mechanics are simpler than they sound. A campaign call has two legs, and the split between them is the whole design:

1. The dialer selects the next record from the list, having already checked suppression, consent state and the calling window for that record's time zone.
2. It originates the outbound leg over your carrier trunk, presenting a caller ID you control.
3. The call is answered. The dialer screens the audio and classifies it: a live person, an answering machine, a fax, a network tone, silence.
4. Machines are handled without an agent — dropped, or left a message if your policy allows one. Only live humans proceed.
5. The live call is delivered into your PBX over the SIP trunk, arriving at a pilot number, hunt group or queue.
6. Your PBX routes it to an agent exactly as it routes any other call.

From the PBX's point of view, a call simply arrives on a trunk and needs routing — something it already does thousands of times a day. All the campaign intelligence happens before that moment. That is why this integrates so cleanly: you are not asking the PBX to learn anything new.

Connecting the two: SIP trunk, SBC and registration

The connection between dialer and PBX is a SIP trunk, and you have two common options for how it authenticates. IP-based trunking is the usual choice when both ends have stable addresses — each side allow-lists the other and there is no registration to expire. Registration-based suits estates behind dynamic addressing, where the dialer registers to the PBX like a device would.

A few practical points that decide whether this is a smooth afternoon or a long week:

• Where the SBC sits. On Cisco and Avaya estates there is almost always already a session border controller terminating carrier trunks. Put the dialer trunk there too — it is the natural demarcation, and it gives you one place to look at signalling when something misbehaves.
• Media path. Decide deliberately whether media flows through the SBC or directly. Direct media reduces latency and load; anchored media is easier to troubleshoot and record consistently. Either is fine, but the choice should be made rather than discovered.
• Codecs. Agree one codec on the internal trunk and avoid transcoding. G.711 between dialer and PBX is the safe default; transcoding costs quality and, on some platforms, licences.
• DTMF. Settle on RFC 2833 and confirm it end to end. Mismatched DTMF is the classic failure that only appears once a customer tries to press 1 on an IVR.
• NAT. If either end is behind NAT, get the signalling and media addressing right before testing at volume. One-way audio at scale is almost always this.

Our SIP trunk setup walkthrough covers the configuration in more detail, and bring your own carrier explains the trunking model.

Keeping your carrier and your numbers

The commercial half of this decision matters as much as the technical half. In an overlay, the platform never carries your voice — it signals your carrier to place calls on trunks you already own. Three consequences follow:

• Your rates stay yours. If you negotiated good termination, you keep it. Nobody re-marks-up minutes you already buy wholesale.
• Your numbers stay yours. No porting project, no dependency on a vendor for your inbound identity, no hostage situation if you change your mind later.
• There is no per-minute platform fee. When the platform does not carry the voice, there is nothing for it to charge per minute. You pay per agent seat and pay your carrier for minutes, separately.

That last point changes campaign economics more than people expect, and it changes them most for the highest-volume campaigns — exactly the ones where a per-minute margin hurts most. We compare the two models directly in per-agent versus per-minute pricing and BYOC versus bundled telecom.

Where your agents sit: PBX extensions or a browser desktop

Once a live call reaches your PBX, it can go to the extension your agent already uses. That is the least disruptive option, it needs no change on the desktop, and it is a perfectly reasonable way to run a pilot.

Its limit is that a desk phone is only audio. It cannot show who is calling and why, cannot capture a disposition, cannot display the script or the compliance prompt, and cannot give a supervisor a live view. Everything the campaign layer knows stops at the handset.

The alternative is a browser-based agent desktop: the audio path runs over WebRTC and the screen carries the customer record, the script, the disposition list and the wrap-up timer. Supervisors get live monitoring rather than a walk across the floor. The comparison in browser dialer versus installed software and our note on WebRTC versus SIP phones covers the trade-offs.

In practice hybrids are common and sensible: an inbound team stays on handsets while the outbound campaign team moves to the browser, with both connected to the same PBX.

Sizing it: channels, pacing and abandon-rate headroom

The number that catches teams out is concurrent channels, because it scales with your pacing ratio rather than your agent count.

Twenty agents dialing at a 2:1 ratio need roughly forty concurrent outbound channels — plus headroom for calls that are still ringing or being screened and have not yet resolved. Fifty channels is a realistic provision. Push to 3:1 and the same twenty agents need around seventy. Size the trunk for peak, not average: when the trunk saturates, the dialer cannot pace, and agents sit idle waiting for calls that cannot be placed.

Two further constraints are worth knowing before you configure anything:

• Calls per second. Carriers and SBCs both impose CPS limits. A campaign starting at 9am can burst well above your steady-state rate, and hitting a CPS ceiling produces rejections that look like carrier faults.
• Detection accuracy sets your pacing ceiling. Aggressive pacing is only safe if you can reliably tell a person from a machine. Where classification is weaker — an unfamiliar market, an unusual language, heavy carrier-default voicemail — the honest response is to pace more conservatively rather than accept a rising abandon rate.

Our predictive dialer tuning guide goes into the pacing maths, and the abandon-rate estimator lets you model a ratio against your own numbers before you commit to it.

Compliance in a split architecture

This is the section to read twice, because it is where brownfield deployments most often go wrong.

When two systems share a call, it is tempting to split the controls between them. Do not. Suppression checks, consent state and calling-hour windows must all live in the campaign layer, for a structural reason: the campaign layer is the system that decides which number to dial and when. By the time a call reaches the PBX, that decision has already been made and cannot be un-made. A PBX can refuse to route a call; it cannot refuse to have placed it.

So the campaign layer should own, before origination:

• Suppression and do-not-call checks against the lists that apply to that campaign
• Consent state for the record, where consent is required
• The calling-hour window for the record's own time zone, not your office's
• Attempt limits and retry rules
• Caller ID selection and its registration status

The PBX keeps what it is already good at — recording policy on the agent leg, internal routing rules, and its existing access controls. What matters is that the gate sits before the call is placed, and that there is one audit trail rather than two that have to be reconciled. Our outbound compliance checklist and the compliance controls page cover the specifics.

These are compliance-supporting controls, not a compliance guarantee. Regulations differ by jurisdiction and change over time, and responsibility for your compliance programme remains with your organisation. Take your own legal advice for the markets you dial.

Multi-tenant overlays for resellers and integrators

If you sell telephony rather than only operate it, the overlay model is worth understanding as a commercial pattern and not just a technical one. Your clients have already bought their phone systems. Asking them to replace those systems to get outbound campaigns is a hard sell; adding campaigns to what they already own is a much easier conversation.

Each client runs as an isolated tenant — its own campaigns, suppression data, users, recordings and reporting — connected to whichever PBX and carrier that client already uses. Under a multi-tenant arrangement the platform can carry your branding rather than ours, which is covered on the reseller page.

A migration path that does not risk the floor

Nobody should cut an entire contact centre over in one weekend. The sequence below keeps the blast radius small at every step:

1. Pilot one campaign on one trunk. Pick a low-stakes list. Provision a separate trunk group so campaign traffic cannot affect inbound capacity.
2. Prove the call path with a handful of agents. Confirm audio both ways, DTMF, caller ID presentation, recording, and that dispositions land where you expect.
3. Tune pacing against real behaviour. Start conservatively — 1.2:1 or 1.5:1 — and increase only while abandon rate stays inside your ceiling.
4. Run parallel. Keep the existing process alive alongside the pilot for a full cycle so you have a genuine comparison rather than a hopeful one.
5. Cut over by queue, not all at once. Move one campaign or team at a time. Each move is small, and each is individually reversible.
6. Keep a rollback that you have actually tested. Rollback is disabling the campaign trunk and reverting a dial-plan entry — but confirm that before you need it, not during.

Our guide on migrating to a new outbound dialer covers list, disposition and reporting migration in more depth.

How DialerBee fits an existing PBX

DialerBee is built to run in exactly this shape. It connects three ways — with our SIP trunks, on top of a PBX or SBC you already operate, or over a carrier trunk you already contract — and the compliance gating, recording, agent desktop, supervisor tools, reporting and tenant isolation are identical on all three. On the two patterns where DialerBee does not carry the voice, there is no per-minute platform fee, because there are no minutes for us to charge for.

Preview, progressive, power and predictive modes are selectable per campaign, and answering machine detection uses language-aware AI across 11 languages. If you want to see it against your own estate, a 14-day trial needs no credit card, or book a demo and we will walk through your specific PBX and trunking setup.

Frequently Asked Questions