Jump to: navigation, search

Deploying Do Not Call Functionality

This topic discusses the deployment of Do Not Call functionality.

Do Not Call Table Structure

The Do Not Call table has a fixed structure, as shown in the following table. The customer_id field, like the phone field, is part of that established structure. The Do Not Call table does not require Format and Field configurations. Genesys Administrator generates this table if the Table Access object is present, but the physical table does not yet exist.

Note: If you manually add entries to the Do Not Call table, you must restart Outbound Contact Server (OCS) so that OCS can read the new records into its memory.
Alternatively, OCS will pick up these updates upon next reread of the Do Not Call list, if OCS is configured for such rereads. For a description of this functionality, see Rereading of the Do-Not-Call List.
Do Not Call Table Structure

Field Name

Type

Nullable

phone varchar (64) yes
customer_id varchar (64) yes
dnc_message varchar (255) yes
tenant_dbid decimal (18, 0) yes
campaign_dbid decimal (18, 0) yes
list_dbid decimal (18, 0) yes
is_internal int yes
time_stamp int yes
expires_at
int yes
Note: The phone field in 6.5 was changed to the contact_info field in the 7.0 Calling List table. The phone field is still in the Do Not Call List table.

User-Defined Field for Do Not Call

The restriction on dialing a particular customer is an alternative to the Do Not Call restriction applied to a particular telephone number. The ability to apply a a Do Not Call request to a specific customer is helpful when the same phone number appears on more than one customer's records. For example, in a family or roommate situation, one member of the household might want to be on the Do Not Call list while another person at the same residence and with the same telephone number might not make that request.

The value of the customer_id option in the OCS Application object is the name of the field that the user designates for the customer identifier. At start-up, OCS reads all the records from the table referenced in the gsw_donotcall_list Table Access and populates two separate tables in memory with unique values from the phone field and from the customer_id field. Do Not Call requests from the agent desktop can also populate these tables in memory during runtime.

Configuration Procedure

Perform this procedure in Genesys Administrator to create a user-defined field to identify customers for a Do Not Call List.

This new field will serve as the
customer_id
for Do Not Call requests and will be included in the
UserData
attached to T-Server events.

As the value of the customer_id option in the OCS Application object, this field will correspond to the customer_id field in the Do Not Call (gsw_donotcall_list) table.

Creating a User-Defined Field to Identify Customers for the Do Not Call List

