Dependencies and Integration Points

This chapter covers the following topics:

Architecture

This topic group provides information on the servers that comprise Oracle Advanced Outbound Telephony, its other components, how they are configured to work together, how they integrate with Oracle Marketing, the minimum software and hardware requirements, and sizing parameters for Oracle Advanced Outbound Telephony.

This topic group covers the following topics:

Oracle Advanced Outbound Telephony Physical Architecture

The Oracle Advanced Outbound Telephony product consists of three main components:

  1. Schema - Oracle Advanced Outbound Telephony has schema objects (primarily tables and views), PL/SQL packages. The Oracle Advanced Outbound Telephony schema stores:

    • Customer records for Advance Outbound campaigns

    • Call history

    • Recycling algorithms

    • Record filters

    • Subset information

  2. Administration GUIs - Oracle Advanced Outbound Telephony has a set of administration user interfaces to perform the following tasks:

    • Campaign call center parameter setup

    • Campaign Activity call center parameter setup

    • Subset creation and maintenance

    • Record Filter creation and maintenance

    • Recycling creation and maintenance

    • Real time reporting

  3. Java servers - Oracle Advanced Outbound Telephony has two Java server processes:

Oracle Advanced Outbound Telephony Architecture Diagram

The following diagram shows the Oracle Advanced Outbound Telephony components in the context of a complete system. Components which are actually part of the Oracle Advanced Outbound Telephony product are highlighted in gray.

the picture is described in the document text

Numbered areas on the physical architecture diagram are explained below.

  1. The Oracle Advanced Outbound Telephony administration GUI is on the HTML stack. It uses the Advanced Outbound Administrator responsibility and it is part of the Oracle Advanced Outbound Telephony product.

  2. To implement and administer other dependent components, other screens in both the HTML and Forms interfaces will be required. Examples of responsibilities used in Forms are ‘Telesales Administrator' and ‘CRM Administrator.'

  3. Much of the Oracle Advanced Outbound Telephony functionality and integration happens through database schemas. There is an Oracle Advanced Outbound Telephony schema present in the Apps Instance and it is part of the Oracle Advanced Outbound Telephony product. Oracle Advanced Outbound Telephony is directly dependent on the schemas of the following:

    • Oracle Marketing (AMS) - Oracle Marketing

    • TCA (HZ) - Trading Community Architecture

    • JTA - Oracle Foundation

    • JTT - Oracle Foundation

    • IEO - Server schema and Logger

  4. The Oracle Advanced Outbound Telephony Dial Server removes records from the database and returns these records through the return queue. This process is described in more detail in the Oracle Advanced Outbound Telephony Dial Server topic.

  5. The agent desktop applications, such as UWQ, Telesales, and Collections, are primarily Forms applications. All desktop applications integrate to Oracle Advanced Outbound Telephony through UWQ.

  6. Oracle Advanced Outbound Telephony integrates into UWQ through the Media Provider interface. An Advanced Outbound Telephony plugin exists in UWQ and is considered part of the Oracle Advanced Outbound Telephony product.

  7. The Oracle Advanced Outbound Telephony Dial Server uses the Telephony Adapter Server for CTI control.

  8. The Oracle Advanced Outbound Telephony Central Server is a lightweight server which does time zone and calendar management. Notice from the diagram that the two Oracle Advanced Outbound Telephony servers do not communicate directly. The Oracle Advanced Outbound Telephony Central Server is part of the Oracle Advanced Outbound Telephony product.

Oracle Advanced Outbound Telephony Servers

This topic group discusses the responsibilities and architecture of the Oracle Advanced Outbound Telephony servers in greater detail, including:

The Oracle Advanced Outbound Telephony Central Server

The Oracle Advanced Outbound Telephony Dial Server

The Oracle Advanced Outbound Telephony Central Server

The Oracle Advanced Outbound Telephony Central Server is responsible for invoking the operations of Oracle Advanced Outbound Telephony that take place in the database. The Central Server does the following things:

The Central Server has the following design characteristics:

The Central Server uses the Oracle Interaction Center Server Manager (ICSM) interface for configuration, for more information on ICSM please refer to the Oracle Interaction Center Server Manager. A Central Server, as its name implies, exists once per instance. One Central Server performs all of the above tasks for all active campaign activities and lists.

The following diagram depicts the Oracle Advanced Outbound Telephony Central Server, its responsibilities and it's relation to the database:

the picture is described in the document text

The above diagram depicts the CRM instance and the Oracle Advanced Outbound Telephony Central Server. The Advanced Outbound Telephony Central Server is responsible for invoking the following procedures or "tasks":

These procedures or "tasks" are plugins and exist as stored procedures in the schema on the CRM instance.

The Oracle Advanced Outbound Telephony Dial Server

The Oracle Advanced Outbound Telephony Dial Server is responsible for the following functional areas:

The following diagram depicts the Oracle Advanced Outbound Telephony Dial Server, its responsibilities and it's relation to the database:

the picture is described in the document text

Unlike the Central Server, which resides alone in its own server group, Dial Servers belong to server groups in a similar manner to the other Interaction Center servers. For scalability purposes, multiple Dial Servers can be added to a single server group. Each Dial Server can support a large call center. When multiple Dial Servers are used, the Oracle Advanced Outbound Telephony UWQ Media Provider Plugin will automatically choose between them based on availability and load.

The following diagram provides a simple example layout of the Oracle Advanced Outbound Telephony servers, and illustrates the concept behind using server groups to set up distributed call centers:

the picture is described in the document text

The above diagram shows two interaction centers: one data center and one call center. The data center, which is located in Chicago, houses the CRM database instance and the Oracle Advanced Outbound Telephony Central Server. The call center, which is located in San Diego and has 200 agents, houses 1 instance of the Oracle Advanced Outbound Telephony Dial Server (SanDiegoAdvanced Outbound TelephonyDS). In this example, the call center in San Diego uses a Nortel Meridian PBX.

The following diagram provides a complex example layout of the Oracle Advanced Outbound Telephony servers, and illustrates the concept behind using server groups to set up distributed call centers:

the picture is described in the document text

The above diagram shows three interaction centers: one data center, two call centers, an agent work area, and a marketing center. The data center, which is located in Chicago, houses the CRM database instance and the Oracle Advanced Outbound Telephony Central Server. Call Center 1, which is located in San Diego and has 200 agents, houses 1 instance of the Oracle Advanced Outbound Telephony Dial Server (SanDiegoAdvanced Outbound TelephonyDS). Call center 2, which is located in Norfolk and has 1000 agents, utilizes 2 instances of the Oracle Advanced Outbound Telephony Dial Server (NorfolkAdvanced Outbound TelephonyDS1 and NorfolkAdvanced Outbound TelephonyDS2). In this example, call center 1 in San Diego uses a Nortel Meridian PBX and call center 2 in Norfolk uses a Lucent PBX. The agent work area utilizes the Oracle Universal Work Queue GUI and a business application, such as Oracle TeleSales.

