Outbound Campaign Management
Customer challenge
Outbound contact centre operations require a different operational model from inbound: supervisors must manage contact lists, define calling schedules, control dial pacing, enforce regulatory suppression lists, and measure campaign performance in real time. Many inbound-first contact centre platforms offer outbound as an afterthought — basic preview dialling only — requiring organisations to run a separate outbound dialler platform alongside their inbound system, with separate agent populations and duplicated reporting.
Compliance adds further complexity: GDPR requires opt-out enforcement and data retention controls; TCPA imposes calling time restrictions; opt-out lists must be applied in real time before any dial attempt.
ExpertFlow's approach
ExpertFlow's campaign management layer allows supervisors to define outbound campaigns against client lists maintained in ExpertFlow's core objects layer:
- Contact lists uploaded or CRM-synced, with deduplication and suppression
- Campaign scheduling: define calling windows per timezone and per campaign
- Dial pace control: preview and progressive dialling modes
- Real-time opt-out enforcement: suppression list checked before each dial attempt
- GDPR controls: consent tracking, data retention periods per campaign
- Blended agents: agents handle inbound calls during outbound campaign quiet periods without supervisor intervention
- Campaign analytics: connection rate, conversion rate, average handle time by campaign and agent
Every outbound conversation is recorded as a unified conversation object, linked to the client record and the originating campaign.
Why ExpertFlow wins here
ExpertFlow's unified conversation model treats outbound calls identically to inbound contacts — same routing, same recording, same CRM linking, same AI assist for agents. Organisations do not need a separate dialler product; outbound campaigns run on the same platform as inbound queues, enabling truly blended agent pools with no system-switching overhead. GDPR compliance controls are built into the campaign layer, not bolted on, which matters in regulated markets.
Architecture
Campaigns are defined and scheduled centrally, dispatched through a common channel-manager layer, and executed either by live agents, an IVR, or a digital connector — while contact state, pacing, and results are tracked in a campaigns database for full auditability.
Components
flowchart LR
CM["Campaign Manager<br/>(front-end)"]
SCH["Scheduler"]
CCM["Customer Channel<br/>Manager (CCM)"]
VC["Voice Connector /<br/>channel connectors"]
DLR["Dialer<br/>(EF CC / Cisco / provider)"]
SW["EFSwitch"]
DB[("Campaigns DB")]
AG["Agent"]
IVR["IVR"]
DIG["Digital connector"]
CM --> SCH --> CCM
CCM --> VC --> DLR
DLR <--> DB
DLR --> SW
SW --> AG
SW --> IVR
CCM --> DIG
SW -. result .-> DLR
DLR -. delivery notification .-> CCM -. webhook .-> CM
| Component | Role |
|---|---|
| Campaign Manager | UI for configuring contact lists, schedules, and campaign type |
| Scheduler | Timing and queuing orchestration; exposes APIs for digital activities |
| Customer Channel Manager (CCM) | Message-routing proxy between scheduler and connectors |
| Voice Connector | Protocol translation toward the dialer for voice campaigns |
| Dialer | Outbound execution; pluggable (EF CC Dialer, Cisco, or provider) |
| EFSwitch | Places the customer call and bridges to agent or IVR |
| Campaigns DB | Persistent contact and state storage |
Agent call flow
sequenceDiagram
participant CM as Campaign Manager
participant SCH as Scheduler
participant CCM as CCM
participant VC as Voice Connector
participant DLR as Dialer
participant DB as Campaigns DB
participant SW as EFSwitch
participant AG as Agent
CM->>SCH: contact list + scheduled call time
SCH->>CCM: forward contacts at appointed time
CCM->>VC: transmit contacts
VC->>DLR: pass contacts
DLR->>DB: persist contacts
Note over DLR: periodically process per campaign config
DLR->>CCM: request available voice agent (via VC)
CCM-->>DLR: agent details (via VC)
DLR->>SW: dial command (customer + agent info)
SW->>SW: initiate customer call
SW->>AG: bridge call on answer
SW-->>DLR: call result on conclusion
DLR->>DB: store result
DLR-->>CCM: delivery notification (via VC)
IVR and digital flows
- IVR campaigns follow the same path through contact dispatch; the dialer sends customer and IVR information to EFSwitch, which bridges to an IVR on answer. Results follow the same store-and-notify path.
- Digital campaigns are asynchronous: Campaign Manager schedules an activity via the Scheduler APIs; the Scheduler queues it and pushes to CCM at the scheduled time; CCM proxies to the appropriate connector. Delivery confirmations and customer read/response events return through CCM to the Scheduler, which updates CX Activities and notifies Campaign Manager via webhooks.
Contact data model
| Field group | Fields |
|---|---|
| Mandatory | UUID, phone number, campaign type (IVR/AGENT), EFSwitch gateway UUID, status (pending/agent_pending/dialed/ended/stopped/failed), call-result description, received timestamp, dial timestamp, campaign-contact ID, campaign ID, earliest/latest dial window, priority (1–10) |
| IVR (optional) | IVR number selection (defaults to dialer config) |
| Agent (required) | dialing mode (PREDICTIVE/PREVIEW), routing mode (AGENT/QUEUE), resource ID (queue/agent), optional queue name |
Campaign control APIs
| Operation | Behaviour |
|---|---|
| Start | Reset stopped contacts to pending |
| Stop | Set pending contacts to stopped |
| Purge | Remove all pending contacts for a campaign ID |
| Dialer status | Return max concurrent-call capacity and current active-call count |
Failover behaviour
| Scenario | Behaviour |
|---|---|
| Voice Connector unavailable | Retry pending contacts |
| DB unavailable (dispatch) | Retry cycle |
| Invalid EFSwitch gateway | Mark contact failed |
| Offline gateway | Reset contact to pending |
| EFSwitch unreachable | Mark contact failed |
| DB failure on control command | Return Service Unavailable |
| Missing campaign ID | Return Not Found |