This document is a technical solution description of the tool providing brief details on the product features and architecture with all necessary solution prerequisites
Introduction
ExpertFlow Campaign Manager (ECM) allows businesses to run automated outbound campaigns with multiple channels, including voice and SMS to keep in contact with the customer base, for purposes such as to send periodic billing reminders/ appointment reminders, announce product/services promotions, making callbacks to follow up. The web-based administration offers contact center managers to schedule campaigns for particular hours of a day, days of the week, pause an active campaign or resume a stopped campaign with a toggle button and define the call rescheduling strategies based on business policies and call outcomes (for instance, send an SMS on phone 02 if phone 01 is ‘busy’). The solution works on top of Cisco contact center and leverages on the dialing capabilities of Cisco Outbound for dialing calls. It then syncs call results from the Outbound system with ECM for it to apply rescheduling call strategies based on call results.
Business Features
Voice campaigns
Run automated, IVR or Agent-based campaigns to quickly contact your customers to give them a reminder alert, promote a new service or package, or call the customers back as a result of a dropped call.
SMS campaigns
Run standalone SMS campaigns to broadcast a message to a list of customers. In case of running an SMS campaign, the campaign type should be set to “None”. Select the “Default” strategy or create your own customized call strategy having all “SMS attempts” for the SMS campaign. See more about Call Strategies below.
Multi-channel campaigns
A voice campaign can also switch to ‘SMS’ at any time during a contact’s lifespan in the campaign. For instance, you can choose to send an SMS to a customer if his phone comes ‘Busy’ as a result of the first Voice attempt. See Call Strategies to learn more about this.
However, this is not vice versa for the moment. That is, an SMS campaign can not be converted to a Voice campaign. This also implies that an SMS campaign should always contain SMS attempts in the campaign strategy.
Campaign Schedule
Campaign schedule allows administrators to control campaign execution based on the defined hours of a day, days of the week. This is useful when you need to define a campaign once and have it running repeatedly during specified timings, on specific days of the week and avoid running it on other days.
However, once the life cycle of a customer is closed within the campaign (i.e. all strategy attempts completed), you must upload customer data through CSV files to the campaign to make calls to customers once again.
Start/Stop a Campaign
Using a toggle switch, a campaign can be started or stopped at any time.
If a campaign is disabled or stopped, no further calls are queued to Cisco Dialer. However, the contacts that were already pushed would be dialed.
If the user resumes an already stopped campaign, the dialing starts based on the specified, scheduled time.
Call Strategies
Call strategies determine how to contact a customer and what to do if the customer does not respond in the first attempt. With this, the user can select:
The preferred channel to contact the customer, i.e. Voice or SMS
Phone number to contact the customer out of a list of five phones (optionally)
The decision as to how many times a customer should be contacted depends upon the number of attempts configured in the call strategy. One can set Voice call strategies for the following dialer Outcomes:
Busy: Dialer returns this when a Busy tone is detected against the customer’s phone
No Answer: Dialer returns this when customer’s phone returns ‘No Answer’
Abandoned: This is returned in case if the call got abandoned by the customer
Others: This category groups all non-connected types of dialer outcomes other than the ones mentioned above such as Fax, SIT Tone, Answering Machine Detection.
In addition to voice, administrators can also choose to send an SMS to a customer. In case of SMS attempts, an SMS template must be specified in the campaign configuration. If the sent SMS expires without receiving any response from the customer, the user can choose to make another attempt or close the contact in the database. This is done by setting an expiry time (in minutes) for the message to get expired before it receives any response from the customer.
One strategy can also be shared among multiple ECM campaigns.
Note:
If the strategy is configured for Phone 1 and Phone 2, the customer numbers must also be provided for the two phone fields.
If the optional "Phone" field is left empty while uploading the customer file, the attempts configured for phone 2 will also be made on Phone 1.
Upload Campaign Contacts
You can upload contacts in ECM using the following ways:
Using the application’s web interface
Using RESTful Calls
Using Interface
Application users can upload campaign contacts through a .CSV/.Txt file from the web application.
The comma-separated CSV file should follow the following format to upload contacts:
Field | Description |
Phone 1 | The primary phone number of the contact. This number can be 28 characters long and must be a valid phone number. This is mandatory and must be specified. |
Phone 2 | The secondary, optional phone number of the contact. This number can be 28 characters long and must be a valid phone number. This is optional and can be left as is. Add comma alone if this field needs to be left empty. |
Phone 3 | The third, optional phone number of the contact. This number can be 28 characters long and must be a valid phone number. This is optional and can be left as is. Add comma alone if this field needs to be left empty. |
Phone 4 | The fourth, optional phone number of the contact. This number can be 28 characters long and must be a valid phone number. This is optional and can be left as is. Add comma alone if this field needs to be left empty. |
Phone 5 | The fifth, optional phone number of the contact. This number can be 28 characters long and must be a valid phone number. This is optional and can be left as is. Add comma alone if this field needs to be left empty. |
Business Parameter 1-12 | These parameters can contain any custom value for a particular customer contact such as Account Type, Customer Email. The length of the data in these parameters can be defined as per the integration specifications locked with ExpertFlow. The length of each of these parameters cannot be more than 40 characters. |
Using RESTful APIs
ECM also exposes REST-based APIs to upload a CSV file in the API call. The API takes ECM Campaign and the file to be uploaded as input parameters and imports the contacts within the file into the database.
These APIs are especially helpful while doing campaign management from third-party CRM applications such as Siebel, MS Dynamics. See 15500720.
View Contacts Status
For each ECM campaign, administrators can view the current status of contacts in the ECM database.
Details of the report columns are described in the table below:
Field | Description |
Phone 1 | The primary phone number of the contact. See 15500720to learn more about this field. |
Phone 2 | The secondary, optional phone number of the contact. See 15500720 to learn more about this field. |
Phone 3 | The third, optional phone number of the contact. See 15500720 to learn more about this field. |
Phone 4 | The fourth, optional phone number of the contact. See 15500720 to learn more about this field. |
Phone 5 | The fifth, optional phone number of the contact. See 15500720 to learn more about this field. |
Request State | This is the current state of the contact in the ECM database. |
Request Time | This is the time of the last attempt made to the contact by the application. |
Cisco Campaign ID | This is the campaign ID of the Cisco campaign which is associated with this ECM campaign. |
Number To Call | This is the current number from the list of five phone numbers on which the current attempt should be made. (Voice or SMS) |
Business Parameter 1-12 | These parameters can contain any custom value for a particular customer contact such as Account Type, Customer Email. See 15500720 to learn more about these fields. |
The administrator can customize this view to see or hide the desired fields such as only Phone 1 to phone 5, Request time and Number To Call.
The list shows all contacts uploaded in a campaign with the Request State column updated. This field can assume one of the following values:
Field | Description |
Pending | Represents contacts which are yet pending and have not been sent to the dialer. |
Sent to Dialer | Represents contacts that have been sent to the dialer. |
Connected | Represents contacts that were dialed and connected successfully with the agents. The calls having this outcome will be assumed as ‘closed’. |
Not Connected | Represents contacts that were dialed but not connected successfully. The calls having this outcome are ‘closed’ as per the call strategy defined. |
Retries Completed | Represents the contacts for which all the retry attempts have been completed without any success to connect with the customer. The calls having this outcome are assumed to be ‘closed’ since all attempts have been expired. |
DNC Listed | Represents contacts that were found in the DNC list and were marked as DNC. |
SMS sent and Closed | Represents contacts to whom an SMS was sent and the contact got closed, without any check on if the client responded. |
SMS sent | Represents contacts to whom an SMS was sent and no response was received till yet from the customer. Contacts who are in this state will not be closed till the time a response is received or another attempt is made, based on the specified SMS expiry time and the delay interval to be given before retrying. |
Dangling | The record status is set to Dangling if it is not synchronized within a specified time from CCE/CCX, i.e it has been sent to the dialer but the call result is not fetched within that time due to any reason. No further action will be performed on such a record so it would be assumed as closed. |
SMS responded | Represents contacts to whom an SMS was sent and a response from the customer was received. After receiving the response, the contact would be closed in the database. |
Integration with CRM
ECM exposes REST-based APIs for granting control of campaign management from within the third-party CRM applications (such as Oracle Siebel, MS Dynamics CRM). Via these REST APIs, administrators can create and manage outbound voice campaigns, pause/resume a campaign, and upload a list of contacts for dialing, all from inside their CRM. For a complete list of API functions, please refer to ECM API Guide.
Call results for campaign calls can also be uploaded to the CRM application using interfaces (normally WSDLs) provided by the client’s CRM team. The reporting on campaigns can then be made available from the CRM application as well (provided that the client’s CRM application provides such reporting interfaces).
Note:
This is not available out of the box unless mentioned explicitly. Lock the specifications with ExpertFlow account manager if ECM has to be integrated with the CRM. The client organizations can choose to either purchase ExpertFlow professional services to implement CRM integration using ECM APIs OR delegate this to their own CRM teams.
Note:
An additional CRM consultation fee can also be added if the client wants ExpertFlow to handle the CRM side as well. Additional PS is charged for updating of call results to the CRM.
Integration with Agent Call Scripter/Agent Guidance
If the ExpertFlow Agent Guidance module is purchased, clients can also design call scripts or conversational guides for agents to record customer feedback while making outbound calls. It works such that each ECM campaign has its own conversational script or a questionnaire that opens up as a Finesse gadget while answering a campaign call.
This especially helps in scenarios where call center agents need to record customer feedback while doing outbound campaigns. For instance, agents registering a new purchase order for a customer interested in the new product/service launch, or agents filling out a survey questionnaire based on the customer feedback about company products and services.
Pause/resume campaigns based on filters
Users can also choose to pause or resume a campaign at any time with a toggle button on the admin interface. Clients can also choose to pause/resume a campaign based on certain filters using APIs. For instance, stop an active campaign in a certain district and keep it running in the other districts.
Maximum active campaign limitation
Contrary to UCCX Outbound, there are no limitations as such in ECM on the maximum number of campaigns being active at a point in time. That means any number of campaigns can remain active at any point in time.
Do-Not-Call List (DNC)
The DNC list contains the phone numbers which should not be dialed for outbound campaigns. Usually, the customers who do not wish to be contacted by the organizations are added in the system as DNC contacts.
ECM scrubs the uploaded list of campaign contacts against the list of DNC before dialing the phone number. So if a contact exists in the DNC, the contact will not be dialed out.
Note that this DNC list is a global list and is applicable to all campaigns created in ECM. The individual, campaign-level DNC is not yet available.
Campaign Reports
ExpertFlow provides few standard reports for ECM campaigns within CUIC.
The reports are developed on top of the ECM database and should NOT be compared with those of the stock reports available from the Cisco Dialer.
Solution Architecture
Integration with Cisco
Since ECM leverages on the dialing capabilities of Cisco Outbound, each voice campaign in ECM is mapped to a corresponding campaign in Cisco Outbound. So all technical, dialing-related details such as dialer modes (Predictive, Progressive, Preview), call scripts to be attached with an IVR campaign or CSQs/Skill groups to be linked with an agent-based campaign are handled at Cisco side while ECM keeps the campaign configuration simpler for non-technical supervisors and administrators.
A contact uploaded in ECM is then forwarded to the respective Cisco dialer campaign over APIs (in case of CCX) or DB connections (in case of CCE). A backend sync service synchronizes call results from the Cisco Dialer DB and updates them in the ECM DB for all dialed calls.
Note that one Cisco campaign can also optionally be shared by several ECM campaigns, who have the same call flow and/or agents to handle calls but run in different schedules (start, end timings) or have different prompts to be played.
Communication Flow
Workflow for voice campaigns
User creates a campaign in ECM (IVR or Agent based) and selects the relevant Cisco campaign
User uploads campaign contacts to the campaign using any of the options described in Upload Campaign Contacts section
ECM’s “Contacts Feeder” service writes the contact to the Cisco campaign DB over APIs (in case of UCCX) or direct DB connections (in case of CCE)
Cisco Outbound generates an automatic call to the customer
The results of the calls are synchronized by the “Call Results Synchronizer” service
Unsuccessful calls are retried or closed as per the strategy defined in Call Strategies.
Workflow for SMS campaigns
The user creates an SMS campaign in ECM.
The user associates the “Default” strategy with the campaign or create a new, customized strategy and associate it with the SMS campaign.
Uploads a CSV file containing contact details.
The system sends SMS messages in bulk to customers in the list using the client’s SMS gateway
The delivery status of the SMS messages are updated in the DB (if the SMS gateway in use by the client sends the delivery report)
Contacts are retried or closed based on the strategy defined in the Call Strategies.
The response message from the customer is neither available nor processed further in the ECM database.
Deployment Models
Non-Redundant / Simplex Mode Deployment
For a non-redundant deployment, the application is deployed on a single server with a single point of failure.
High Availability (HA) / Duplex Deployment
For HA, ExpertFlow deploys the solution on two VMs as Docker containers using Docker Compose. If one VM goes down, the traffic will be routed to the other VM.
Each solution component is deployed as a stateless microservice in its own Docker container. Expertflow opted for a service-per-container paradigm in which each backend microservice is executed in its separate container.
Each Docker container is deployed with the “Restart Always” policy which causes it to restart automatically on the same VM. Notice that there might be a downtime of a few seconds while restarting the container. This implies that any requests received during the downtime will be rejected.
Services will be available via a virtual IP. If one of the VMs goes down, the virtual IP will route the traffic to the other VM.
Out of Scope
- Component-Level Failover: Failover of individual components is not supported.
- Network-level failover support: The internal network/link between the VMs (or the Docker network) is assumed to be working all the time.
- DB Cluster: Setting up the DB cluster for MS SQL Server lies under the Customer responsibility.
- Manual intervention will be required when both VMs are down.
Failover scenarios
| Failover Scenario | Behavior | |
|---|---|---|
| 1 |
Solution Security
Permissions-based User Access
ExpertFlow applications have a central authentication module that automatically synchronizes contact center supervisors and agents from CCX/E into the User Management module. This allows any contact center user to log into the application using the same Finesse credentials without the need to recreate the user credentials in the application again.
With the latest version, the application also allows administrators to create local user accounts for supervisors or/and agents with a user-defined password and username. Restricted permissions on the level of entities allow administrators to assign selective privileges to a particular group of users.
Note:
- Currently, the permissions can only be granted on selective lists/entities. More granular permissions on the level of selective fields or certain data cannot be granted.
- The password reset option is not available for local users. If a local user has forgotten his password, he needs to request the admin to create a new account to get logged in.
HTTPS Support
For HTTPS support, provide a valid certificate from a certified Certificate Authority (CA).
Solution Prerequisites
SMS Campaign Requirements
To run an SMS campaign, the application needs to connect with an SMS Gateway such as Infobip, CM SMS Gateway, Tropo and Twilio. It can also connect to a Direct-to-SMSC Gateway over SMPP.
The application can also work with a hardware-based SMS Gateway with APIs such as SMS Eagle, Ozeki NG SMS Gateway and GrepTech SMS Gateway.
Port Utilization
Type | Source Host | Source Port | Destination Host | Destination Port |
|---|---|---|---|---|
TCP | Any application in LAN | any | MS SQL Server | 1433 |
HTTP/S | ECM Application | any | UCCX/Informix DB | 80/443 |
HTTP/S | Enterprise web user | any | ECM Web App | 8080/8443 |
SMPP | ECM Application | any | SMS Gateway | 2775 |
Hardware Sizing
CPU | vRAM | vDisk |
|---|---|---|
2 cores (2.60GHz, 2 processors) | 8 GB | 1x100 GB |
Software Requirement
OS Compatibility
We require the customer/partner to install the following software on the server.
Item | Version |
CentOS 7 | Administrative privileges (root) are required to follow the deployment steps. |
Database Requirements
Item | Notes |
| MS SQL Server 2014, 2016 Express/ Standard/ Enterprise |
Docker Engine Requirements
| Item | Notes |
Docker CE | Docker CE 18+ and docker-compose (in case of CentOS) |
| Git | Git install |
Browser Compatibility
Item | Version | Notes |
Firefox | the latest | |
Chrome | the latest | |
| IE | Not tested | An on-demand testing cycle can be planned |
Cisco Unified CCX Compatibility
UCCX 11.6
System Access Requirements
Machine Access
Administrative privileges (root) on the machine are required to follow the deployment steps.
Provision Database and a user on SQL Server
The following database and the privileged SQL user is required to connect to the application database. The application will create its tables and other schema objects itself after connection.
Create an application database with a name such as EFECM
Create a SQL Server User EFUser with a database role db_owner on the EFECM database
Time Synchronization Requirements
If the system dates and times are not synchronized, the system can produce unpredictable results. Therefore, the EF applications and Cisco UCCX should have their time zone and date/time properly configured, according to the geographic region and must be synchronized.
To configure the time zone, please see the instructions from the hardware or software manufacturer of the NTP server. The application servers should be synchronized. This synchronization should be maintained continuously and validated on a regular basis. For security reasons, the Network Time Protocol (NTP) V 4.1+ is recommended.