The middleware setup, which defines the Telephony Adapter server and the CTI server, determines which Telephony Adapter server will be pointed to.

Oracle Marketing Integration

Oracle Advanced Outbound Telephony is tightly integrated with and dependent on Oracle Marketing (Oracle Marketing). As such, Oracle Marketing is a prerequisite for Oracle Advanced Outbound Telephony. Integration with Oracle Marketing deals primarily with sharing schema objects such as:

List Integration

Campaign Activities

List Entries

List Integration

List integration with Oracle Marketing is based around a shared state model. In some states (or statuses), Oracle Marketing owns a list and its state transitions. In some states, Oracle Advanced Outbound Telephony owns the list and its state transitions.

The following diagram shows the state transition model for lists (the list states and transitions shown in shaded area are owned by Oracle Advanced Outbound Telephony):

the picture is described in the document text

The above diagram depicts the various list state transitions. Only the validating and executing list states are owned by Oracle Advanced Outbound Telephony.

The list state begins as "locked", where it can be cancelled/closed or begin the validating process. If it is cancelled/closed, it will be archived. If it begins the validating process, it will be validated, and begin the executing process (all within Oracle Advanced Outbound Telephony). Once the execution process has completed, it will be set back to "locked".

Definitions of these states, as well as the key transition states, are as follows:

Records will only be released from lists which are in the executing state, and also have active activities.

Campaign Activities

Similar to lists, the sharing of campaign activities is based around a state model. However, the campaign activity integration is simpler.

The following conditions must be true for Oracle Advanced Outbound Telephony to use a campaign activity from Oracle Marketing (and display it in the IEC Admin GUI):

The following additional conditions must be true for Oracle Advanced Outbound Telephony to release records from lists within a campaign activity:

List Entries

Similar to lists, the sharing of campaign activities is based around a state model. However, the campaign activity integration is simpler.

The following conditions must be true for Oracle Advanced Outbound Telephony to use a campaign activity from Oracle Marketing (and display it in the IEC Admin GUI):

The following additional conditions must be true for Oracle Advanced Outbound Telephony to release records from lists within a campaign activity:

Responsibilities

The following table shows the responsibilities needed for implementing, administering, and using Oracle Advanced Outbound Telephony use:

Responsibility Name Who Uses it Responsibility Description
Call Center HTML Administration Oracle Advanced Outbound Telephony Administrators Manage multiple aspects of interaction center, including: ICSM, and UWQ Media Actions.
Audience SuperUser and Campaign WorkBench SuperUser Oracle Advanced Outbound Telephony Administrators Manage Oracle Marketing operations.
Sales Online Super User Oracle Advanced Outbound Telephony Administrators Associate agents or resource groups to campaign activities.
Advanced Outbound Administrator Oracle Advanced Outbound Telephony Administrators Manage Oracle Advanced Outbound Telephony operations.
Advanced Outbound Performance Monitor Oracle Advanced Outbound Telephony Administrators Monitor Call Center Performance.
Interaction History JSP Admin Oracle Advanced Outbound Telephony Administrators Create outcome, result, and reason codes, and their pairings.
Oracle Marketing Administrator Oracle Advanced Outbound Telephony Administrators Create custom target group priority levels.
TeleSales Agent Oracle Advanced Outbound Telephony Agents Allows agent level access to Oracle TeleSales.
Collections Agent Oracle Advanced Outbound Telephony Agents Allows agent level access to Oracle AdvancedCollections.

Related Topics:

Concepts

Appending Campaign Activities

Oracle Advanced Outbound Telephony allows you to append new records to an existing campaign activity by creating a new campaign activity and appending it to an existing campaign activity. This process allows you to dynamically add new records to a campaign activity, or, in other words, add records to a campaign activity while records from that campaign activity are being dialed.

While the copy process overwrites all records with PARTY_IDs that already appear in the destination campaign activity, the call history for the records is maintained. This process prevents the duplication of records in the destination campaign activity once the append process has been completed. Also, by overwriting the information for the record in the destination campaign activity, the move process ensures the record is not marked as Do Not Use.

To successfully perform the append campaign activity process, a destination campaign activity must be present and you must have already created the new campaign activity containing the list information you want to append to the destination campaign activity. The campaign activity must be validated at least once. As well, the status for both the source and the destination campaign activities must be either "Locked" or "Executing", and the campaign activities must be Call Center Ready.

Area Code Mapping

Also known as Region Mapping.

An area code is a telephone numbering plan within a country that allows subscribers to make and receive telephone calls across long distances, such as the 3 digit area code used in US and Canada.

Area Code Mapping provides a way for Oracle Advanced Outbound Telephony to find the country to associate a phone number with.

The Trading Community Architecture (TCA) seeds area code mappings for the US (United States) and CA (Canada). However, if you are processing campaign activities containing numbers in other countries (whose phone country code does not map uniquely to a territory code), you will need to create the area code mappings for those countries. If your campaign activity contains numbers in only one country, you can create rules defining the area code for the entire campaign activity, and do not need to create these mappings. Additionally, these mappings are used to associate regions (states/provinces) with area codes so that regions can be associated with contact points and used in applying Region Calendars to determine when contact points can be called.

Calling Calendars

A calling calendar defines a set of callable times. Calendars can be associated to geographic locations (countries or regions) or marketing objects (campaign activities). Oracle Advanced Outbound Telephony utilizes three types of calendars:

Country Calendar (Mandatory)

A country calendar consists of a baseline callable time range for all seven days of the week, as well as any exceptions. Exceptions are most commonly used for holidays, and may be specified by specific date or by pattern (for example, third Friday of each month).

Country calendars MUST be defined, otherwise the records in the campaign activity will not be called.

Country calendars are expected to be created based on country-specific laws and are required for Oracle Advanced Outbound Telephony. There may be cases where it is acceptable to call contact points outside of the range of these laws, user defined calendars allow you to do this.

Every list entry has one to many contact points. Every contact point (telephone number) must have an associated country code and time zone. Every country code must have an associated calendar. This association creates the base set of callable times for every list entry. Oracle Advanced Outbound Telephony ships with country codes for many countries; however, additional country codes can be created and added to the base product as necessary to meet your business needs.

Region Calendar (Optional)

Region calendars can be used to solve the problem of when certain regions further restrict the callable times from the country they are in. For example, the United States sets the callable time parameters at 9am through 9pm; however, certain states further restrict those hours. These restrictions necessitate the creation of a regional calendar to address the more limited callable hours.

