This chapter covers the following topics:
Oracle Email Center is a comprehensive solution for managing high volumes of inbound email. Oracle Email Center reduces the cost per email interaction by automatically replying to certain email inquiries as well as routing others to a skilled set of agents and providing them with a full featured console with cross application functionality.
Oracle Email Center increases customer satisfaction and reduces customer attrition by providing quick, accurate and consistent responses. It also increases agent's efficiency through the use of a full featured, Email Center agent console thereby reducing agent turnover.
An easy-to-use graphical user interface Administration console enables the administrator to configure the system, define processing rules and publish business data, while the Supervisor console enables the supervisor to manage email queues and balance workload. In addition, Oracle Interaction Center Intelligence provides a comprehensive set of reports that enable directors and managers to track email activity and relate it to business events. Through its integration with other Oracle E-Business applications, Email Center provides its agents with cross-application functionality and at the same time provides a utility called Message Component to the business applications for viewing, composing and responding to email messages.
Oracle Email Center is a complete solution for managing email interactions with customers, partners, suppliers, employees and other entities that interact with an organization. Oracle email Center can be integrated with any IMAP compliant mail server. Oracle Email Center can automatically analyze the intent of an incoming email in any of the multiple supported languages and suggest probable response documents to the agents based on the intent of the incoming email. A sophisticated Classification and Routing engine helps to automatically categorize the email based on rules defined by an administrator and route emails to a specific user group based on agent skills and email content. Using a centralized customer model and Oracle Customer Interaction History schema, Oracle Email Center records all email interactions and maintains a link to the archived emails as well. To better develop email into a strategic business channel, Oracle Email Center is seamlessly integrated with the other Oracle E-Business Suite applications. This integration enables the Email Center agent to create and update business objects such as service requests. Oracle Email Center also provides a utility called the 'Message Component' that provides agents in other applications with a unified approach to composing emails and viewing archived emails.
Oracle Email Center maximizes value for enterprises by automating incoming email interactions through classification, routing, queuing, response selection, and delivery of email messages to the appropriate group of agents. The enhanced processing engine now enables administrators to define rules using customizable data whose value changes dynamically. Based on these customizable business rules, incoming messages are automatically acknowledged, classified or categorized and routed to the appropriate contact center agents. The ability to insert tags into outbound emails and extract these tags from inbound response emails also enables Oracle Email Center to perform certain processing actions automatically. Oracle Email Center exploits the centralized customer information provided by Oracle's single customer model and leverages leading Oracle technologies and products such as Oracle Text (linguistics processing engine) to deliver a robust, functionality-rich solution.
A key strategy for customer acquisition and retention lies in deploying an email response management system as part of an integrated multi-channel customer contact strategy that is integrated with the enterprise's service applications. Along with Oracle Advanced Inbound and Advanced Outbound for telephony and web customer contact, Oracle Email Center provides contact centers with an easy-to-implement, enterprise-class email response management system pre-integrated with other interaction center channels and Oracle E-Business Suite applications.
This topic group contains the following topics:
Oracle Email Center Components
This section describes the architecture of Oracle Email Center.
Oracle Applications database
This database contains all Oracle Applications schema & API's including:
Marketing Encyclopedia System (MES) schema and programs
Knowledge Management (KM) schema
Customer Trading Community Architecture (TCA) schema
Customer Interaction History schema
The Email Center schema
Local Message Store schema
The Local Message Store (LMS) is a set of tables within the Email Center schema used for storing MIME messages. The LMS is split into Primary and Secondary message stores internally.
Email Center runtime and configuration schema
Primary Message Store - Holds all emails that are currently in the "active" processing state in Email Center.
Secondary Message Store - Holds all emails that are in "resolved," "sent," or "deleted" states.
Oracle internet Application Server (iAS) or Web Tier
This constitutes the middle-tier business logic and is used for all HTTP requests from the Email Center components such as the Email Center Administration Console, Agent Console and Message Component.
The Email Center middle-tier resides on iAS. In addition to providing the interfaces for the various Email Center components, the middle-tier also manages load and connections to the various IMAP and SMTP servers. Caching of commonly used objects like connections to email accounts, profile values, and server information is used for improved performance and scalability.
This tier also includes the Outbox Processor. The Outbox Processor is essentially a queue for outbound emails. Requests to this queue come from auto-ack, auto-routing, and auto-reply. The Outbox Processor records the interaction in Oracle Customer Interaction History and archive a copy of the outbound email prior to sending the email.
Oracle Email Center Agent Console
The Agent Console contains the Home page for an Email Center agent. This gives the agent a view on what email messages are waiting in queue for handling as well as what messages are currently assigned to the agent. From the Home page, an agent can request a new message from a classification queue, drill down to the Inbox to see what messages are still waiting to be answered, or compose a new outbound message. The Home page also gives agents the ability to take a break and to see what Email Center activities they've accomplished.
The Agent Console also provides a view to the agent's Inbox for each account to which the agent is assigned. The My Inbox page lists Sender, Subject, Date, and Status information for each message in the Inbox, and a click on the Subject will launch that message into its own Message Component window.
Customer functionality includes the ability to search for customers, to identify persons, organizations, or relationships to compose outbound email messages to, plus see what interactions agents have already had with the customer. In the Interactions view, agents can click on old messages and view them.
The calendar tab also exposes the Oracle Applications Foundation calendar functionality.
Oracle Email Center Message Component
The Message Component (MC) contains all functionality needed to compose, reply, or view email messages from Email Center. The MC is a standalone browser window that is launched from the Agent Console whenever a message needs to be viewed. Once the agent is finished with the message, the MC browser window closes.
The Message Component is also used by other integrated applications to allow them to view historical email messages that are stored in the Local Message Store and to compose new outbound messages.
The Message Component contains Knowledge Base functionality that allows agents to insert or attach documents. Customer searching and detail information allows agents to associate messages with customers.
Oracle Email Center Supervisor Console
If you have the Email Center Supervisor responsibility, you have access to the Supervisor tab displayed in the Email Center Agent Console. The Supervisor tab allows you to preview, assign, reply to, or delete queued messages; assign agents to accounts or accounts to agents; and create, update, and publish documents.
Oracle Email Center Administration Console
This console is used for defining email accounts for Email Center and configuring business rules for email processing. This set of screens enables administrators to configure define Email Center accounts, configure email processing rules, update Intents, assign agents to email accounts and publish response documents into the Marketing Encyclopedia System (MES).
Oracle Email Center Download Processor
The Download Processor is a Java service that runs in the iAS, or middle, tier and acts as an inbox processor. It polls the Inbox folder of active email accounts for new incoming emails and copies the new inbound emails into the Local Message Store. The Download Processor checks only for new emails in the inbox of active accounts on the mail server.
Here are summary points about Download Processor:
It is an Inbox processor.
It is a java service running in the middle tier and controlled by Generic Service Management (GSM) Framework.
It maintains its own jdbc connection pool and implements logging.
It polls the Inbox folder of active email accounts for new incoming emails.
It copies new inbound emails into Local Message Store (LMS).
It is registered as Email Center Download Processor – Normal Mode service (Migration Mode also registered).
Name – DP or ECDP.
Internal Code Name – EMTA (Email Center Mail Transfer Agent).
Oracle Email Center automatically creates the following two folders on the mail server for every email account created in Email Center:
Oracle Processed - The original incoming email is moved to the Oracle Processed folder from the Inbox folder after it has been successfully downloaded into the Local Message Store. Initially, this original email is stored on the mail server as well as a safety backup. For all other purposes of the Oracle Email Center. the email content in the Local Message Store is used.
Oracle Retry - If the Download Processor cannot process an incoming email, then the email is moved into the Oracle Retry folder from the Inbox folder and requires an administrator’s attention.
Oracle Email Center Message Access Layer
The Message Access Layer contains a collection of the APIs that handle reading and writing messages to the Local Message Store.
The Message Component provides all email message functionality, including viewing and composing. Inbound messages are displayed and can be replied to using system-generated suggested responses. Outbound messages can be created using a rich-text (HTML) or plain text editor that allows inserting standard templates and free form text.
The Email Center Agent Console is an HTML application that allows Email Center agents to view inbound message volume, request new messages, see assigned messages, and compose new messages. The composition and viewing of messages is handled by the Message Component which works in tandem with the Agent Console and allows the agent to work or view multiple email messages at the same time.
The supervisor console is a tab in the Email Center Agent Console that appears when you log in with the Email Center Supervisor responsibility. This tab allows you to preview, assign, reply to, or delete queued messages; assign agents to accounts or accounts to agents; and create, update, and publish documents.
The Administration console provides setup pages to guide an administrator through the implementation, configuration and administration process of Oracle Email Center.
The Email Center Server Process is a PL/SQL-based program that extracts information from an email message to perform the everything defined in the rules engine. This includes, for example, intent, classification, routing processes, and delivering email to the appropriate group of agents.
Email Center uses several features of the Oracle E-Business Suite products, such as the Resource Manager and Oracle Customer Interaction History (IH).
The code has the following sequence of steps:
Inbound email arrives at the mail server to an email account that is monitored by Oracle Email Center.
The email message is copied to the Local Message Store by the Download Processor.
The Email Processing concurrent program causes email processing to begin - extracting themes/tokens from the body of the email message.
Oracle Email Center identifies the intent of the email.
The "Party" is identified based on the from_address header.
Invokes rules engine:
The email is classified
Auto-delete rules are run against the email.
Auto-acknowledgement rules are run against the email.
Auto-processing is performed.
Auto-redirect rules are run against the email (internally or externally).
Auto-reply rules are run against the email.
Rules governing the suggested response document search are run.
Routing rules are run against the email and it is routed accordingly.
Outbox Processing describes what happens to a message related to an interaction when an Email Center agent performs an action on the message, such as Send, Delete, Transfer, Reroute, and Resolve.
Messages that agents initiate are processed in real time and do not use Outbox Processor. Outbox Processor is necessary, however, to handle auto-processing actions such as auto-acknowledgements and auto-replies that can occur during inbound email processing.
The step of editing the Applications Context file can be done with the Oracle Application Manager.
Steps:
Login to Oracle Application Manager.
Click Site Map.
In the System Configuration region, click AutoConfig.
Click the Edit Parameters image for the Application Tier context.
On the System tab, expand the oa_web_server Title.
Ensure the value for the Email OutBox Processor s_emailcenter_comment is blank. If it is a pound sign (#), delete it.
Save any changes and regenerate the jserv.properties file.
Restart the middle-tier.
To test whether or not the Outbox Processor is running, login to Email Center Administration, go to Monitoring > Outbox Processor > Status and verify there is an Outbox Processor running.
When Oracle Email Center agents log in, they are presented with the Home page.
From this page, the agent can either select an account and a classification to get a queued email or select an account and begin working on a previously fetched email. Agents can also compose a new message from an account.
When a queued email is selected, a new Message Component browser window is launched, and the message is displayed as a ready to edit Reply. Internally, the message ownership attribute is assigned to the agent.
At the same time, a draft reply message is created and cached in the database.
If the agent cannot answer the customer question it can be transferred to a manager or other subject matter expert using the Transfer button. Or, the agent can choose to reroute the message. Email Center provides the following reroute options:
reroute to a different account
reroute to a different classification
requeue the email
When an agent reroutes an email, the application excludes that agent from the list of agents to whom the email is rerouted. Similarly, if an email is placed back in the queue on more than one occasion, then any agent who has ever rerouted this email is excluded.
When rerouting to a different account or rerouting to a different classification, the email is reprocessed.
If the agent feels that no response is necessary, the inbound message can be deleted or marked as Resolved by selecting the LOV item in the Message Component actions menu.
Note: When an agent clicks the Delete button, the message is not actually deleted but is marked as Deleted in the Local Message Store. There a supervisor or administrator can review deleted messages prior to purging them.
On the reply page, the agent can create a personalized response to the customer inquiry using the following features:
insert or attach suggested responses generated by the backend processing,
attach other collateral documents either from the local machine or the network,
browse the MES knowledge base and add those documents,
search the MES or Knowledge Management knowledge bases for other information,
add free form text.
An attempt is made to identify the customer and contact for the email message. If the inbound message is a reply to a previously sent Email Center generated message, then the tag processing is used to look up the customer and contact. Otherwise, the TCA schema is searched for a matching email address. If an exact match is found, then the reply page displays the customer information. If multiple matches are found, then the agent can click a link to get a list of customers with matching email addresses. If the backend processing is unable to identify a customer, then the agent can search the customer database to attempt to find the customer. This enables more accurate Customer Interaction History to be recorded.
Finally, if the agent is unable to complete the reply, then the message can be saved using the Save option. If the Save option is selected, then the draft message is copied to the Local Message Store. The next time the inbound message is selected out of the agent's inbox, the saved draft message will be restored and presented to the user.
When the agent is finished with the message, the Message Component window is automatically closed. In the case of a "terminal" action for the message interaction with the agent (Transfer, Send, or Delete), Customer Interaction History is recorded so that in the future this agent or other agents can see the previous correspondence the company has had with this customer.
When the agent is finished with the message, whether Transferring, Sending, Deleting, Saving, or Canceling, the Message Component window is automatically closed. In the case of a "terminal" action for the message interaction with the agent (Transfer, Send, or Delete), Customer Interaction History is recorded such that in the future this agent or other agents can see the previous correspondence the company has had with the customer.
A system administrator assigns one or more responsibilities to an application user. A responsibility is a level of authority that allows a user to access specific functionality and data in Oracle Applications. Oracle Applications is installed with predefined responsibilities. A system administrator can modify a predefined responsibility or create custom responsibilities.
The following table describes the predefined responsibilities that are used to implement Oracle Email Center.
| Responsibility | Function | Interface |
|---|---|---|
| Email Center Administrator | Enables you to configure Email Center via the Administration console and run concurrent programs. | HTML |
| Interaction History Administration JSP | Allows you to create custom reason codes and associate them with Email Center actions. | HTML |
| Email Center Agent Console | Enables you to view the email queues and their account inboxes via the Email Center Agent Console | HTML |
| Email Center Message Component | Enables you to preview emails, respond to incoming emails and compose new emails. | HTML |
| Email Center Supervisor | Allows access to the Supervisor tab on the Agent console. This tab provides Email Center supervisors with a set of tools to better manage Email Center activities. | HTML |
In the Forms interface, if an application user has only one responsibility, then the related menu or application (if there is only one function in the menu) appears after the user signs on. If an application user has more than one responsibility, then a list of available responsibilities appears after the user signs on. To switch responsibilities, choose Switch Responsibility from the File menu.
In the HTML interface, an application user must select a default responsibility (even if the user has only one responsibility). The next time the application user signs on, the tabs related to the default responsibility appear. To switch responsibilities, go to Navigation Preferences in your profile (Profile icon). In the Switch Responsibilities section, select another responsibility from the Current Responsibility list.
Oracle Email Center uses the following responsibilities:
| Responsibility Name | Who Uses it | Responsibility Description |
|---|---|---|
| Email Center Administrator | Email Center Administrators | Allows access to the Email Center Administration Console. This console is used to:
|
| Interaction History JSP Admin | Email Center Administrators | Allows access to Oracle Interaction History, where administrators can create custom reason codes and associate them with Email Center actions. |
| Email Center Agent Console | Email Center Agents | This responsibility, along with the Email Center Message Component responsibility, must be assigned to all Email Center Agents. Allows access to the Email Center Agent Console. This console is used to:
|
| Email Center Message Component | Oracle Email Center Agents Oracle TeleService Agents Oracle TeleSales Agents |
Allows access to the Email Center Message Component. Allows Email Center agents to:
|
| Email Center Supervisor | Email Center Supervisors | Allows access to the Supervisor console. This tab allows you to:
|
Administrators can define an auto-processing rule to automatically create service requests. Administrators can select the service request type with which the service request will get created and also select which template will be used for email notifications sent from Email Center.
A service request is automatically created for an incoming email if it satisfies the assigned auto-processing rule conditions. A simple way that a service request is automatically created is that the content of the email body is included in service request notes. Oracle Email Center also provides an option to send a notification when the service request is created or updated.
Another type of rule, the Email Parser definition, provides information for much more complete automatic generation of service requests. This parses an inbound email and extracts detailed information from it. Within this rule, administrators can define the following:
Information that they want to extract from emails satisfying certain conditions
Tags between which data is parsed
The corresponding field on the Service Request schema to which this data is mapped
The parser definition rule has the same behavior as all the other rules that are defined in the Oracle Email Center application. These rules appear in the rules repository, and administrators can associate them with email accounts. If a parser definition and a create service request auto-processing rule are associated with an email account, then the information that is extracted from the inbound email based on the parser definition is transferred to the newly generated service request.
Service requests can be automatically created for emails from employees and contingent workers. If the auto create service request process fails, then the email can either be routed to an agent, a service request can be created for the default customer, or the email can be redirected to a specified email address. The option to redirect to a specified email address is only available for employee emails.
Oracle Email Center now provides administrators with the ability to define rules for automatically deleting an inbound email. If the conditions defined by the administrator are satisfied, then the incoming email will be automatically moved to the "Delete" system folder for that account. An interaction for the same will be recorded and the email will not be processed any further.
Auto-Redirect refers to the ability to redirect an incoming email to a different Email Center account or to an external email address based on defined rules. This functionality will provide the following benefits:
The ability to redirect emails from one central external (email address known to customers) account to multiple internal accounts (setup for dividing work internally).
The ability to transfer emails from an old de-activated email account to a new email account.
The ability to transfer emails to non-Email Center agents.
The ability to redirect emails to an agent's non-Email Center account which he/she can check without being connected to the network.
Oracle Email Center provides administrators with the ability to define rules for automatically redirecting an email message. In addition to the auto-redirect rules, custom tags are extracted from incoming emails and made available as keys for the defining rules. Activities and media life cycle segments are recorded to indicate that an incoming email was automatically redirected.
Oracle Email Center provides administrators with the ability to define rules for automatically replying to an inbound email. If the conditions defined by the administrator are satisfied, then an outbound response is formed using the templates/documents selected by the administrator and sent to the customer automatically using the Outbox Processor. The incoming email will be automatically moved to the "Resolved" system folder and a copy of the response will be archived in the "Sent" system folder for that account. An interaction for the same will be recorded and the email will not be processed any further.
Oracle Email Center's email processing engine allows you to set routing rules so that subsequent email correspondence with a customer will automatically be routed back to the original agent (the agent who handled the customer's original email).
Oracle Email Center tags every outbound message with the ID of the agent who sends it. To route a customer's response back to the agent who originally sent the email, when associating a "Routing" type rule to an email account, select "Original Agent" from the Primary Destination list. If the email processing engine identifies the presence of an "Agent ID" system tag in the inbound email, then it routes the email to that agent, otherwise the email will be routed to the resource (agent) group selected as the "Default Destination" for that routing rule.
Email Center agents can create a service request from the Email Center Message Component. The Service Request is associated with the incoming email and the SR number is tagged to the outbound response. Administrators can define rules for automatically updating a service request and the status code to be used. If the incoming email satisfies the conditions and if an SR number tag is extracted, then the corresponding service request will be updated to the status code selected by the administrator. As well, a template can be associated to the service request for sending out a notification as mentioned in the Auto-Create Service Request concept topic.
Queue access is the ability of agents to see emails in an email queue and selectively pick those emails that they prefer to work on. They retain their ability to reroute or assign an email from the message component.
Administrators can define whether an email account is enabled for queue access. If an email account is marked as enabled for queue access, then agents who have the proper permissions are able to selectively pick from all the queues under that account. In addition, administrators can enable queue access at the agent level. Therefore, administrators can allow a certain group of agents to pick from a particular queue. This gives administrators granular control over queue access for queues and agents.
The queue access functionality is enabled from the universal work queue access method in addition to the agent home page (HTML). As such, if a queue is marked as enabled for access, then agents can view the emails in the email queue by clicking the queue node.
As Oracle Email Center processes inbound and outbound email messages, Email Center uses customer IDs to record information about the messages processed. As Email Center is set up for use by your business, a default Customer ID must be defined for use by Oracle Email Center. The default Customer ID must be a customer identification number which you want to use when processing inbound and outbound email for which a customer match could not be identified. Depending on your business processes, this could be a customer ID that represents one of your current business customers or a customer that you have created specifically to be used as a default customer, such as “Unidentified Customer”. The default customer ID is used by Email Center for every interaction for which a customer match could not be found.
The Oracle Customer Interaction History schema requires a customer ID and a resource ID to create an interaction. Hence, like "default customer," Email Center also needs a "default resource" for recording interactions for all automated processing actions, such as Auto-Delete and Auto-Reply, performed by Oracle Email Center's email processing engine. All auto-processing interactions that do not involve an agent will use the resource ID number of the default resource.
Oracle Email Center utilizes two document retrieval methods: keyword matching and MES category mapping. The Document Retrieval processing rule enables administrators to select which method they want to utilize for retrieving documents from the Knowledge Base.If “Keyword Matching” method is selected, then the administrator can:
select either Knowledge Management or MES repository or both
select categories within MES in which to scan for documents with matching keywords.
Keyword Matching
Keyword matching matches keywords extracted from the incoming email to keywords in documents stored in the knowledge base repositories. This method of document retrieval is an extension of Intent Analysis explained in the Intent Processing topic. Each "Intent" in Email Center has two lists of keywords associated with it. One set of keywords (Type "Q" for Question) is used to perform a match against the set of keywords (tokens or themes) extracted from the incoming email message and another set of keywords (Type "R" for Response) is used to perform a match against the index of keywords related to the documents stored in the knowledge base repositories.
After identifying one or more "intents" of the email, Email Center appends the type "Response" keywords for each intent to the string of keywords extracted from the incoming email message and uses this new string to find matching documents from the knowledge base repositories. These matching documents are each assigned a score based on a complex algorithm which ultimately determines the order in which they are displayed to the agent.
MES Category Mapping
This method of document retrieval is based on a mapping of the incoming email to a specific category in Marketing Encyclopedia System (MES).
MES category mapping is a simplified approach where each incoming email gets mapped to a category in MES based on administrator defined conditions. Different categories can be selected for different defined conditions using the rules engine. The documents stored in that specific category are then displayed to the agent in the descending order of their usage, with the most widely used document on the top of the list.
The Oracle Email Center Download Processor is a Java service that runs in the iAS tier and acts as an inbox processor. It polls the Inbox folder of active email accounts for new incoming emails and copies the new inbound emails into the Local Message Store. The Download Processor checks only for new emails in the inbox of active accounts on the mail server.
Classifications are user-defined categories or queues in which email messages are placed depending on their properties and content. When you set up your Email Center system, queues are created for each of the classifications you define in your system. As email is received and categorized into an Email Center classification, the email message is placed in the queue for that classification. When an agent logs into the Email Center Agent Console, a list of email accounts, to which the agent has been given access, is displayed along with a list of the classification queues and the number of email messages in each of the queues. If a queue does not contain any email messages, the queue will not be displayed to the agent.
Email Center uses Email Center classifications to categorize inbound email so that it can be automatically routed to specific groups of agents. The Email Administration functionality provides classification administration pages which enable the creation of classifications using classification rules. Email Center classification rules use classification keys and for each type of key a set of valid operators are available. Classification keys represent inbound email characteristics such as message size or received date. Multiple classification rules can be chained together using And or Or operations to create a classification. The classifications are associated with specific email accounts and are given a processing priority within their associated email account.
Classifications can be used when defining routing rules. The Email Center Administration functionality enables you to classify your inbound email so that the email messages can be routed to specific groups of agents.
You use email classifications to differentiate email, such as email received from particular customers that should be routed to specific agents based on service levels. For example, you can classify your premier customers as Gold customers and classify other customers as Silver customers. You can then set up routing rules to route email messages from your Gold customers quickly to specific agents, so that Gold customers receive a greater level of service than Silver customers.
Email threading links all of the emails associated with a particular issue in a single thread. When an agent views the email thread, the agent sees all the email interactions from both the customer and the agent relating to that issue. All the emails pertaining to the specific issue are captured and displayed to the agent in descending order of time. Email interactions appear similar to how they are displayed on the HTML Service Request page. The Thread tab of the message component provides access to this display.
Oracle Email Center implementations are now enabled to execute a custom procedure as part of the email processing. All the data values extracted from the header of the incoming email including the tags are available as input parameters for the custom procedure. The custom procedure MUST return either "Y" or "N" as the output parameter. If the output of the customer procedure is "N", then the inbound email is not processed any further, or else the email is processed by executing other processing rules in the order of their priority.
IMAP is an acronym for “Internet Message Access Protocol” that regulates the communication between email clients and the messages stored in the Email Server.
The IMAP server is a set of processes that provide email clients with the ability to access and manage messages stored in the Email Server based on the above protocol.
Oracle Email Center can be integrated with any IMAP compliant email server.
Intent Analysis refers to the process that Oracle Email Center employs to identify the intent of the incoming email message or the broad area pertaining to the email. This process is primarily dependent on extracting keywords from the incoming email message. This is accomplished using the Oracle Text engine which is one of the core components of the Oracle Database. Oracle Text additionally has the option to derive related "themes" based on the "tokens" extracted from the incoming email message. For English language both theme and token processing is allowed. For all other language Oracle Text only uses only tokens.
These keywords (tokens or themes) are then matched against a set of keywords that were generated and stored in the Email Center schema as part of the configuration step of setting up "Intents". Based on this match, Email Center processing engine identifies one or more "Intents" related to the incoming email message.
For example, a hardware company would have the following intents: Accessories, Service, Product Information, Installation whereas a medical company will have very different intents, e.g. claims, insurance, and doctors.
As you work with email messages, you can use suggested response documents and email templates which have been stored in the knowledge base repositories set up for use by Email Center.
As you work with the Oracle Email Center application and refer to the Knowledge Base (KB) for Email Center, you are referring to the set of products that you are using to store documents used with email processing. The Email Center Knowledge Base can be just the Marketing Encyclopedia System (MES), or both MES and Oracle Knowledge Management. Oracle Knowledge Management, formerly named the Solution Management System (SMS), is a component which enables Oracle support applications to manage solution sets. Solution sets typically associate problems with their respective fixes. SMS serves as a repository of problem, diagnosis, related symptoms and their solutions. SMS is currently optional for Email Center but MES is required for use for Email Center.
As Oracle Email Center was set up for use by your business, the following two types of documents were uploaded into MES for you to use in composing or responding to email messages:
Suggested response documents: Documents which are presented to the agent as suggestions for responses to incoming email.
Message format templates: Documents which are predefined style sheets for Email Center agents to use when composing email messages.
As your Email Center system was set up, categories were created in MES in which to organize and store the Email Center related documents. Message format templates were created and then stored in the Email Center Templates category of MES. Message format templates must be stored directly under the Email Center Templates category in order for agents to access the templates. However, suggested response documents can be stored in any MES categories. Thus, suggested response documents were created and stored in the appropriate MES categories.
For organizational purposes, your Email Center administrator might have chosen to create an Email Center category in MES in which to store all of the Email Center related documents. If this has been done, the Email Center Templates category might have been created under the Email Center category, as a subcategory of Email Center.
The Local Message Store is a set of tables for storing Multipurpose Internet Mail Extensions (MIME) messages in the Email Center application schema. The Local Message Store contains two sets of tables:
The Primary Message Store - This store contains all email messages that are currently in a processing state in Email Center. These are messages with a status of Active. When an email is either in a queue or currently with an agent, the email message resides here. Tables with the name IEM_MS* compose this store.
The Secondary Message Store - This store contains all historic email messages. These are messages that have resolved, sent, or deleted statuses. After an agent either deletes or responds to an email message, the message moves here and its status changes to reflect the action taken on it. Tables with the name IEM_ARCH* compose this store.
Merge fields are dynamic content that are inserted into documents and templates with the aim of personalizing the content. The merge field is a placeholder for a variable that gets filled automatically by the application or when a query associated with a document is fired.
The use of merge fields in a document enables its content to be dynamic. Email Center recognizes dynamic merge fields only in HTML or text file type documents. You can create highly personalized response documents through the use of merge fields. To include merge fields in a document, they must be enclosed within a special set of tags.
For a required merge field: ((* *))
For an optional merge field: ((? ?))
In the following example:
Dear ((*CP_TITLE*)) ((?CP_FIRST_NAME?)) ((*CP_LAST_NAME*))
At the time agent selects document either for inserting or attaching into outbound email, values for merge fields CP_TITLE and CP_LAST_NAME will be required, whereas a value for CP_FIRST_NAME will be optional.
Email Center supports three types of merge fields:
Standard Merge Fields - These are pre-defined in Email Center. Standard merge fields are automatically populated with customer, email account and message information. These merge fields can be inserted directly into a response document or template and do not require a query for extracting the data. These merge fields can also be used as bind variables in a SQL query.
Following is the complete list of Standard Merge fields provided by Oracle Email Center for creating dynamic documents:
| Code | Description | Note |
|---|---|---|
| CP_LAST_NAME | Customer Last Name | PERSON_LAST_NAME from HZ_PARTIES table |
| CP_FIRST_NAME | Customer First Name | PERSON_FIRST_NAME from HZ_PARTIES table |
| CP_MIDDLE_NAME | Customer Middle Name | PERSON_MIDDLE_NAME from HZ_PARTIES table |
| CP_PREFERRED_NAME | Customer Preferred Name | KNOWN_AS from HZ_PARTIES table |
| CP_TITLE | Customer Title | PERSON_TITLE from HZ_PARTIES table |
| CP_2ND_TITLE | Customer Second Title | PERSON_ACADEMIC_TITLE from HZ_PARTIES table |
| CP_SUFFIX | Customer Suffix | PERSON_NAME_SUFFIX from HZ_PARTIES table |
| CP_EMAIL_ADDRESS | Customer Email Address | EMAIL_ADDRESS from HZ_PARTIES table |
| CP_PRIMARY_EMAIL | Customer Primary Email Address | Data from HZ_PARTIES table |
| CP_PRIMARY_PHONE | Customer Primary Phone Number | Data from HZ_PARTIES table |
| CP_HOME_PHONE | Customer Home Phone Number | Data from HZ_PARTIES table |
| CP_WORK_PHONE | Customer Office Phone Number | Data from HZ_PARTIES table |
| CP_ADDRESS | Customer Address | Data from HZ_PARTIES table |
| CP_ADDR_LINE1 | Customer Address Line 1 | ADDRESS1 from HZ_PARTIES table |
| CP_ADDR_LINE2 | Customer Address Line 2 | ADDRESS2 from HZ_PARTIES table |
| CP_CITY | Customer Address City | CITY from HZ_PARTIES table |
| CP_STATE | Customer Address State | STATE from HZ_PARTIES table |
| CP_PROVINCE | Customer Address Province | PROVINCE from HZ_PARTIES table |
| CP_POSTAL_CODE | Customer Address Postal Code | POSTAL_CODE from HZ_PARTIES table |
| CP_COUNTY | Customer Address County | COUNTY from HZ_PARTIES table |
| CP_COUNTRY | Customer Address Country | COUNTRY from HZ_PARTIES table |
| CP_ORGANIZATION | Customer Organization | Data from HZ_PARTIES table |
| CP_PARTY_ID | Party ID for the Customer | PARTY_ID from HZ_PARTIES table |
| CP_PARTY_NUMBER | Party Number for the Customer | PARTY_NUMBER from HZ_PARTIES table |
| Code | Description | Note |
|---|---|---|
| CON_LAST_NAME | Contact Last Name | Contact Data from HZ_PARTIES table |
| CON_FIRST_NAME | Contact First Name | |
| CON_MIDDLE_NAME | Contact Middle Name | |
| CON_PREFERRED_NAME | Contact Preferred Name | |
| CON_TITLE | Contact Title | |
| CON_2ND_TITLE | Contact Second Title | |
| CON_SUFFIX | Contact Suffix | |
| CON_EMAIL_ADDRESS | Contact Email Address | |
| CON_PRIMARY_EMAIL | Contact Primary Email Address | |
| CON_PRIMARY_PHONE | Contact Primary Phone Number | |
| CON_HOME_PHONE | Contact Home Phone Number | |
| CON_WORK_PHONE | Contact Office Phone Number | |
| CON_ADDRESS | Contact Address | |
| CON_ADDR_LINE1 | Contact Address Line 1 | |
| CON_ADDR_LINE2 | Contact Address Line 2 | |
| CON_CITY | Contact Address City | |
| CON_STATE | Contact Address State | |
| CON_PROVINCE | Contact Address Province | |
| CON_POSTAL_CODE | Contact Address Postal Code | |
| CON_COUNTY | Contact Address County | |
| CON_COUNTRY | Contact Address Country | |
| CON_ORGANIZATION | Contact Organization | |
| CON_PARTY_ID | Party ID for the Contact | |
| CON_PARTY_NUMBER | Party Number for the Contact |
Note: For standard merge field values containing customer and contact data to be automatically populated, the agent must ensure the Customer bin is populated (e.g. the customer lookup for an incoming email has been successful or the agent manually searches for and selects a customer), prior to inserting a document or template.
| Code | Description | Note |
|---|---|---|
| AD_USER_NAME | Agent User Name | This is the FND_USER.USER_NAME (e.g. MRABATIN |
| AD_USER_FULL_NAME | Agent Full Name | Concatenation of Agent's First Name and Last Name |
| Code | Description | Note |
|---|---|---|
| MD_CURR_DATE | Current Date | Current System Date |
| MD_CURR_TIME | Current Time | Current System Time |
| Code | Description |
|---|---|
| ACCT_REPLY_TO | Current Account Reply To Address |
| ACCT_FROM_NAME | Current Account From Name |
| ACCT_FROM_ADDRESS | Current Account From Email Address |
| ACCT_SIG | Current Account Signature |
| Code | Description |
|---|---|
| INB_EMAIL_ADDRESS | Inbound Message From Address |
| INB_SUBJECT | Inbound Message Subject |
| INB_TO | Inbound Message To Address List |
| INB_CC | Inbound Message Carbon Copy Address List |
| INB_SENT_DATE | Inbound Message Sent Date |
| INB_CLASSIFICATION | Inbound message classification |
| Code | Description |
|---|---|
| ACK_SENDER_NAME | Auto Acknowledgment - Full Name of the Sender |
| ACK_SUBJECT | Auto Acknowledgment - Subject of the Inbound Email |
| ACK_RECEIVED_DATE | Auto Acknowledgment - Email received Date |
| ACK_ACCT_EMAIL_ADDRESS | Auto Acknowledgment - Account email address |
| ACK_ACCT_FROM_NAME | Auto Acknowledgment - Full Name of the Account |
Custom Merge Fields - These merge fields are defined by the administrator. A value for each custom merge field must be manually entered by the agent before inserting or attaching the associated document into an outbound email. At the time when a document is inserted or attached the custom merge field placeholder(s) will be dynamically replaced with the data entered by the agent for each one respectively.
SQL Merge Fields - These merge fields are defined by the administrator. SQL merge fields are automatically populated with information resulting from the execution of a document's associated SQL Query. All SQL merge fields used in a document should correspond to column aliases of the Select statement portion of the document's associated SQL query. If bind variables are present in the Where clause of the SQL statement, the agent will be asked to enter valid values for them prior to executing the SQL query and, subsequently, auto-populating the document's SQL merge fields.
Bind variables do not require the use of merge field tags ((* *)) or ((? ?)).
For example, a document may contain? the following two SQL merge fields: ((*Product)) and ((*Date*)):
Dear customer,
Thank you for your interest in ((*PRODUCT*)). This product will be released on ((*DATE*)).
The query to populate these fields would have the following SELECT statement:
SELECT
PRODUCT_NAME "((*PRODUCT*))",
RELEASE_DATE "((*DATE*))"
FROM …
WHERE …
Note: Ensure that the SQL query is written such that a default value is returned if the query returns no data, otherwise the template/response document cannot be used.
Note: The alias for the column names in the Select clause, should match the name of the merge fields in the document. Do not end the query with a semicolon (;) or forward slash (/).
For the SQL merge fields to be auto-populated after the agent inserts or attaches the document into an outbound email, Email Center requires the selected document to be physically associated with the SQL Query.
This association occurs automatically when the dynamic document is created and published to MES via Email Center's Template Editor. If the dynamic document is not created using Email Center Template Editor, manual association of the document with SQL Query is required.
Note: If you enter a SQL Merge Field in a document, but fail to associate the document with a SQL query, Email Center assumes the merge field is a custom merge field and expects the agent to manually enter a value.
Email Center agents are provided with a menu of actions for handling email interactions. For example, an agent can compose/send a brand new email, transfer an inbound email to another agent, reply to an inbound email or simply delete an inbound email. In doing so, agents may want to record a justification or explanation of their actions and make this information available to other agents or to their supervisors who may work on or review the email interaction at a later time
Notes, also called annotations, provide agents with the ability to enter and review internal notes for any given email message. A note is related to a unique email message, whether or not the message spans across multiple interactions.
All notes associated to an email message are accessible for review via an Add Note hyperlink from the following pages:
Message Component - Reply Screen.
Message Component - View Message (Read Only) Screen* - this is the screen that is accessed by a supervisor when clicking on an e-mail message subject in the Supervisor Console's message summary screen.
Customer's Interaction History - Customer Details screen.
Interaction Threads screen.
Notes may also be entered directly from the transfer, assign, reroute and compose pages. In these cases, no Internal Notes pop-window is needed. Instead, these pages include an optional Notes text field.
The note type is based on what page you are on or what action you are taking. There are six seeded note types:
Assign Reason - Assign reasons provide an explanation of why an email message is being assigned to a particular user from a supervisor.
Delete Reason - Delete reasons provide an explanation of why an email message is being deleted.
Internal Note - Internal notes allow you to create an internal reminder to yourself or for another agent.
Reroute Reason - Reroute reasons provide an explanation of why an email is being rerouted to another classification group.
Transfer Reason - Transfer reasons provide an explanation of why an email is being transferred from one user to another.
Oracle Text, previously known as interMedia Text, is a component of the Oracle 8i and later versions of the Database. It provides a generic search, retrieval, and viewing capabilities for text. Email Center uses the Oracle Text application as part of it's Intent analysis process. Oracle Text extracts a set of keywords from an incoming message and provides them to the Email Center Intent engine to identify the email intent. Once the intent for the email is identified, Email Center calls a Marketing Encyclopedia System (MES) API that searches the Oracle Text index on the knowledge base repositories to determine appropriate response documents.
Email Center uses Oracle Text as part of its intent analysis process. Oracle Text extracts a set of keywords from an incoming email message and provides them to the Email Center intent engine to identify the email intent. After the intent for the email is identified, Oracle Text searches through the knowledge base repositories to determine appropriate response documents.
When used with Email Center, Oracle Text 8.1.7 performs text searches and keyword analysis in languages supported by CRM applications.
Oracle Text provides Email Center with a string of keywords and their associated scores extracted from the headers, body and any readable attachments of an incoming email message.
The quality of the intent process for a specific language is a function of not only how well the system has been “trained” and “tuned” over time by the administrator, but also the database character set and tools (such as stoplists provided by Oracle Text) used to optimize the search and retrieval of keywords.
Database Character Sets
A character set is specified when creating a database. The character set selected determines which languages can be processed by Email Center and Oracle Text. Over the years, character sets have evolved to support more than a single language. These new character sets support a group of related languages, based on the encoding scheme (that is, the same script). For example, the ISO 8859 Part 1 character set series was created to support 24 different European languages. More recently, the use of an unrestricted or universal character set, such as Unicode encompasses most major scripts of the modern world. Several character sets may meet your current language requirements, but you should consider future language requirements as well. Often, unrestricted multilingual support is needed, and a universal character set such as UTF8 is recommended as the database character set.
Oracle Text Default Stoplists
Oracle Text provides a set of default stoplists. Stoplists are lists of words which are not to be analyzed by Oracle Text. If a default stoplist exists for a language, it is used to identify the words that the system ignores during the text processing.
For example, the default English stoplist contains words such as “a,” “it,” “can,” “some,” “on,” “have,” “the,” and “they.” If an incoming email contains the text “Can I have some information on the Oracle Database?” then Oracle Text extracts the following keywords: “information,” “Oracle,” and “Database.” The other words are excluded.
An administrator can create stoplists for additional languages, and also extend the default stoplists. Please refer to the most current Oracle Text documentation for information about the available default stoplists, how to extend stoplists, and other tools for improving the precision of the linguistic analysis for a given language.
Email Center provides its agents with the ability to create and update service requests from within the Email Center Agent Console. This service request (SR) is associated with the email via Oracle Customer Interaction History. In addition when the agent responds to the incoming email after creating a service request, that SR number will be inserted as part of the tag information. If the customer replies back to the agent response, this SR number is then extracted and made available to the agent who can update the service request accordingly.
Tagging is a feature that enables you to define a set of keys and values. The encrypted set of key-value pairs is referred to as a "tag" that is automatically appended to the subject of every outbound email. When the customer replies back to an outbound email, the tag and its corresponding key-value pairs are extracted and made available to the system.
Two automated processing scenarios are listed below. These scenarios can be manually activated when the administrator sets the appropriate system profile option.
Automatic update of service requests
When processing an email, if the agent creates a service request from within Email Center, the service request number is included in the tag that is appended to the response sent to the customer. If the customer replies back, then the service request number is extracted from the incoming email and can be used to update the status of the service request automatically.
Automatic routing of email messages to a specific agent
The ID of the agent that composes an outbound email is included in the tag by default. This agent ID will then be extracted when the customer replies and used to route the incoming email back to the agent who generated the outbound email.
SMTP is an acronym for “Simple Mail Transport Protocol”. This is the standard used by Oracle Email Center to send and receive email messages from the Internet.
The SMTP server is the process that enables email messaging based on the above protocol.
Sendmail is an SMTP implementation that runs in the background, listening for incoming mail
Oracle Email Center now includes spell checking capability. The spell checking engine will enable agents to spell check their email responses or spell check any new emails they compose prior to sending it. The spell checking engine will also enable administrators and supervisors to check for spelling errors while creating a document/template using the editor provided within Oracle Email Center.
Dictionaries for the following languages are available:
American English
Brazilian Portuguese
British English
Canadian English
Danish
Dutch
English
Finnish
French
German
Italian
Norwegian
Portuguese
Spanish
Swedish
Additionally, a site level custom dictionary is provided, where the administrator can add words that are specific to the company/business such as company name, address, product names, common acronyms, etc.
The spell checking functionality enables users to replace a single occurrence of an incorrectly spelled word or all occurrences of that incorrectly spelled word with the correct match from the dictionary or as manually typed entry. You will also be able to ignore spelling errors identified by the spelling checker engine if you desire.
A "tag" can be defined as a container of valuable information that can be passed between a vendor and a customer using email as the communication channel. The process of appending such system or customer related data to the outbound email and extracting from an incoming email is referred to as "tagging". The data extracted can then be used for classifying and routing an email or automatically performing a processing action based on the content of the "tag". The ability to tag emails enhances the integration of Oracle Email Center with other E-Business Suite applications, whereby a specified action can be performed based on the presence, absence or value of a specific tag. For example, the outbound email can contain a service request number that is based on email generated from Oracle TeleService or Oracle TeleSales..
Tags fall into two categories:
System - System tags are seeded key value pairs, which are maintained and processed by the Email Center server processing engine. The following system tags are available:
INTERACTION_ID - Interaction ID for the outbound email
AGENT_ID - The Resource ID for the agent who is sending the email
CUSTOMER_ID - The PARTY ID for the customer selected
The above data will be appended to every outbound email by default. Additionally, other business applications integrated with Email Center can pass a key-value pair relevant to their business using the tag listed below.
BIZ_KEY_VAL - This is a variable key that enables business applications integrating with Email Center to pass values pertaining to their business. For example, the TeleService application may need to append the Service Request number.
Custom - Custom tags are defined by the administrator. These tags are not appended to the email by default but have to be explicitly associated with each email account. The custom tags can be of the following types:
Fixed - These keys have a fixed value.
Query - These keys have a SQL call for retrieving the value at run-time.
Procedure - These keys have a valid PL/SQL procedure call that generates the value of the key at run time.
After a custom tag is associated with an email account, every outbound email sent from that account automatically includes this tag.
Email Center creates a tag for each outbound email comprising the system tags and custom tags associated with that account and generates a unique encrypted ID. This unique encrypted ID is then enclosed within predefined tag markers and appended to the subject of the outgoing email as shown below:
"Re: Please assist with my issue [REF: 1005218040]".
When a customer replies back, Email Center identifies the tag markers in the subject of the email and extracts the tag ID enclosed within. This tag ID is then decrypted and the corresponding key-value pairs made available to the processing engine for validating the processing rules.
If you are using Microsoft Internet Explorer, you can select to compose the your email messages in the rich text mode by clicking on the “Change to Rich Text Mode” hyperlink on the Compose or Reply page. This provides you with rich text editor functionality. You can then switch back to plain text mode by clicking on the “Change to Plain Text Mode” button displayed as part of the toggle action.
Agents are required to enter a reason code for performing any of the interaction ending actions such as:
Replying to an inbound email
Deleting an inbound email
Transferring an inbound email
Rerouting an inbound email
Composing a new outbound email
A few reason codes for each of the above actions are seeded and are available out-of-the-box. However administrators can add more custom reason codes for each action using the Oracle Customer Interaction History Administration screens. The reason code is recorded along with other interaction data and can be used for reporting. Reason codes are also seeded and recorded for every automated processing action as well.