Start

  1. Create a new user-defined field. On the Configuration tab, define the fields as follows:
    • Name = <user-specific name>
    • Data Type = varchar
    • Length = 64
    • Field Type = User-Defined
    Also select the options Nullable and State Enabled.
  2. Assign the send_attribute to on the Options tab by adding a default section.
    Define the fields as follows:
    • Option Name = send_attribute
    • Option Value = GSW_CUSTOMER_ID
  3. Designate the new user-defined field as the customer_id option in the OCS Application object.
    In Genesys Administrator > Environment > Applications > OCS Application object > Options tab > OCServer section, create and define the customer_id option. Use the name of the new user-defined field as the value of customer_id.
    • Option Name = customer_id
    • Option Value = <name of new user-defined field>
  4. Add the new field (defined in #1) to a new Format object.
    In Genesys Administrator, go to <Tenant> > Provisioning tab > Outbound Contact > Formats view, and create a new format for a Calling List table that includes the new user-defined field.
  5. Configure a Table Access object for the gsw_donotcall_list.
    In Genesys Administrator, go to <Tenant> > Provisioning tab > Outbound Contact > Table Access view, and create and configure a new Table Access object as follows:
    In the Configuration tab, specify the following:
    • Name = gsw_donotcall_list (required field value.)
    • Table Type = Log Table
    • DB Access Point = <user-specific name of DB Access Point> The DB Access Point here is for gsw_donotcall_list.
    • Format = None
    • Database Table = <user-specific name of database table>
  6. Create a Calling List object using the new format. In Genesys Administrator, go to <Tenant> > Provisioning tab > Outbound Contact > Calling Lists view, and configure a Calling List object as follows:
    In the Configuration tab, specify the following:
    • Table Access: <New Calling List>
  7. This is a new Calling List formatted with the customer_id field.

These configurations allow the customer ID to be inserted into Do Not Call requests, into the database table specified in the gsw_donotcall_list Table Access, and into the memory tables.

End

Updating the DNC List

Through Genesys Administrator, you can update a current DNC list with data from an external source. Genesys Administrator first reads data from an ASCII file, which is in comma-delimited format. The user then maps this data to the appropriate columns in the DNC list (database table).

The process to update or import data from an external source is composed of three steps:

  1. Selecting the data file and type.
  2. Assigning names to data columns.
  3. Specifying data import options.

For detailed instructions, see Framework Genesys Administrator Help (Provisioning Your Environment > Outbound Contact Object Types > Do Not Call List > Importing a Do Not Call List File).

OCS-Desktop Protocol Changes for DNC

A Do Not Call (DNC) request from an agent (GSW_AGENT_REQ_TYPE = DoNotCall) includes an attribute to specify the customer_id: GSW_CUSTOMER_ID. At least one attribute (GSW_PHONE or GSW_CUSTOMER_ID) must be present in the UserData of the request if the GSW_RECORD_HANDLE is not specified.

Do Not Call Duration

The Do Not Call Duration functionality enables you to set an expiration date for a DNC request. On the date of expiration, OCS removes or ignores the DNC entry.

Configuration

To configure DNC Duration, you must first manually add the expires_at field to the Do Not Call table.

Enter the Database Definition Language (DDL) statement that applies to your database type:

  • PostgreSQL
ALTER TABLE <dnc_table_name> ADD COLUMN expires_at integer NULL
  • MS SQL
ALTER TABLE <dnc_table_name> ADD expires_at int NULL
  • Oracle
 ALTER TABLE <dnc_table_name> ADD expires_at int NULL

This field will store the expiration time in POSIX format (seconds since midnight of 01/01/1970). A value of 0 or NULL means the DNC entry never expires.

Next, configure the following options:

  • dnc-use-duration - Used to enable DNC Duration. If the value is set to false, there is no change in the way OCS treats a DNC entry. If the value is set to true, OCS stores the expires_at value found in the Do Not Call table and later retrieves the value to determine if a given DNC entry (for new dials only) is active (not expired) or expired.
  • dnc-default-duration - Used when the GSW_DURATION attribute is not specified in a DNC request that has a value specified in the GSW_RECORD_HANDLE attribute.
  • dnc-purge - Used to remove expired DNC entries. The purge occurs after OCS reads the DNC table after restart or after OCS re-reads the DNC table in accordance with the dnc-reread option.

Finally, add the GSW_DURATION attribute to the Desktop communication protocol (for both transports, T-Events and HTTP). This attribute represents the DNC duration, in seconds. OCS adds this value to the current time to calculate the expiration date, which it then stores in the Do Not Call table.

Handling Requests

The following scenarios describe the process OCS uses to handle DNC duration requests.

Scenario 1:

  • GSW_DURATION is not specified.
  • GSW_RECORD_HANDLE is not specified.
  • Resolution: OCS applies a value of 0. It does not refer to the dnc-default-duration option, regardless of the settings.

Scenario 2:

  • GSW_DURATION is not specified.
  • GSW_RECORD_HANDLE is specified.
  • Resolution: OCS retrieves the DNC duration from the dnc-default-duration option.

Scenario 3:

  • GSW_DURATION is specified.
  • dnc-default-duration is specified.
  • Resolution: OCS uses the GSW_DURATION value.


Handling Multiple Requests

If OCS receives multiple DNC requests for the same customer, and all of those requests have different expiration dates, it applies the later expiration date.

For example, if one DNC request for a given customer specifies an expiration date of January 1, 2018 and another DNC request for that same customer specifies an expiration date of March 1, 2018, OCS recognizes March 1, 2018 as the expiration date.

Feedback

Comment on this article:

blog comments powered by Disqus
This page was last modified on 16 October 2017, at 12:32.