If there are conflicts between the regional calendar and the corresponding country calendar, the country calendar prevails (except when you select Yes from the drop-down list in the Override Country Calendar field).

User Defined Calendar (Optional)

User defined calendars are optional calendars which can be associated with campaign activities. These calendars are used to supplement information in the country calendar. If there are conflicts between the user defined calendar and the corresponding country calendar, the country calendar prevails (except when you select Yes from the drop-down list in the Override Country Calendar field).

For example, the default calling time in the country calendar you are using is 9AM to 9PM; however, you are only calling businesses and you know that nobody will be present after 6PM. You can create a user defined calendar that adjusts the call time accordingly.

Calendar Example:

Oracle Advanced Outbound Telephony ships with a default U.S. calendar. It contains the following baseline callable ranges:

Sunday 10AM-8PM

Monday 9AM-9PM

Tuesday 9AM-9PM

Wednesday 9AM-9PM

Thursday 9AM-9PM

Friday 9AM-9PM

Saturday 9AM-8PM

In addition, it contains restricted calling hours for the standard U.S holidays. Note that the callable times are always specified in terms of the local time zone; no time zone specification is necessary. If you wish to prevent calling on a specific target group from 6PM to 8PM on a specific date (for example, Monday, June 4, 2001), you can create an user defined calendar with the following exception information:

06-04-2001 6PM-8PM: no calling

and apply it to the target group.

Campaigns

A campaign is the organizational unit of a focused marketing effort. Campaigns define the marketing effort. One marketing campaign can have multiple campaign activities associated with it and each of these campaign activities can be targeted for different execution channels. For example, a marketing campaign might have a campaign activity associated with it that is targeted for e-mail execution, and another associated with it that is targeted for telephony execution.

Campaign Activities

Campaign activities are specified within Oracle Marketing (by a user with the Oracle Marketing Campaign WorkBench SuperUser responsibility).

Campaign activities support multiple channels of execution within a marketing campaign. A campaign activity is the highest-level object associated with Oracle Advanced Outbound Telephony. Target groups are associated to campaign activities, as are agents. A campaign activity has a start date and an end date. Multiple campaign activities can be associated to one marketing campaign, where the campaign activity is managed as a different execution channel.

The release strategy is executed at the campaign activity level. When the campaign activity is created in Oracle Marketing, the interaction center administrator designated for campaign activity approval (via the Marketing Medium specification) will receive notification. The administrator must approve the campaign activity before it can be executed. This approval process takes place in the Interaction Center Administrators's Personal Homepage, where the workflow item must be approved.

Note: The configuration of campaign activities takes place both within Oracle Marketing and within the Oracle Advanced Outbound Telephony administration application.

Oracle Advanced Outbound Telephony only deals with the target groups targeted for outbound telephony execution. In order for Oracle Advanced Outbound Telephony to be able to use a campaign activity from Oracle Marketing, the following conditions must be met in Oracle Marketing:

Dialing Methods

A dialing method is the mode by which the system dials the customer telephone numbers as it passes the records to the agents. Automated dialing enhances productivity and list penetration because it dials the customer telephone numbers with a reduced chance for error.

Each campaign activity can have a different dialing method. Oracle Advanced Outbound Telephony allows you to set up different campaign activities and lists with different dialing methods. Within a single campaign activity, different lists can also have different dialing methods. While dialing methods can be set at both the campaign activity and list level, lists are set by default to use the dialing method of the parent campaign activity. However, this default can be overridden at any time.

Oracle Advanced Outbound Telephony supports the following dialing methods:

Do Not Call (DNC)

Also known as a "Stop List".

In compliance with the Telephone Consumer Protection Act (TCPA), at the request of the call recipient, calls can be blocked so that they will not be dialed by Oracle Advanced Outbound Telephony or any other application.

Oracle Advanced Outbound Telephony manages 'Do Not Call' records through Oracle's Trading Community Architecture (TCA). The architecture provides a fully coordinated effort across the e-Business application suite for controlling contact restrictions for all contact media (Email, phone, postal mail etc.). The architecture specifies contact control based on execution channel (telephony, Email, etc.), time periods for applying the restriction(s), and purpose (telemarketing, collections, etc.) for a phone number.

Before any record is eligible for calling, at runtime Oracle Advanced Outbound Telephony will validate the record against TCA for any real-time updates where the channel equals "phone," or "all;" thus, facilitating compliance with the federal Telephone Consumer Protection Act (TCPA) legislation.

The first filtering effort should be made within Oracle Marketing through the creation of a suppression list. Before list generation, a suppression list should be defined which identifies if list entries have been flagged within TCA not to be called.

Oracle TeleSales is used to add numbers to the Do Not Call list. Please refer to the Oracle TeleSales documentation for more information on requesting numbers be added to the Do Not Call list.

Importing Lists

The importing of target groups from various sources is an important part of using Oracle Advanced Outbound Telephony. Target groups may be sourced internally, from the Trading Community Architecture database (TCA) or externally either through target group import or by use of Oracle Discoverer. Interaction centers and marketing organizations frequently purchase lists of contacts. This functionality is entirely owned by Oracle Marketing.

Oracle Marketing also allows for the regeneration of existing lists.

List Entries

A list entry is one row in a list. It is occasionally called a record. Currently, each list entry is associated with one party and has one to many contact points. The fields on each list entry are always the same within one list. They are determined by the list source type, which is associated with the list header.

List entries a re created when Oracle Marketing generates a list. They contain all necessary denormalized data from other areas of the database with the exception of Do Not Call information.

Oracle Advanced Outbound Telephony uses the list entry as the primary, permanent storage area for the record.

List Generation

When you generate a list, customer records satisfying the list conditions are populated in the list. A list can only be generated after all the conditions have been specified. The amount of time it takes to generate a list depends on several factors such as the size of the database and the system environment condition at the time a list is being generated.

List Generation Types

There are three Generation Type options:

Lists

A list is a data structure containing information about one or more customer records. A list does not reproduce the customer database; each record in the list points back to a real customer account in one of your customer databases. More specifically, each record in the list only reflects the subset of fields needed for a screen pop and to meet the list segmentation criteria.

The purpose of a list is to identify a particular segment of customer records. Once a segment has been identified, an administrator can control the conditions under which the records are called.

The term ‘list' is also used to mean a specific group of list entries. As mentioned above, lists can be used with Oracle Advanced Outbound Telephony by associating them with the correct type of campaign activity. Lists are owned by Oracle Marketing and are used for many purposes within marketing aside from outbound dialing.

