Campaigns

Behavior

Agent Based Calls

1. The campaign manager send a list of contacts with a scheduled call time to the scheduler.

2. The scheduler sends these contacts to the Customer Channel Manager(CCM) at the scheduled time.

3. The CCM passes these contacts to the voice connector(VC).

4. The VC sends these to the dialer.

5. The dialer stores them in the a database.

6. The dialer periodically reads this database and processes the contacts based on the campaign type.

7. For Agent-Based calls, the dialer sends an agent request to the VC.

8. The voice connector sends a request for a voice agent with the call details to the CCM.

9. The CCM obtains the details of an available Voice agent and send them to the VC.

10. The VC passes these details to the dialer.

11. The dialer sends a command to EFSwitch with the customer and agent information.

12. EFSwitch calls the customer.

13. Upon answer, the call is bridged to the EF CX Agent.

14. When the call ends the call result is sent to dialer via EFSwitch.

15. The call result is stored in the database and sent to the VC.

16. The VC sends this result to the CCM as a Delivery Notification.

IVR Based Calls

1. The campaign manager send a list of contacts with a scheduled call time to the scheduler.

2. The scheduler sends these contacts to the Customer Channel Manager(CCM) at the scheduled time.

3. The CCM passes these contacts to the voice connector(VC).

4. The VC sends these to the dialer.

5. The dialer stores them in the a database.

6. The dialer periodically reads this database and processes the contacts based on the campaign type.

7. The dialer sends a command to EFSwitch with the customer and IVR information.

8. EFSwitch calls the customer.

9. Upon answer, the call is bridged to the EFSwitch IVR.

10. When the call ends the call result is sent to dialer via EFSwitch.

11. The call result is stored in the database and sent to the VC.

12. The VC sends this result to the CCM as a Delivery Notification.

Technical Solution

Contact Structure

The parameters for a campaign contact are set in the campaign manager sent to the scheduler.

These parameters are described in the following sections, along with other relevant information that the dialer stores in a database based on the state of the contact.

Mandatory

IVR campaign

Can be provided in an IVR campaign. If not provided, the default value configured in the dialer is used.

Agent campaign

Mandatory for agent campaigns.

Dialing Flow

1. The dialer will periodically query the database and take note of all the campaigns and the number of their contacts present.

2. It will also take note of the current free call slots.

3. It will then follow one of two cases:

   1. Slots > Campaigns

      1. At least one contact picked from each campaign.

      2. Preference given to campaign with least contacts.

      3. Dialing order for each campaign is FIFO, if multiple contacts from same campaign are picked.

      4. Overall dialing order is campaign with lowest contacts first.

   2. Slots <= Campaigns

      1. First for each campaign contacts are ordered by received_time ascending(from oldest added, to newest added)

      2. For each campaign the oldest added contact is put into a list

      3. This list is sorted by received_time ascending(from oldest added, to newest added)

      4. From this list we pick the first X number of contacts where X = free slots

4. These contacts are then sequentially processed based on the campaign type.

5. The dialing speed is also throttled based on the configured value in the environment variables.

IVR Campaigns

1. For IVR based campaigns, the IVR number is taken from the contact entry if set.

2. If the IVR number is not provided in the contact entry then the default IVR specified in the dialer configuration is used.

3. The dialer checks via EFSwitch ESL if the gateway provided is valid.

   1. If it is valid, then the following command is sent to EFSwitch to initiate the call: 

      JS

      originate {session_in_hangup_hook=true,domain_name=EFSWITCH-IP,record_session=true,origination_caller_id_name=IVR-NUMBER,origination_caller_id_number=IVR-NUMBER,call_direction=outbound,origination_uuid=call_uuid}sofia/gateway/GATEWAY-ID/CUSTOMER-NUM IVR-NUMBER XML EFSWITCH-IP

   2. If invalid, the contact status is set to 'failed' and it will not be redialed.

   3. If the gateway is down then the contact status is set back to 'pending' to be tried again later.

4. The call slots are decremented by 1.

5. Once the call ends, the dialer receives a call-ended event from the EFSwitch ESL and:

   1. Stores the call result in the database and sets the status to 'ended'.

   2. Sends the call result to the Voice Connector for a Delivery notification to be sent to the CCM.

   3. Increments the call slots by 1.

Agent Campaigns

1. If the campaign call type is of 'AGENT', then the contact status is set to 'agent_pending' and call information is posted to the voice connector API.

2. The call slots are decremented by 1.

3. The voice connector sends back the following payload when it received either an agent reserved or no agent available notification from the CCM:

4. If no agent was available, the dialer sets the contact status to 'pending' to try again the next time it queries for pending contacts.

5. If agent was reserved, then the dialer checks via EFSwitch ESL if the gateway provided is valid.

   1. If invalid, the contact status is set to 'failed' and it will not be redialed.

   2. If the gateway is down then the contact status is set back to 'pending' to be tried again later.

   3. In either case call information is sent to the voice connector which will send an END_CHAT payload to the CCM to close the conversation and free up the agent.

6. The following command is sent to EFSwitch which will call the customer and bridge the answered call to the agent:

   JS

   originate {ignore_early_media=true,session_in_hangup_hook=true,sip_h_X-Destination-Number=SERVICE-IDENTIFIER,sip_h_X-CallType=PROGRESSIVE,customer_number=CUSTOMER-NUM,sip_h_X-CALL-VARIABLE0=CALL-ID,sip_h_X-Call-Id=CALL-ID,domain_name=EFSWITCH-IP,record_session=true,call_direction=outbound,sip_h_X-queueType=NAME,sip_h_X-queue='QUEUE_NAME',origination_uuid=CALL-ID,origination_caller_id_name=AGENT-EXTENSION,origination_caller_id_number=AGENT-EXTENSION,sip_h_X-agentExtension=AGENT-EXTENSION}sofia/gateway/GATEWAY-ID/CUSTOMER-NUM agent XML EFSWITCH-IP

7. Once the call ends, the dialer receives a call-ended event from the EFSwitch ESL and:

   1. Stores the call result in the database and sets the status to 'ended'.

   2. Sends the call result to the Voice Connector for a Delivery notification to be sent to the CCM.

   3. Increments the call slots by 1.

   4. If the customer had dropped the call after answering (before the agent could be bridged):

      1. The dialer detects the case via the call variables in the call-ended event.

      2. Call information is sent to the voice connector which will send an END_CHAT payload to the CCM to close the conversation.

Additional Functions

Campaign controls

The dialer exposes three APIs that can be called by the campaign manager to start, stop or purge campaigns:

• Set this campaign's stopped contacts' status to 'pending'.

• Set this campaign's pending contacts' status to 'stopped'.

• Remove all pending contacts with this campaign ID.

Check Dialer Status

This API can be used to check the configured value of MAX_CONCURRENT_CALLS and the current number of active calls i.e. contacts with the dialed or agent_pending state.

Failover Cases