This chapter covers the following topics:
The implementation of Oracle Email Center has been simplified and enhanced through the use of the Administration Console. Persons implementing Email Center should have a working knowledge of Oracle Forms, HTML, Java, and the installation platform.
This topic group contains the following:
A checklist of the steps to perform an Email Center implementation.
An implementation planning questionnaire that will help you determine and collect information you will need during the process.
A worksheet for gathering the necessary information for completing the configuration module sections.
In order to have a working Oracle Email Center, we recommend that you execute the following installation task sequences, listed below, in chronological order.
The Configuration, Rules, and Business Data steps can then be revisited to incorporate any implementation specific requirements.
Step 1: Auto install CRM Applications.
Step 2: Post install steps.
Step 3: Installation Check Point
Step 1: Create a Default Customer.
Step 2: Create user with access to the Email Center Administration Console and Monitoring Administration.
Step 3: Set System Profiles.
Step 4: Set Site Profiles.
Step 5: Configure email accounts on an IMAP compliant email server.
Step 6: Define corresponding email accounts in Email Center.
Step 7: Create user accounts for Email Center agents.
Step 8: Define Resource Groups.
Step 9: Configuration Check Point.
Step 1: Create email processing rules.
Step 2: Associate processing rules with email accounts.
Step 3: Rules Check Point.
Step 1: Create intents and keywords.
Step 2: Enable intent processing.
Step 3: Create hierarchical categories in MES.
Step 4: Create queries to populate merge fields.
Step 5: Create documents and templates using the template editor.
Step 6: Publish documents and templates into the MES categories created above.
Step 7: Business Data Check Point.
Oracle Email Center is a complete solution for managing email interactions with customers, partners, suppliers, employees, and other entities that interact with an organization.
Topics include:
To receive email messages in your Email Center, you must create email accounts on your IMAP compliant email server. Once created on the email server, these email accounts must be defined in Email Center.
Email accounts can be defined in Email Center as "Internal" or "External". External accounts are defined to receive emails from external parties such as customers, partners, resellers, and so on. Internal accounts are set up to receive emails from internal employees. The sender's email address for emails received in External email accounts are mapped against all email contact points stored in the TCA schema. However, for emails received in Internal email accounts, the sender's email address is mapped against all email addresses stored in the HRMS schema. Since these employee records cannot be searched or viewed in the Email Center Message Component, we recommend that Internal email accounts should only be used for automated email processing flows.
Email accounts defined in Email Center can be set to either "Active" or "Inactive" status. The Download Processor only monitors the Active email accounts while checking for new emails. Email Center agents can continue to acquire and respond to emails that have already been queued in the Inactive emails accounts, however, no new emails will be received unless the status of the email account is switched to "Active".
When you set the status of an email account to "Active", Email Center performs validation checks on the email account name, user name, account password, host name, and port number. Also, for its own internal processing, Email Center requires that each email account contain Oracle Processed and Oracle Retry folders. If these two folders are not already present, then Email Center will automatically create them upon account activation.
Email Center no longer requires special system folders such as Sent, Deleted, and Resolved, nor does it require the Unclassified folder and a folder for every classification associated with the email account. The various attributes of the email such as state, classification, and so on are now recorded in specific columns within the Local Message Store.
As well, the "Intent" and "Acknowledgement" accounts are no longer necessary. Email Center administrators can now create intents with corresponding keywords from within the Email Center administration console rather than build a keyword list by sending sample emails to an "Intent" account. The acknowledgment emails can now be easily separated from actual responses within the Local Message Store by recording a corresponding value in the email type column, thus eliminating the need for an "Acknowledgment" account.
The processing of an email can be divided into multiple segments with a predefined priority among them. The incoming email needs to be categorized or classified, the unwanted emails such as bounce-backs and auto-replies should be automatically deleted, valid email inquiries should be acknowledged, routed and responded to either manually or automatically. To enable the administrator to define multiple rules for each processing segment, the application has eight seeded processing rule types. Each rule type corresponds to a segment of the email processing cycle, and the ordering among rule types cannot be altered. Listed below are the rule types in the order they are executed:
Classification - This rule type determines the classification or category of an email. Each classification associated with an email account translates to a unique queue of email displayed to an agent while acquiring email messages. Customers can use Classifications to either prioritize the email or help agents differentiate between the intent of various email. If an email message does not meet the criteria for any of the classification rules associated with the email account, then the email is displayed in the "Unclassified" queue.
Auto-Delete - This type of rule pertains to automatically deleting incoming emails such as bounced messages or spam without processing it.
Auto-Acknowledge - This type of rule pertains to sending an auto-acknowledgement to the sender of the email.
Auto-Processing - This type of rule pertains to processing actions that are performed automatically on the incoming email such as create a service request or execute a custom procedure. This rule type can be used to automatically create a service request from an inbound email. An auto-processing rule to create a service request can include an email parser definition.
Auto-Redirect - This type of rule pertains to automatically redirecting emails to different accounts.
Auto-Reply - This rule type pertains to either automatically replying to an incoming email using specified documents or redirecting it to a different email address (not forward - retaining original header info).
Document Retrieval - This rule pertains to retrieving probable response documents.
Routing - This rule type pertains to either routing an email to an agent/group of agents, replying to it using specified documents, resolving the email interaction or redirect the email to a different address (not forward - retaining original header info).
For more information on each rule type, see the following topics:
Administrators can create multiple rules for each of the above rule types and assign them a priority while associating them with individual email accounts as explained in the following sections.
Note: In general, "specific" rules that apply to a small number of emails should be assigned a high priority, whereas "generic" rules that apply to majority of the emails should be assigned a low priority.
The Oracle Email Center processing engine executes rules within each rule type starting with priority "1" till a rule is executed. Once a rule within a given rule type is executed, the email processing will jump to the next rule type unless it is a "terminating" action such as auto-delete, auto-reply, or auto create SR. In which case, the processing of that email is terminated.
Ultimately, the incoming email will either be:
Automatically deleted
Automatically resolved (as part of the custom procedure/workflow execution) or auto create SR
Automatically responded to or
Routed to an agent or agent group
Key Descriptions
There are two parts to defining a rule - conditions and an action. While each rule type has its own corresponding action, the conditions for each rule type can be defined using static keys listed below or a "dynamic procedure" in the case of Classification and Routing rules.
If a key is not present, a value of "null" is being passed to the calling procedure. Therefore, there is only one way to verify the existence of a particular key, for example: "<Key> is not null".
Rule Engine Keys
| Key Name | Internal Name | Description | Comments |
| Agent ID | IEMNAGENTID | This tag is available in case of replied email. The agent ID is the resource ID of the agent who sent out the original email. | |
| All Intents | IEMSALLINTENTS | The concatenation string of all the intents to which inbound email are mapped. | |
| Classification | Classification name as determined by the "Classification" rules. When an incoming email is classified under the defined classifications, the classification name is then available for rule declaration. Thus, this key is NOT available while defining "Classification" rules. | ||
| Contact ID | IEMNCONTACTID | The contact ID of the customer. If the email is from an email address listed to a single identifiable customer contact in TCA, this key is available. | |
| Custom workflow Return Value | IEMSCUSTOMWFVAL | The return value passed by custom workflow engine | |
| Customer ID | IEMNCUSTOMERID | The party ID of the customer | If the email is from an email address listed to a single identifiable customer (party) in TCA, this key is available. In the case of a no match situation, the key has a value of –1 and in the case of multiple match situation, the key has a value of 0. |
| Email Top Intent | IEMSEMAILINTENT | The top intent, the intent with the highest score, of the email as determined by the Email Center Intent Engine processing. | |
| Language | IEMSLANGUAGE | The language of the inbound email as specified in the email extended header. The value for this key depends on the originating email system. For example, if the email originated from a Netscape Messenger email system, the value could be "EN" which specifies that the originating email system uses the English language. | This is a non standard value as it is email client dependent. Oracle does not suggest using this key unless you are sure about the value. |
| Message Size (in Bytes) | IEMNMESSAGESIZE | The size of the email message in Bytes, including any attachments. | |
| Organization | IEMSORGANIZATION | The organization information of the email client used by the sender. This value is picked up from the email extended header. | This is a non standard value as it is email client dependent. Oracle does not suggest using this key unless you are sure about the value. |
| Priority | IEMSPRIORITY | Priority of the email | In earlier releases, this value was passed from Oracle Email Server with possible values of: “High”, “Low”, and “Normal”. Since this value is determined by the email client of the sender, it is not very predictable. For this release, Oracle has set a fixed value of "1" for this column. |
| Received Date | IEMDRECEIVEDDATE | The system date when the email was received from the sending email client. | |
| Received Time (hh24: mm:ss) | IEMTRECEIVEDTIME | The system time, in the format of (hh24: mm:ss), when the email was received from the sending email client. | |
| Score Percent | IEMNSCOREPERCENT | The score percentage associated with the top email intent as received from the Email Center intent engine. | |
| Sender’s Email Address | The complete value of the sender email address, such as John.Smith@customer.com. | ||
| Service Request ID | IEMNBZTSRVSRID | This key is available in the case of replied email, if a service request is created for the original email. | |
| Subject | IEMSSUBJECT | The subject of the email picked up from the email subject line. | |
| System Date | IEMDSYSTEMDATE | The current system date when processing occurs. | |
| System Time (hh24: mm:ss) | IEMTSYSTEMTIME | The current system time, in the format of (hh24: mm:ss), when classification processing occurs. | |
| To Address | IEMSTOADDRESS | To Address for the Inbound Email |
The comparison operators available while defining the conditions vary depending on the data type of the selected key.
While entering a comparison value for the key, administrators must keep in mind the data type of the key. The majority of the keys are "text" type, for which Email Center imposes a 250-character limitation and does not permit the use of wildcard characters. However the text comparison is NOT case sensitive.
When specifying values for a numeric type key, such as Customer ID, Score Percent or Message Size, you must enter a whole integer value. Values cannot contain a decimal.
When specifying values for date or time type keys such as Received Date/Time or System Date/Time, you must enter the values in the formats shown below:
Date format: dd-mon-yyyy. If you enter the value in a different format, Email Center attempts to convert it to this format.
Time format: hh24:mm:ss, where "hh24" is a two digit number (00-23) representing an hour based on a 24 hour clock; "mm" is a two digit number (0-59) representing the minutes; and "ss" is a two digit number (0-59) representing the seconds.
Note: For time or date values, you can use the search icon to the right of the value field to select the appropriate date from a calendar or the time from a time clock.
Internal Keys Available for Customized Processing
| Key Name | Internal Name | Description | Comments |
| [Custom Tag] < Name of Custom Tag> | Name of the Custom Tag will be the internal key name | This value is passed as a part of key value pair available as a pl/sql table to the custom procedure. | The number of available custom tags is determined by the number of custom tags you create and associate with the email account. |
| Message Id | IEMNMESSAGEID | This is the internal Email Center message ID. | |
| Media Id | IEMNMEDIAID | This is the value of the Inbound Media ID that was created as part of email processing. | |
| Interaction Id | IEMNINTERACTIONID | This is the value of the Inbound Interaction ID that was created as part of email processing. |
If a generic rule is defined that applies to all emails received for a given email account then, you must select the "All Emails" check box for that rule. This check box is ONLY available while defining rules for the following rule types:
Auto-Acknowledge
Auto-Processing
Auto-Reply
Routing
The "All Emails" only applies to emails received in the email account to which the rule is associated. If for a given account, you have multiple rules within a rule type then in general you should assign a low priority to a generic rule that applies to "All Emails". The more specific rules should be assigned a higher priority.
Classification rules help categorize the email based on either the "static" key values selected or the outcome of a "dynamic" procedure. Upon successful execution of the classification rule, the email message is displayed to the agent in a unique queue of email messages. If none of the classification rules associated to an email account are satisfied, then the email is displayed in the "Unclassified" queue.
Auto-delete rules allow the automatic deletion of inbound emails without processing them. If the criteria in an auto-delete rule is met by an incoming email message, further processing of the email is terminated and the email status is set to "Delete" and the message is moved from the Primary Message Store to the Secondary Message Store within the Local Message Store. This type of rule will prevent the processing of junk email such as bounced messages and spam.
Auto-delete rules utilize similar key/operator/value configurations as classification rules do.
Auto-acknowledgements are confirmation emails that are sent for every incoming email received by an email account. These emails simply confirm receipt of the incoming email and may provide some indication of when the customer can expect a response. Auto-acknowledgements do not contain any content that is used to respond to a customer enquiry.
Auto-acknowledge rules utilize similar key/operator/value configurations as classification rules do. However, since the only action possible for the auto-acknowledge rule type is to send out an email acknowledgement, you can select the MES category and the specific template from the provided lists.
Upon successful execution of the auto-acknowledge rule, Email Center will ignore other auto-acknowledge rules of a lower priority and continue processing the email.
Auto-processing rules define additional processing actions that are automatically performed on incoming emails. These could either be a seeded action provided out-of-the-box such as such as Create Service Request, Update Service Request, or a custom procedure called using the Execute Custom Procedure/Workflow.
Create Service Request
The auto-processing rule action Create Service Request allows administrators to automatically create a service request from inbound email. Such a rule can include an email parser definition. Administrators can also specify what service request type and notification template to use when creating the service request.
When a service request is automatically created, the content of the email body is included in service request notes. If the auto-processing rule includes an email parser definition and thereby provides more information to the service request, the service request can then be better routed for best attention. Oracle Email Center also provides an option to send a notification when the service request is created or updated. Service requests can be created from both employee and contingent worker email.
If the auto create process fails, 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. However, the redirect option is only available for employee emails.
Update Service Request
When a service request is created in response to an incoming email from Email Center Message component, the SR number is tagged to the outbound email. If the customer replies back then the SR number is extracted from the email and the corresponding service request can be updated automatically using the status code selected by the administrator while defining the rule. Upon successful completion of the "update service request" rule, the incoming is automatically moved to the "Resolved" folder and not processed any further.
Execute Custom Procedure /Workflow
You can perform any customized computation or updates as part of the email processing cycle by invoking a custom procedure or workflow. All key values that are available while defining conditions are also available as input parameters for the custom procedure or workflow. The custom process is however required to return either "Y" or "N" as the output value. This determines if the email is processed any further ("Y") or not ("N").
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.
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.
Auto-Reply rules enables you to define conditions which if satisfied will result in an email response being composed using the selected document(s) and sent automatically without agent intervention to the customer.
You can select multiple documents and also select which of those should be inserted into or attached to the response.
If the incoming email is responded to automatically, then the status of the incoming email is automatically changed to "Resolved." The email is not processed any further.
In cases where an auto-reply email is sent in response to an incoming email message, an auto-acknowledgement email is supressed so the customer will not receive two separate email.
The Document Retrieval processing rule enables administrators to select a method for retrieving documents from Knowledge Base. They can choose to use the old keyword matching method, or the new MES Category Mapping method.
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.
If “MES Category Mapping” method is selected then the administrator can select one specific category to be mapped to the rule conditions.
Routing rules determine the resource (agent) group to whom the email will finally get routed to. Similar to Classification rules, routing rules can either be defined using the "static" key values or the output of a "dynamic" procedure. The resource (agent) group can be selected when the routing rule is associated with an email account. This is because each account will have a different set of valid groups to which an email can be routed.
There are two types of destinations that need to be selected while associating a routing rule to an email account - "Primary Destination" and "Default Destination". If the conditions for a routing rule are satisfied then the email processing engine will first try to route the email to the agent/group selected as the "Primary Destination". If the primary resource group does not contain any agents assigned to that email account then the processing engine will route the email to the "Default Destination" group. If the default resource group does not contain any agents assigned to that account as well, then the email processing engine will route the email to all agents assigned to that email account.
While selecting the "Primary Destination" an extra option called "Original Agent" is available. Oracle Email Center appends an "Agent ID" tag to every outbound email. When the customer replies back, this tag is extracted from the incoming email and used to route the email back to the same agent if and only if the routing rule has "Original Agent" selected as the "Primary Destination".
Oracle Email Center uses Oracle Text technology to extract keywords from an incoming email. The keywords are then used to identify the purpose or the "intent" of the email. The intent can then be used to categorize or classify email in unique queues. The keywords associated with an intent can also be used to automatically search through the knowledge base repositories and provide the agent with a list of documents that can serve as probable responses to the incoming email.
Oracle Email Center provides administrators with a user interface to create and manage intent. For Email Center's intent function to work, an administrator must configure "Intents" with sets of keywords that would be found in the incoming email as well the matching response documents stored in the knowledge base repositories. The administrator can rank the keywords by awarding each one a weight, which translates to its importance in comparison with other keywords for the same intent. Email Center then maps the keywords extracted by Oracle Text from the incoming email with the list keywords defined by the administrator to determine the "intent" of the email and retrieve matching response documents as well.
The Oracle Email Center email parser can parse an inbound email for data elements contained within user-defined tags. The information captured from the inbound email can then be used to populate service request fields when a service request is automatically created from this inbound email using an auto-processing rule. With the Email Parser Definition page, administrators can define the tags and the data associated with them. For an email, the application maps data between the start and end tags to the corresponding service request field indicated in a specific line item. Later, using the Create Auto-Processing Rule page, they can associate the definition with an auto-processing rule.
The following table shows the service request fields. (This document adds the Subfield column to meet legal requirements.)
| Subfield | Field | Description |
|---|---|---|
| Customer Attributes: | Service Request Type | Service Request Type |
| Customer Attributes: | Urgency | Urgency of the SR |
| Customer Attributes: | Account Number | Account Number |
| Customer Attributes: | Customer Number | Customer Number |
| Customer Attributes: | Customer Name | Name of the customer |
| Customer Attributes: | Customer Phone | Phone number of the customer |
| Customer Attributes: | Customer Email | Email address of the customer |
| Contact Attributes: | Contact Number | Contact Number |
| Contact Attributes: | Contact Name | Name of the Contact |
| Contact Attributes: | Contact Phone | Phone number of the Contact |
| Contact Attributes: | Contact Email | Email address of the Contact |
| Contact Attributes: | Instance Number | Instance Number |
| Contact Attributes: | Instance Serial Number | Serial Number for the Instance |
| Contact Attributes: | External Reference for an Item | External Reference number for an Item |
| Inventory Attributes: | Inventory Item number | Number of the Inventory Item |
| Inventory Attributes: | Tag Number | Tag Number |
| Inventory Attributes: | Serial Number | Serial Number |
| Problem Code and Resolution Code Attributes: | Problem Code | Problem Code |
| Incident Address Attributes: | Addressee | Addressee information |
| Incident Address Attributes: | Incident Site Number | Site number pertaining to that incident |
| Incident Address Attributes: | Site Name | Name of the Site |
| Incident Address Attributes: | Incident Address1 | Line 1 of Incident Address |
| Incident Address Attributes: | Incident Address2 | Line 2 of Incident Address |
| Incident Address Attributes: | Incident Address3 | Line 3 of Incident Address |
| Incident Address Attributes: | Incident Address4 | Line 4 of Incident Address |
| Incident Address Attributes: | Incident City | Incident City |
| Incident Address Attributes: | Incident State | Incident State |
| Incident Address Attributes: | Incident Country | Incident Country |
| Incident Address Attributes: | Incident Province | Incident Province |
| Incident Address Attributes: | Incident Postal Code | Incident Postal Code |
| Incident Address Attributes: | Incident County | Incident County |
Here is a example of the broad process of email parsing.
Setup
The administrator creates a new Email Parser definition with the line entries shown in the following table.
| Service Request Field | Start Tag | End Tag |
|---|---|---|
| Instance Number | Instance Number:[ | ] |
| Customer Number | Customer Number:[ | ] |
| Account Number | Account Number:[ | ] |
Structured Email
The structured email contains the following tagged text:
Instance Number:[ 121223]
Customer Number:[32222]
AccountNumber:[ 1608 ]
Action
The Email Parser definition is associated with a Create Service Request auto-processing rule. The Email Parser extracts the below data and maps it to the following service request fields:
121223 > Instance Number
32222 > Customer Number
1608 > Account Number
Subsequently, as part of the Create Service Request auto-processing rule, the data that the Inbound Parser definition has captured, such as Instance Number, Customer Number, and Account Number in the example is passed to the service request that the applications is creating from the inbound email.
In this example, the resulting service request that is created from this inbound email has the Instance number prepopulated with the 121233, the Customer Number field pre-populated with the value ‘32222’ and the Account Number field pre-populated with the value ‘1608’.
In the case where there is carriage return within the data being captured, the integrity of the carriage return is maintained. As an example:
SR Field: Problem Description Start Tag: Problem Description ( End Tag:) And we get the following email: Problem Description(Line 1 Line 2 Line 3) The captured data will be: Line 1 <cr>
A tag is an encrypted identification mark that is inserted into the subject line of an outgoing email message. A tag enables a company to associate valuable information with the email message, which can be used in future processing of a reply to an outbound email message.
Tags must be associated with email accounts in order to be used for email processing. Once a tag is associated with an email account, every outbound email sent from that account will have the tag id, and the values for every key in that tag, inserted into the email header.
Tags are invisible to the agent composing the email messages and are inserted into the email messages just prior to sending the email.
When a customer replies to an outbound email message, generated from the Email Center, the tag is included in the reply message. When the reply email is received by Email Center, the tag is identified and the Email Center server expands the tag, reads the key-value pairs, and passes the tag information through Email Center Auto Processing. The Auto Processing engine executes actions based on system and user defined rules.
There are two types of tags: system and custom.
System tags are seeded key value pairs, maintained and processed by the Email Center server processing engine. Examples are: INTERACTION_ID, AGENT_ID and BIZ_KEY_VAL. These are internal to the product and cannot be removed or changed. Email Center maintains seeded biz_key names for business applications that integrate with Email Center.
Custom tags are those defined and created using the Administration Console create tag functionality. Custom tags can be comprised of the following three types of keys:
Fixed: Keys that have a fixed value.
Query: Keys that have a SQL call for retrieving the value at run-time.
Procedure: Keys that have a valid PL/SQL API/function call that generates the value of the key at run time.
The Email Center Administrator can define the variables that form a tag using the Administration Console functionality. A tag is comprised of one or more keys. The three components of a key are Type, Name, and Value.
Examples of Custom Tags
Fixed type tag: All outgoing emails sent from a particular account should be flagged as a Priority, so a Fixed Tag "PRIORITYMAIL" is created with a value of "Priority". When an email is sent from this account it will include this tag. When a customer responds, the tag will be extracted and the incoming email will be classified as a "Priority" email based on the value of the Tag and presented accordingly to the agent.
Query type tag: A special offer is included with every outgoing email. This offer is only valid for 10 days after the email is sent out. A Query Tag "TENDAYOFFER" is created with a value of "select trunc(sysdate) from dual". When an email is sent from this account the SQL query is executed and the resulting value included in the tag. When a customer responds, the tag is extracted and the incoming email routed to the appropriate group of agents depending on whether the reply is within the 10 days.
Procedure type tag: The ID of the Customer associated with the email message is used to look up sales volume for last month. A Procedure Tag "SALESVOL" is created with a value of "LOOKUP_UP.SALES_VOLUME". When an email is sent from this account the Procedure is executed and the resulting value included in the tag. When a customer responds, the tag is extracted and based on the Tag value the email is classified. If the value is >10000 then classify as "Premier Customer", if >5000 and <10000 then "Gold Customer", otherwise "Silver Customer".
Oracle Email Center is integrated with two knowledge base repositories - Marketing Encyclopedia System (MES) and Knowledge Management, previously known as Solution Management System (SMS). Knowledge Management or SMS is a component which enables Oracle support applications to manage solution sets and 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.
While the Email Center processing engine can search both repositories for probable responses, Email Center administrators can only create and publish documents/templates in MES. The Email Center Message Component enables Email Center agents to manually search for documents in either repository based on keyword, but only enables browsing through categories defined in MES.
As Oracle Email Center is set up for use by your business, the following two types of documents must be uploaded into MES for agents 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 responses or new email messages.
As your Email Center system is set up, a hierarchy of categories are created in MES in which you can store the Email Center related documents. These categories can be visualized as folders which help you organize your data files.
Administrators can select the MES categories and sub-categories that will be scanned for matching response documents on a per account basis. This way the documents returned by the intent analysis engine are more accurate. Email Center administrators can also select the MES category in which the templates or style sheets are stored, so that when an agent is composing a new email, the templates stored in that category are available for "quick" insert. This is explained in the "Setting Profile Options" chapter later.
A document or a style sheet published in MES can have merge fields. These merge fields enable creating a document that can be populated with dynamic content. This is most useful for generating personalized responses using a single template or style sheet, where customer name and details could be defined as merge fields which get populated automatically when a customer is selected. Merge fields can also be populated by executing a SQL statement associated with the document. The details are explained in the "Configuring Business Data" section.
A resource group is a set of agents that can be assigned to work on a specific email account and/or a specific classification. The resource groups created are used as the destinations for the routing rules. Each resource group must have at least one agent. Resource groups created for Email Center purposes must have the "Call Center" usage assigned to it.