Although different aspects of list headers are configurable from different GUI screens in Oracle Advanced Outbound Telephony, the list header structures are the same.

List Regeneration

Oracle Marketing has the ability regenerate the target groups (e.g. Oracle Advanced Outbound Telephony calling list) with new data. Calling record updates may also include new or changed phone numbers, in which case Oracle Advanced Outbound Telephony must revalidate the data. The list regeneration process will not disturb any call history information of records that have already been called.

Campaign activities (e.g. target groups/calling lists) may have execution duration of weeks where the calling record may become outdated. If the updated information has an impact on record release control or has different phone numbers, then call center administrators need the ability to insert/delete/update records to a calling list.

An example may be a collections campaign effort where delinquency time and amount may change since the creation of the calling list. Different strategies or priority are used based on this information. The list may be segmented based on amount of duration of delinquency (e.g. 30, 60 or 90 days) where the highest priority may be given to records that are the most overdue and/or above a threshold amount. By regenerating the list, the record will be categorized appropriate for dialing.

List regeneration options offered by Oracle Marketing that Oracle Advanced Outbound Telephony can handle include:

List Source Types

Also referred to as Data Sources. A list source type is a concept used by Oracle Marketing to define how fields from the database (typically TCA) map to the columns of a target group entry. A target group entry has several hundred generic columns; a specific list source type, for example, could state that the phone number will go into column 1 and the name will go into column 2. However, a different list source type could populate the first column with name and the second column with phone number.

Oracle Advanced Outbound Telephony recycling algorithms and record filters are directly associated to source types because they define which fields are present in a target group.

Oracle Marketing ships with two default list source types:

Caution: While Oracle Marketing allows you to modify the source type fields, you MUST NOT remove or modify the following fields: Per Customer - Oracle Advanced Outbound Telephony requires these fields for each customer. They are either used in the screen pop, or to check for DNC, release control, or the stop list.

Note: Per Phone Number - Oracle Advanced Outbound Telephony requires these fields for each phone number.

Outcome, Result, Reason Codes, and Wrapups

Customer Interaction History provides a three-tiered hierarchical means of recording the conclusion of an interaction: OUTCOME, RESULT and REASON. During the interaction wrap up process, contact center agents may conclude an interaction or activity by assigning one, two or all three of the conclusion descriptors. Outcome, result, and reason codes specify what happened on a dial attempt to contact a customer. These codes are seeded, but are also user-extensible.

A wrapup relates outcomes to results and reasons. You can limit the availability of a wrapup to a specific campaign type or code. When the wrapup is selected for an interaction, the outcome, result, and reason in the wrapup definition are assigned to the interaction.

Outcome, results and reasons codes should always be enforced as a hierarchy. That is, the user must always select an outcome before you can select a result and they must select a result before they can select a reason.

If an outcome has no results associated with it, then the user should not be allowed to select a result for that outcome. Also, if an outcome/result combination has no reasons associated with it, then the user should not be allowed to select a reason for that outcome/result combination.

If the outcome selected is designated as requiring a result, then the user must select a result. If only one valid result is set-up for the outcome, then that value should be defaulted for the user. If the result selected is designated as requiring a reason, then the user must select a reason. If only one valid reason is set-up for the result, then that value should be defaulted for the user.

Examples

Outcome Selected = "No Answer" or "Busy"

Outcome selected = "Contact"

Outcome selected = "Contact", Result selected = "No Sale"

Outcome selected = "Contact", result selected = "Sale"

Call Outcome

An outcome describes the outcome of a customer interaction (for example, making contact with the customer or reaching an answering machine). An outcome can be assigned manually by the agent or automatically by the application.

You can required the assignment of a result when a particular outcome is assigned to an interaction. In addition, the assignment of an outcome can generate a callback so that an agent calls the customer back at another time.

'Outcome' reflects network connectivity (e.g. connect, busy, ring-no-answer, SIT, etc.); a list of system defined outcome codes are defined within Oracle Advanced Outbound Telephony, others may be user defined.

OUTCOME_ID OUTCOME_CODE SHORT_DESCRIPTION
1 No Ans No Answer
2 Busy Busy
3 Wrong Num Wrong Number
4 Not Avail Not Available
5 Bad Pnum Bad Phone Number
6 Ans Mach Answering Machine
7 Contact Contact
8 Decease Decease
9 Maint Maintenance
10 Req Proc Request Processed
11 Bypass Bypass
12 Change Number Change Number
13 Delete Delete
14 Facsimile Tone Facsimile Tone
15 Incoming Incoming
16 Invalid for Calling Invalid for Calling
17 Modem Answer Tone Modem Answer Tone
18 Not Set Yet Not Set Yet
19 Priority Callback Priority Callback
20 Requeued Requeued
21 Withdrawn During Network Time Withdrawn During Network Time
22 Withdrawn During Ringing Withdrawn During Ringing
23 FHM Hangup FHM Hangup
24 FHM Customer Hangup FHM Customer Hangup
25 Flunked Stoplist Flunked Stoplist
26 Unknown Unknown
27 Dialer Error Dialer Error
28 Discarded Discarded
29 No ringback No ringback
30 No dial tone No dial tone
31 Advanced Outbound Telephony system Advanced Outbound Telephony system
32 Failed release control Failed release control

Call Result

A result describes the consequence of an outcome. Examples of 'Results' could include: "Sale" or "No Sale" or "Wrong Party Contact".

Using a wrap up, you can relate an outcome to one or more results (for example, a outcome of "contact" with a result of "no sale"). Also, you can require the assignment of a reason when a particular result is assigned to an interaction.

RESULT_ID RESULT_CODE SHORT_DESCRIPTION
1 NoSale No Sale
2 Sale Sale
3 Compl Customer Complaint
4 Cb Call Back
5 Multi Act Multiple Activities
6 Completed Completed Activity
7 Incompleted Incompleted Activity
8 Sent Message Sent
9 Not Sent Message Not Sent
  Failed validation The record failed to be validated
11 Cache expiration The record expired in the cache

Call Reason

A reason provides an explanation for the result. 'Reason' codes are optional user/application defined. It is used to further detail the 'Result' of the call, such as "Too Expensive" or "Using Competitor's Product" or "No Interest"

Using a wrap up, you can relate a result to one or more reasons (for example, a contact outcome with a result of "no sale" and a reason of "no money").

REASON_ID REASON_CODE SHORT_DESCRIPTION
1 No Money No Money
2 Already Gave Already Gave
3 Expense Too Expensive
4 No Work Out of Work
5 Gave Office Gave at the Office
6 Other Other Reason
7 Busy Too Busy
8 SP Handl Req Special Handling Required

These codes are owned and administered by Oracle Customer Interaction History. Oracle Advanced Outbound Telephony references these codes in its recycling algorithms and record filters.

Phone Formats

Phone formats must be created for each country that you will be calling in your lists. Oracle Advanced Outbound Telephony ships with the phone formats for the United States and Canada. Additional phone formats can be created by logging into the Oracle Forms Application with the Trading Community Manager responsibility.

Record Release Control

Oracle Advanced Outbound Telephony provides the following means of controlling record release:

Record Filter

A Record Filter is a set of rules against which the records are checked at the point of release to filter out unwanted dials. Record filters check release fields to ensure they match defined parameters (STATE equal to Virginia). A match here will prevent the release of the record.

The record filter process occurs after a record is selected and provides a last minute means to filter records from being called. If a record does not pass the release checkpoint process, the record will be recycled according to the rules defined for recycling processing.

The release criterion should be defined in an SQL statement where any field(s) available in AMS_LIST_ENTRIES table may be used as a criterion.

Record filters utilize expressions in a similar manner as recycling algorithms. However, instead of being called conditions, they are called rules. They use the following three components:

Record filter rules are structured in the following order: field operator value. For example: PERSON_FIRST_NAME equal to James (where PERSON_FIRST_NAME is the field, equal to is the operator, and James is the value). The combination of these three elements (field, operator, and value) is called an expression.

The Oracle Advanced Outbound Telephony HTML Administration console displays rules in an alphanumeric hierarchy.

Example:

In the above example, the lines under each rule are conditions for that rule.You can have multiple expressions in a single condition (as seen under Rule 2) and you can have multiple conditions under a single rule (as seen in Rule 1). If you want to have more than one expression in a condition, or more than one condition in a rule, it is very important how the they are joined together (by AND or by OR).

Separate top level rules are only joined together by OR; however multiple expressions within a single condition, and multiple sub-conditions within a single rule can be joined by either AND or OR.

If you want to have multiple top level rules in your record filter, their order is very important. Once a rule is met, Oracle Advanced Outbound Telephony ignores all other rules at the same level and only completes execution for the process within that set of rules. In the above example, if Rule 1 is met, then Rule 2 and Rule 3 are ignored.

Release Priority

Release priorities determine the relative priority of a subset in comparison to other subsets. Oracle Advanced Outbound Telephony utilizes the AMS_list_priority lookup code for release priority.

Every subset has a release priority. Priorities allow Oracle Advanced Outbound Telephony to distinguish between “high” priority subsets and “low” priority subsets. The priority selections Oracle Advanced Outbound Telephony supports are:

Highest through Medium level priorities are preemptive; all subsets with priorities in this range will be exhausted in priority sequence before the next priority level is used. Low and Lowest priorities are used in round-robin fashion; each of these subsets will release its quantum of records, then the next subset in the same priority level will be used.

Oracle often recommends that time-based subsets (for example, the Busy and Priority Callback subsets) have higher priorities, and that all other subsets have lower priorities. This insures that records that need to be called back at specific dates and times are called before those that have no assigned callback dates and times. When Oracle Advanced Outbound Telephony sees that no records are available in the time-based subsets (because they are scheduled for future callback), then it automatically begins the round-robin process among subsets with lower priorities.

Release Strategy

Release strategy is a broad concept which describes how Oracle Advanced Outbound Telephony releases records from lists and subsets. Oracle Advanced Outbound Telephony supports the following types of release strategies:

An additional factor affecting release strategy is priority. Both lists and subsets have priorities which influence release strategy.

Distribution Strategy

When using the distribution release strategy, Oracle Advanced Outbound Telephony pulls an indicated ratio of records from each campaign activity at the same priority level over time. The distribution strategy utilizes distribution priority level and an indicated ratio number (weight), both of which are set in the Oracle Advanced Outbound Telephony HTML Administration console.

Example: You have campaign activities A and B. Both are set at a distribution priority of "High." Activity A is set to a distribution weight of 10 and Activity B is set to a distribution weight of 20. Over time, a ratio of 10 records will be released from Activity A and 20 will be released from Activity B.

Quantum Release Strategy

The quantum release strategy supports proportional calling across all lists and subsets associated with the campaign strategy and it is considered the baseline strategy for an Oracle Advanced Outbound Telephony service.

The quantum release strategy controls the number of records that can be sequentially dispersed from a subset. This means that when Oracle Advanced Outbound Telephony is distributing customer records to agents, it releases a quantum number of records from each subset before it goes on to the next subset in the campaign.

Every subset has a quantum which you can dynamically adjust via Oracle Advanced Outbound Telephony. Usually, a subset's quantum is adjusted to reflect the proportion of customer records in that subset compared to other subsets in the campaign.

Without the concept of a quantum, Oracle Advanced Outbound Telephony would read all records from one subset before moving on to another subset. This would exhaust each subset in order. While a strategy of this sort may be useful in some instances (for instances, in a Collections application, where you want all of the 60-day overdue customers called before the 30-day customers), you generally want a mix of records from different subsets.

Quota Release Strategy

The Quota Release Strategy stops releasing records from a list or subset when a pre-defined limit has been reached.

This strategy disburses records from a list or subset based on the quota that is assigned to a list or subset. A quota represents the maximum number of records with a certain outcome or result that should be obtained from that list or subset during a pre-defined period of time (set by a Quota Reset Period value).

Quotas are reset at the end of a quota reset period (defined at the list or subset level), so that the list or subset is again available for calling. The raw values used to calculate the quota are dependent upon the outcome codes of each record and must be passed by the agent business applications to Oracle Advanced Outbound Telephony.

Recycling Records

Recycling is the process of determining how to process records that have been dialed. When a record is returned, a user-definable recycling algorithm is executed, which looks at the record, the call outcomes, the call results, and previous calls to the record.

For example, if a call ends up with a status of “Busy,” you can assume that it's likely that the decision maker is at home; therefore, you will probably want to call the customer back within a few minutes. Oracle Advanced Outbound Telephony can automatically schedule a record with a busy outcome to be attempted in 10 minutes. On the next attempt, if the line is still busy, Oracle Advanced Outbound Telephony can call back the customer in another 15 minutes.

Likewise, if there is a “No Answer” in the morning, Oracle Advanced Outbound Telephony may schedule the next call to be attempted during the afternoon of the same day.

Call recycling also occurs for target groups that have contact outcomes. For instance, some applications automatically schedule callbacks after a call has resulted in a literature request. The application may schedule a callback for five days in the future, giving the customer time to receive and review the mailing. After the five days have passed, Oracle Advanced Outbound Telephony automatically calls the customer back, allowing the agent to reinforce the information sent by mail and close the sale.

Benefits of Recycling

Recycling provides the following benefits:

Possible Actions for Recycling

Possible Conditional Check Commands

Condition Description
List field is This condition checks a field in the call record for a specific value.
Call attempt is This condition checks the number of call attempts made on this record.
Outcome of the nth previous call is This condition checks n consecutive previous call attempts for a specific outcome.
Outcome code is This condition checks value of the outcome code returned from the interaction.
Result code is This condition checks the value of the result code returned from the interaction.
Reason code is This condition checks the value of the reason code returned from the interaction.
Call attempt on current contact point is This condition checks the value of current call attempt to this contact point.
Consecutive outcome to current contact point is This condition checks the value of the outcome of current call attempt to a contact point against previous call attempts to the same contact point. This count will start at 1.
For example, if the current call attempt results in a Busy outcome and the previous two call attempts to the same contact point also resulted in outcomes of Busy, then the consecutive count would be 3.
The day of the week is... This condition allows you to recycle a record based on what day of the week it is or is not when the record is called.
The time of nth call is... This condition allows you to recycle a call based on what time of the day it was when a previous call attempt was made for this record. The specified number (n) stands for the number of calls ago. The number you specify for "n" must be within the last 20 calls. For example, if you have a calling plan that begins calling records on a Mon - Wed - Fri basis then switches to Tues - Thurs calling if no connects are achieved, you could use this algorithm to dictate when a record should shift from the Mon - Wed - Fri pattern to the Tues - Thurs pattern.
The time of nth previous call... This condition allows you to recycle a record based on the time within the called timezone that nth previous call was placed.
The time of the call This condition allows you to recycle a call based on the time that current call was placed.

Recycling Algorithms

The recycling algorithms you create determine how a record is recycled. Recycling algorithms are composed of conditions, sub-conditions, pre and post-processing actions, and actions to perform if no sub-conditions are met.

When creating a recycling algorithm, you must first decide whether you will use an existing algorithm as a model for your new one, or whether you want to create a completely new algorithm. If an existing algorithm contains relatively similar pre or post-processing actions, conditions or sub-conditions, you should use it as a basis for your new algorithm. The Oracle Advanced Outbound Telephony HTML Administration console allows you to do this by permitting you to copy existing algorithms. If your new algorithm will be significantly different from any existing ones, you should create a completely new algorithm.

You must then add or modify pre or post-processing actions (not required), or the conditions or sub-conditions for the algorithm. You then need to add an action for each condition or sub-condition. These actions will determine how the record is handled if the condition or sub-condition under which you add it is met.

Note: Each condition or sub-condition must have an associated action or you will receive an error.

Recycling Algorithm Conditions

Conditions determine how the algorithm processes records that have been dialed. Conditions are composed of three parts:

To avoid confusion, since the first component of the condition is also called a condition, we refer to the entire statement (condition, operator, and value) as an expression. Expressions are structured in the following order: condition operator value. For example: STATUS contains ACTIVE (where STATUS is the condition, contains is the operator, and ACTIVE is the value), or: HOUSEHOLD_SIZE greater than 3 (where HOUSEHOLD_SIZE is the condition, greater than is the operator, and 3 is the value).

The Oracle Advanced Outbound Telephony HTML Administration console displays conditions and their sub-conditions in a treeview model.

Example:

Condition 1

Condition 2

In the above example, Condition 1 and Condition 2 are top level conditions. If you want to have more than one expression in a single condition, it is very important how the expressions are joined (by AND or by OR).

If you want to have multiple top level conditions in your recycling algorithm, their order is very important. Once a condition is met, Oracle Advanced Outbound Telephony ignores all other conditions at the same level and only completes execution for the process within that condition block. In the above example, if Condition 1 is met, then Condition 2 (and Sub-condition 1 under Condition 2) will be ignored.

Recycling Algorithm Sub-Conditions

Sub-conditions allow you to further refine how each condition in your algorithm handles dialed records. For example, you could have the following condition statement:

For this condition statement you could add sub-conditions that further define how the condition processes dialed records. For example, you could add the following sub-conditions to the Outcome code equals No Answer condition:

By adding these sub-conditions, you can establish a different handling procedure for each calling attempt. Each of these sub-conditions will need an action added to it to determine how Oracle Advanced Outbound Telephony handles the call attempt if none of the sub-conditions are met.

Recycling Algorithm Pre and Post-Processing Actions

Recycling algorithms utilize pre and post-processing actions to determine what happens to records before and after (respectively) the conditions apply.

Pre and post-processing actions are pre-seeded statements. The pre and post-processing areas in the Oracle Advanced Outbound Telephony HTML Administration console allow you to access and utilize these pre-seeded statements. These statements allow you to do virtually anything you want before or after (respectively) the conditions of the recycling algorithm - check for any condition you want and then take action based on the checked conditions, or initialize or clear variables needed during the recycling process.

Recycling Algorithm Actions Performed if no Sub-Condition Are Met

Actions if no sub-conditions are met are pre-seeded actions that you can add to the root level, a condition, or a sub-condition that establish a method of handling the record in the event the top level conditions or sub-conditions under that top level condition are not met. If a condition or sub-condition is met, it's associated action will be utilized. However if no conditions or sub-conditions are met, none of their actions will be utilized; therefore, you must add an action if no sub-conditions are met to handle these occasions.

For example, if you had the following condition and sub-condition statement:

Condition 1: Outcome code equal to No Answer

To each of these sub-conditions you can add an action which will determine what happens to the record if no sub-condition are met. For the first call attempt, you could add an action of Call back next Monday. For the second attempt, you could add an action of Call back next Saturday at 11:30. For the third call attempt, you could add an action of Call back next week. By adding an action for each sub-condition, you can set up different processing paths for each separate call attempt.

Generating Reports

Call centers are dynamic environments; being armed with real-time information is critical in decisions such as managing list depletion/exhaustion and managing the productivity of the interaction center agents.

Oracle Advanced Outbound Telephony logs information to two areas: Oracle Customer Interaction History and Interaction Center Intelligence.

Information logged into Oracle Customer Interaction History contains only dial attempts made by Oracle Advanced Outbound Telephony that did not result in a call connect, therefore was not forwarded to an agent. The log entries in Oracle Customer Interaction History from Oracle Advanced Outbound Telephony help to build a complete picture of calling efforts. Calls that were completed and transfer to an agent application will have log entries from the agent application. The combination of log entries from both sources will provide a complete view of the calling effort and its results.

Information logged into Interaction Center Intelligence (ICI) is for the purpose of providing some real-time reports on the dialing efforts. Information feed to CCI is done on an interval basis, and reflects up-to-date information on the interaction center performance such as: break down of the types of calls made, break down of call outcomes, limited agent information in terms of number of agents, and break down of records left to be dial.

The report data is only maintained for a 24-hour period. The time at which the reports are cleared daily can be set at the Campaign Activity level. To set this time:

  1. Log into the HTML admin pages with the Advanced Outbound Administrator responsibility.

  2. Select the Campaign Activity whose Reset Time must be changed.

  3. On the Interaction Center Campaign Activity Details page, under the Interaction Center Parameters area, select the desired reset time from the hour and minute lists, and click Update.

    All times are now set and displayed in the user's local time. The UI calculates the conversion and stores/retrieves times from the database.

Oracle Advanced Outbound Telephony allows you to generate the following reports:

Report Name Report Description
Dialing Statistics Displays the details of calls placed for a campaign/activity. Provides you with an ability to evaluate the efficiencies of a campaign activity calling effort.
Campaign Call Results Detail Provides you with a view of the distribution of call results for a given campaign/activity that is currently active in the call center.
Campaign Record Detail Statistics Provides you with a detailed view of the distribution of records for one active campaign. Statistical data for the report reflects back to when the campaign has become active.
Campaign Record Summary Statistics Provides you with a quick glance view of the distribution of records for all campaigns that are currently active in the call center. Statistical data for the report reflects back to when the campaign activity has become active.
Campaign Agent Performance Statistics Provides you with a view of the distribution of call results among lists and subsets for a given campaign/activity that is currently active in the call center.
Campaign Performance Statistics Displays details of campaign activity performance with real-time records available/consumed and agents' activity for each campaign/activity.
Agent Call Results Detail Provides a view of the distribution of call results among the agents for a given campaign/activity that is currently active in the call center.
Campaign Time Zone Detail This report shows the number of callable records in each time zone served by the specified campaign/activity. The record count takes into account all callability rules (e.g. calendars) for the time zones displayed.
This report maintains up-to-date counts as long as the Advanced Outbound Telephony Central Server is running. The Reset Time has no effect on this report.

Server Groups

A server group is also known as an interaction center. Interaction center servers (e.g. UWQ, OTM) typically belong to a server group. An exception to this is the Oracle Advanced Outbound Telephony Central Server, which exists one per CRM instance. A server group typically represents the concept of a call center, but this is not required.

Agents are assigned to server groups using Oracle CRM Resource Manager. Servers are assigned to server groups using the Interaction Center Server Manager (ICSM) interface, which requires the Call Center HTML Administrator responsibility.

Subsets

A subset is a set of entries within a list identified by field values. Subsets are dynamic, and can be created and deleted at will within the context of a list.

When subsets are used, a default subset is created that contains any list entries not contained in the user-defined subsets. Any list entries that exist in two overlapping subsets will be placed in the subset that has the higher priority level.

For example, if you have one subset for people with last names beginning with "A" through "C" and another subset for people with incomes between $50,000 and $100,000, some names might appear in both subsets. Whichever subset has the higher priority of the two will be the subset in which the records are placed upon validation or when updating the campaign activity.

You create list subsets by designating conditions. When records meet the designated conditions they are placed in the list subset. Conditions are composed of three parts:

Conditions are structured in the following order: field operator field value.

Condition Structure Example

ADDRESS contains VA - where ADDRESS is the field, contains is the operator, and VA is the field value.

Subset Example

A call center administrator has a list containing a generated score in the field called ‘SCORE.' This contains values from 1 to 5. Additionally, a field called ‘STATE' of the score value, the administrator would like to create the following subsets:

The marketing campaign is expected to get much better results in New York, so an additional subset is created:

The default subset at this point contains list entries that match:

Each of these subsets can be given its own priority, quantum, or quota value. If the interaction center administrator decides that there may be a possible difference in results between the score value of three and four, they can create a new subset:

and edit the existing subset 2:

Subset Priority

In previous releases, a record could match the criteria for multiple subset definitions, thus making it difficult to determine what release criteria was used to release the record. Subset priority is a means of mediating record membership to one subset. Based on the order of the subset definition, the record matching the first subset definition will become a member of that subset, thus making the order of the subset definition important. Subset priority based on order will eliminate ambiguities as to which subset a record is a member.

For example, lets say you are selling season tickets for NFL football games. You have several subsets already, including: one for males, one for people between the ages of 25 and 35, and one for people with incomes over $100,000 per year. It is entirely possible for a call record to be a member of one or all of the above subsets. Since you will most likely receive better results from the over $100,000 subset, that is the subset you should execute upon first. You can use subset priority to prioritize the over $100,000 subset, and also to also pull multi-subset call records (where one of the subsets is the over $100,000 subset) into the over $100,000 subset only.

Time Zone Management

Oracle Advanced Outbound Telephony manages time zones transparently to the call center administrator. As mentioned earlier, this is dependent on every contact point (telephone number) having an associated country code and time zone value. All of these items are owned by TCA. All countries represented in a calling list must be mapped to a time zone.

Time Zone Mapping

If your data does not provide time zone information for your contact points, and you cannot use the validation rules to specify the time zone at the list level, then you will need to create time zone mappings in order to validate your lists.

There are three different types of time zone mappings.

Even if this type of mapping exists, postal codes cannot be used in determining the appropriate time zone unless a validation rule is created (and associated with desired list(s)) to enable such mapping lookups

In general, you should try to use the first type of mapping as it allows for the best validation performance and requires the least amount of effort to create. However, there are certain countries split among different time zones, and the second type of mapping is required to accurately determine the correct time zone. You should only create the third type of mapping when absolutely necessary as it leads to a large number of records in the time zone mapping table, reducing the performance of lookups.

Time Zone Mapping

Oracle Advanced Outbound Telephony contains time zone mapping tables that must be defined. Many countries only occupy a single time zone, but others are spread across multiple time zones. If your interaction center plans to make calls throughout countries (for example: United States or Canada) where many states and provinces fall in different time zones, you may need to provide the state/region postal codes and area codes to determine that Oracle Advanced Outbound Telephony is using the correct time zone for the customer. There are database load utilities readily available within the database that can be used to upload purchased data into the Oracle Advanced Outbound Telephony Schema.

To ensure that customers are called at the appropriate times, Oracle Advanced Outbound Telephony must know where the person resides in relation to time zones. This way Oracle Advanced Outbound Telephony can follow the appropriate telemarketing laws that govern calling in their particular country, state, country or city.

The time zone mapping form is used as an easy entry point to provide Oracle Advanced Outbound Telephony with a method to call customers or contacts.

At a minimum, the country code and time zone must be entered for each country that an interaction center will contact. It is mandatory that all countries map their time zone with their country name.

For single time zone countries, no further information is needed.

For countries with more than one time zone, it is recommended that you map the appropriate time zone, country code, and optional area code, postal code, state/region information to assist Oracle Advanced Outbound Telephony during list validation time. By utilizing the address specific information, Oracle Advanced Outbound Telephony can match a customer record with the appropriate time zone and country if their customer record is incomplete.

This functionality is especially important in countries where there are multiple time zones. For example, the United States has eight time zones spanning from Saipan, Northern Mariana Islands, U.S.A. (Standard time zone: UTC/GMT +10 hours where daylight saving time currently not observed) and Honolulu, Hawaii, U.S.A. (Standard time zone: UTC/GMT -10 hours where daylight saving time currently not observed). In addition, there are many states who have either multiple time zones and may or may not participate in daylight savings time.

For example: The state of Indiana has up to three different time zones depending on the location in the state. To ensure we call the customer at the correct time, we need to know exactly where the customer is and follow the laws for their state. In this case, Oracle Advanced Outbound Telephony may need to go down to the postal code to ensure that the correct time zone is being used for the customer record.

Note: Postal code mapping only utilizes the address for the contact party and may not necessarily reflect the location of the contact point (for example: phone number).

Trading Community Architecture

The Trading Community Architecture (TCA) is a customer model designed to support complex trading communities. TCA strives to model all relationships within a trading community. For example, the trading community of an appliance manufacturer may include suppliers, distributors, resellers, retailers, service providers, business consumers, and end users. The appliance manufacturer not only wishes to track relationships between itself and other entities within this trading community, it also takes an interest in relationships that other community members have with each other. The manufacturer may not even have direct relationships with all such members; nevertheless, it needs to know about them and how each relates to other entities within the community.

Validation History

Once you have run a validation report, a Validation History hyperlink appears on the side panel of the Validation Report page in the Oracle Advanced Outbound HTML Administration console. Clicking this link allows you to view a historical listing of every time validation has been run on the selected campaign activity.

Validation Report

A View Report column has been added to the summary view table of existing lists on the Interaction Center Campaign Activity Target Groups page. Clicking the View Report hyperlink provided in this column generates a report furnishing the following information:

Row/Column Name Description
Validation Status Shows whether or not the selected list is validated.
Number of Valid Records Shows the number of validated records within the selected list.
Number of Invalid Records Shows the number of records that failed validation within the selected list.
Reason for Invalidity Provides a reason why each Number of Records column entry failed validation.

Validation Rules

Validation rules are composed of actions and these rules allow you to make exceptions to the automatic list validation process. For example, you can use validation rules when you don't know the country code or time zone, but you know you will be dialing calls in a certain time zone. If the country code or time zone is not known these records will fail the list validation process and will not be dialed. You can set a validation rule to allow you to dial these records because you are confident of what is in the list. By doing this, you can prevent these calls from failing the list validation process, and thereby not being dialed.

Validation Rule Actions

Rule Action Description
Country is... This action allows you to specify the phone country code at the list level. The phone country code refers to the country code used when dialing a number. For example, the phone country code for US and Canada is 1. This rule is useful when every number in a list uses the same phone country code, and that phone country code is not specified in the phone country code attribute of the contact point. A complete list of valid phone country codes can be found in the HZ_PHONE_COUNTRY_CODES table.
Disable validation of area code lengths This pertains to non-standard number lengths (prevalent in some countries.) For example, if a phone number format has been created for the country you're validating, but does not pertain to your list, then you can use this action.
Disable validation of cell phone numbers This pertains to non-standard number lengths (prevalent in some countries.) For example, if a phone number format has been created for the country you're validating, but does not pertain to your list, then you can use this action.
Disable validation of phone number lengths This pertains to non-standard number lengths (prevalent in some countries.) For example, if a phone number format has been created for the country you're validating, but does not pertain to your list, then you can use this action.
Enable incremental parsing of area codes This rule allows you to enable incremental parsing of area codes from the phone number and raw phone number attributes. This allows validation to parse the area code from the phone number attribute, by iteratively comparing the area code digits to a list of valid area codes (in IEC_G_CC_AC_TC_MAPS) until the correct match is found. There must be entries for all of the potential area codes in IEC_G_CC_AC_TC_MAPS in order to successfully parse the area code. The US and CA area codes are provided.
Enable incremental parsing of phone country codes This rule allows you to enable incremental parsing of phone country codes from the raw phone number attributes. This allows validation to parse the phone country code from the raw phone number attribute, by iteratively comparing the phone country code digits to a list of valid phone country codes (in HZ_PHONE_COUNTRY_CODES) until the correct match is found. There must be entries for all of the potential phone country codes in HZ_PHONE_COUNTRY_CODES in order to successfully parse the phone country code. The data for most (if not all) countries is provided.
Enable use of zip codes in determining correct time zone using mappings This rule allows you to enable the use of postal codes while performing time zone mapping lookups. There are only a few cases when this data is necessary to determine the correct time zone, and this functionality will slow validation considerably.
Phone country code is... Use this when the phone country code is not in the database but you know which country code all the phone numbers are in.
Region is... This action allows you to specify the region (state/province) at the list level. Regions are stored in the JTF_LOC_AREAS_VL and are created/updated in Oracle Marketing (Administration/Marketing/Geography). Oracle Advanced Outbound Telephony only recognizes locations of type STATE as regions. This rule is only useful when every phone number in a list is within a single region and the region is not specified via an Area Code Mapping.
Require that a contact point have a region to pass validation This rule allows you to require that a contact point have a region to pass validation. This is recommended if the administrator only wants to call contact points for which a region calendar can be used to determine whether or not the contact point is callable.
Time zone code equals time zone... Use this when a non-standard timezone code is entered in the database. The list may have any string as its timezone code; use this to map the string to a time zone Oracle Advanced Outbound Telephony recognizes. You can use the "time zone" and "Update time zone" columns on the Target Group Entries page to accomodate any string that may be entered for the time zone.
Time zone is... This rule allows you to specify the time zone at the list level. This rule is useful if every contact point in the list belongs to the same time zone that is known by the administrator, and/or time zone data is not provided for the contact points. This option will also speed the validation process since less work will be done to determine the correct time zone.
Time zone mappings over-ride time zone data provided for contacts, where an appropriate mapping exists This rule allows you to enable the unconditional use of time zone mappings at the list level. This allows the time zone mappings to over-ride time zone data provided in the contact point's time zone attribute since the mappings are likely to be more accurate than specifying the time zone by either GMT offset or time zone name. This rule should not be created unless you have loaded the time zone mappings into IEC_G_TIMEZONE_MAPPINGS.

Validation Rule Example: