Setting Up Unstructured Email Handling

This chapter provides an overview of unstructured email routing and discusses how to:

• Define customer-based routing rules.

• Define context-based routing rules.

• Define content-based routing rules.

• Apply content-based routing rules to a mailbox.

Note. Throughout this chapter, the term worklist refers to both ordinary group worklists and to PeopleSoft MultiChannel Framework queues. The term customer refers to external customers and, if you use the email response management system (ERMS) with help desk applications, to the employees that the help desk serves.

See Also

Defining Worklists

Understanding Multichannel Applications Supported by PeopleSoft CRM

ERMS Processes

Understanding Unstructured Email Routing

The system's ability to analyze an email and perform an appropriate action is crucial to an efficient email response process.

This section discusses:

• Routing methods.

• Content-based routing using Verity.

Note. This chapter applies only to mailboxes for which you have enabled routing, based on email analysis or automated mail processing (AMP). This chapter does not apply to mailboxes that route all emails to a default worklist.

Routing Methods

The unstructured email process analyzes emails to determine the worklist whose members are most qualified to reply. The process that determines the appropriate worklist has several routing methods, as shown in the following diagram:

Routing process for unstructured email

When the routing process starts, it loops through each email, attempting to route each one to the appropriate worklist.

Note. The order of thread based, customer-based, and thread-based routing is designed to be in sync with automated mail processing.

Context-Based Routing

Context-based routing enables you to route an email based on the sender's email address. You can set up routing based on both fully qualified email addresses and on email domains (the portion of the email address that follows the @ symbol).

For example, to route all email from company XYZ to the preferred customer worklist, set up domain-based routing rules so that all email from the domain xyz.com is routed there.

Customer-Based Routing

Customer-based routing enables you to route emails based on factors such as customer value. To do so, the system checks the email's business object ID (as determined by the mail reader process). If the business object ID is the one that you use for unknown senders, the customer-based routing option is not available. However, if the business object ID represents an actual customer, the system performs any customer-based processing that you include in the routing process. PeopleSoft CRM does not come with any customer-based routing rules, only an infrastructure that you can use to plug in your own rules.

The customer-based routing method is available only with emails for which the sender is a known customer. However, because your organization is responsible for designing and implementing this type of routing, you can route the email based on any criteria you like, not just the identity of the sender.

Note. Remember that the word customer can refer to employees as well as to external customers.

Thread-Based Routing

Outbound emails sent through the PeopleSoft Customer Relationship Management (CRM) correspondence management system (ad hoc email notifications and ERMS email response) include an identifier known as a context tag. If the recipient replies to the email and includes the context tag in the reply, the routing process uses the tag to identify the parent email (the email to which the sender replied).

If the parent email was sent through the ERMS system (that is, the parent was a reply to another inbound email), the system sends the new email to the last group worklist associated with the previous inbound email.

For example, suppose that a customer sends an email (email A) to report a printer problem. This email is routed to the Laser Printers group worklist, and then it is rerouted to the Color Ink Jet Printers group worklist. An ERMS user replies (email B) asking for more information. This reply contains a context tag. The customer then replies (email C) with the requested information. Email C contains the context tag that originated in email B. When the system processes email C, it recognizes the context tag, traverses the thread to determine that email A is the previous inbound email, and routes email C to the Color Ink Jet Printers group worklist. If the ERMS user sends another email back to the customer (email D), the email message will have the same context tag as the previous emails in the thread.

If the parent email was an ad hoc email notification, there is no worklist already associated with the thread. In this case, the system establishes the sender of the original ad hoc email and routes the email to that user's default group worklist as established from the Supervisor Desktop. If the user does not have a default group worklist, the system routes the email to the mailbox's default worklist.

Note. Thread-based routing works only when the context tag is present. To increase the probability that customers will include the context tag when they reply to an email, the outbound email should instruct customers to include the context tag in reply messages.

Content-Based Routing

Content-based routing involves analyzing the content of an email message and routing the email to a group worklist with competent members who can process it properly.

There are two types of content-based routing in ERMS: one with the presence of NLP and the other one with Verity.

Content-based routing uses NLP, a third-party categorization application, to perform content analysis on emails and return suggested categories and threshold scores. By matching the returned category and threshold of an email to a list of rules that you define in the mailbox, the system can invoke proper actions to handle preliminary and common email processing (for example, respond to transaction status inquiry) in an automated fashion, thus reducing agents' workload. The routing process includes a rules engine, which is a batch process that runs periodically behind the scenes to process email from different mailboxes in a sequential manner. It matches email categories and threshold scores with active category rules that are associated with the mailbox. If the rules engine finds a rule that applies to the email, it triggers the specified action(s) automatically.

See Setting Up Automated Mail Processing.

If NLP is unavailable, content-based routing uses Verity, a third-party searching application, to search each email for keywords that you establish. You associate different worklists with different groups of keywords. By comparing the scores for each group of keywords, the system determines the worklist to which it routes the email.

The routing process runs as part of a job that also includes a process to build the Verity collection that the system uses for content analysis. The collection includes all emails in the unstructured email queue.

Each instance of the Build Collection process (RB_SRCH_BLD) overwrites the collection files that the previous instance of the process created. Because the system does not remove email from the unstructured email queue until it has been successfully routed, an email that is not routed because of a failure in the routing process remains in the queue and is included in the next iteration of the Verity collection.

The content-based routing process is described in more detail in the following sections.

Default Routing

If none of the previous routing methods identifies an appropriate worklist, the system routes the email to the default worklist for the mailbox. Every mailbox must have a default worklist.

See Also

Understanding PeopleSoft CRM Searching

Defining System Settings for Email Processing

Content-Based Routing Using Verity

This section describes the content-based routing process using Verity and the elements (queries, query groups, and worklists) that the system uses during content-based routing.

Queries and Query Groups

Content-based routing of this kind is based on matching the text in an email to a list of keywords that you define, when NLP is unavailable. You define the keyword lists at two levels. Queries are lists of weighted keywords. You assemble the queries into query groups.

For each query group, the system builds a Verity Query Language (VQL) statement based on the keywords in all the associated queries. Executing the VQL statement yields a score that indicates how well the email matches the keywords in that query group.

Defining VQL at the query group level and keywords at the query level can significantly reduce your keyword data entry and maintenance. For example, if you use 10 worklists for handling printer-related issues, you can define one query with keywords that are common to all printers and additional queries with keywords for certain types of printer issues. You can then set up query groups for each type of issue, and each query group's VQL references the common keywords in addition to the more specific ones. You do not need to enter or maintain the set of common keywords in 10 different locations. The reusability of queries and query groups makes the configuration of content-based routing rules more efficient.

You can also create your own VQL statement (either from scratch or by modifying the system-generated VQL). Once you set the query group definition to use user-created VQL, any queries associated with the query group are no longer relevant. Changes to the query or the query group do not update your custom VQL unless you copy the updated system-generated VQL again.

Typically, you create queries and have the system create the VQL for you. If, however, you prefer to write your own VQL, you do not need to create queries. If you create queries and write your own VQL, remember that the system does not use the queries when the user-defined VQL is in use. Also, remember to validate your VQL; the routing process does not use custom VQL that has not been validated.

ERMS Worklists

Each mailbox definition includes a list of worklists that are possible targets for content-based routing. Not only does this list help to focus the routing process, it also improves performance. The system obtains scores for relevant query groups only, and you can easily limit the number of queries executed for each email.

Worklists are associated with one or more query groups so that the query group scores can be used to calculate worklist scores. Two methods exist for calculating worklist scores: average query group score and highest query group score. You set this option for each mailbox that you define. Once the routing process calculates the scores for all potential worklists associated with a mailbox, it routes the email to the worklist with the highest score.

During the content analysis, the system records worklist scores so that you can view them later in the email routing history from the email workspace. When rerouting an email, you can refer to this scoring history to evaluate other potential worklists.

If the score is based on the highest query group score, the system also records (but does not display) the query group that achieved the score. If a worklist has more than one query group with the highest score, the priority that's set in the query group and worklist association determines which query group is considered the one that achieved the highest score.

Query, Query Group, Worklist, and Mailbox Relationships

Content-based routing is based on the following object associations:

• Queries to query groups.

• Query groups to worklists.

• Worklists to mailboxes.

The system routes an email to the mailbox worklist with the highest score. The system calculates the worklist's score based on the scores for the associated query groups. The system determines the query group score based on a VQL statement that includes keywords from the queries that are associated with the query group.

The following diagram illustrates these relationships:

Relationships of content analysis objects

In this diagram, an organization is using separate mailboxes for its North American and European support operations. In North America, the organization has separate group worklists to support laser printers and inkjet printers; in Europe, there is one group worklist for all printer types.

Because the North American support operation needs to separate laser printer issues from inkjet printer issues, there are separate query groups for each printer type. The European worklist is associated with both query groups, each North American worklist is associated with one.

Both of the query groups reference a shared query with general printer keywords. Two other queries provide lists of laser printer keywords and inkjet printer keywords to the appropriate query group.

Note. Queries use the PeopleSoft related language architecture, so if a query definition contain keywords in several language, the associated query group definition contains VQL for each language. During content analysis, the system applies the VQL that corresponds to the language code from the mailbox-specific run control for the Build Collection process.

Analysis Steps

Here is a summary of the process for content-based routing:

1. The system identifies the mailbox to which the email was sent.

2. Based on the mailbox definition, the system determines which worklists are valid targets.

3. The system determines which query groups are associated with those worklists.

4. The system executes the VQL for each query group and records each email's score for each query group.

5. The system determines the score for each worklist, using either the highest query group score or the average query group score.

6. If no worklist achieves the minimum threshold that you set, the email is routed to the mailbox's default worklist.

7. If at least one worklist achieves the minimum threshold, the system routes the email to the worklist with the highest score.

   To break a tie, the system uses the worklist priorities that you set within the mailbox definition.

8. The system performs the following post-routing processing:

   1. Sends an auto-acknowledgement email to the sender if the mailbox is configured for acknowledgements.

      The system skips this step if the email has a context tag. Consequently, customers do not receive acknowledgements for every email in an ongoing conversation; they receive an acknowledgment for the initial email only.

   2. Sets the email's processing status to Routed.

      The processing status is different from the email status that agents see on the email workspace.

      See ERMS Processes.

   3. Removes the email from the unstructured email queue.

Note. Content analysis analyzes email body text that is stored in the PeopleSoft CRM tables. It does not analyze content that is stored as an attachment. When the size of an email causes the system to store its entire content as an attachment, content analysis is not possible and the unstructured email process routes the email to the mailbox's default worklist.

Defining Customer-Based Routing Rules

This section discusses how to:

• Define an application class with customer-based routing rules.

• Apply customer-based routing rules to a mailbox.

Page Used to Define Customer-Based Routing Rules

Defining an Application Class with Customer-Based Routing Rules

To implement customer-based routing rules, create an application class that performs the necessary analysis and identifies the target worklist.

PeopleSoft CRM provides a base class called CustomRouting that you extend when creating your own routing processing. The delivered base class is located in the RB_ERMS package.

Sample Code

The following sample code returns a worklist called SpecialVIPService. The worklist name is passed to the unstructured email process, which routes the email to that worklist.

class CustomRouting
   method TargetWL() Returns string
end-class;

method TargetWL
   /+ Returns String +/
   Local string &Target_Worklist;
   
   /* Custom-based routing here and determine the target worklist to route the email to. In this example, the emails will
be routed to the group worklist, 'SpecialVIPService'
   
   &Target_Worklist = "SpecialVIPService";

   */
   Return &Target_Worklist;
end-method;

Applying Customer-Based Routing Rules to a Mailbox

Access the Mailbox Definition page.

In the Unstructured Email Processing group box, enter the ID and path for the application class to be used.

See Defining Mailboxes.

Defining Context-Based Routing Rules

This section discusses how to define context-based routing rules.

Page Used to Define Context-Based Routing Rules

Defining Context-Based Routing Rules

Access the Exception Routing page.

Reply To	Enter a fully qualified email address. Email received from this address is routed as specified on this page and does not go through content-based routing.
Domain	Enter an email address domain (the part of an email address that follows the @ symbol). Email received from any address in this domain is routed as specified on this page and does not go through content-based routing.
Worklist Name	Select the group worklist to which the system routes email from the specified address or domain.
Comment	Enter an optional comment that explains why email from the address or domain is routed to the specified worklist.

Defining Content-Based Routing Rules

This section discusses how to:

• Define queries.

• Define query groups.

• Associate query groups with worklists.

Note. This section only applies to content-based routing using Verity.

Prerequisites

Before you set up content-based routing rules, you must:

• Define the group worklists to which the content-based routing process routes email.

• Define the mailboxes that use the content-based routing rules.

See Also

Setting Up and Using Worklists

Defining Mailboxes

Pages Used to Define Content-Based Routing Rules

Defining Queries

To define queries, use the Query/Keyword Details (RB_QUERY) component.

Access the Query/Keyword Details page.

Active Flag	Select Active (the default) or Inactive. When the system creates the VQL for a query group, any inactive queries are ignored.
Exact Match	Select to search for an exact, case-sensitive, match. If you leave this check box clear, the system-generated VQL statement not only performs case-insensitive searches, it also searches for words based on the same stem. For example, if this check box is cleared and the query includes the word process, the system accepts the words processes and processing as matches.
Keyword or Phrase Description	List the words and phrases to include in the query. Entries that include more than one word are treated as phrases; the email matches the search criteria only if the entire phrase is present. Any punctuation that you include in the phrase is part of the phrase.
Weight	Assign a weight from 1 to 100 that corresponds to the relative importance of the word. When the system creates the VQL for a query group, this weight is applied to the keyword and is factored into the final query group score.

Note. Any change to a query's keywords, phrases, or weights automatically updates the system-generated VQL statements in all query groups that reference the modified query.

Defining Query Groups

To define query groups, use the Query Grp/System Associations (RB_QUERY_GROUP) component.

Access the Query Groups page.

Main Query Group Setup

Verity Query Language String

Queries

Associating Query Groups with a Worklist

To associate query groups with a worklist, use the Query Grp/Wrklist Associations (RB_WL_ROUTING) component.

Access the Query Group/Worklist Associations page.

Worklist Name and Queue	Displays the worklist whose query group associations you are defining. The read-only Queue check box is selected if the worklist that you are configuring is defined as a queue on the Group Worklist page.
Query Group ID	Select the query groups to associate with this worklist. Only active query groups are available for selection. If you inactivate a query group after associating it with a worklist, the query group is not used to determine the worklist's score. Query groups can be associated with multiple worklists.
Query Group Name	Displays the name of the query group as defined on the Query Groups page. Click the query group name to access the Query Groups page, where you can review the query definition.
Priority	When worklist scores are based on the highest query group score, the system records (but does not display) the query group that achieved the score. If a worklist has more than one query group with the highest score, the priority that you set here determines which query group is considered the one that achieved the highest score. Enter a priority from 1 to 999. Highest priority is given to the query group with the lowest value: priority 1 is higher priority than priority 2. This priority does not affect the routing, only the statistics that the system keeps. When worklist scores are based on average query group scores, this field is not used.

Applying Content-Based Routing Rules to a Mailbox

This section discusses how to:

• Associate AMP rules and worklists with a mailbox.

• Review worklist statistics for a mailbox.

• Review the content-based routing rules for a mailbox.

Pages Used to Apply Content-Based Routing Rules to a Mailbox

Associating AMP Rules and Worklists with a Mailbox

Access the Associate Rules and Worklist page.

Behavior Summary

Use this group box to associate categories and category rules with the mailbox. The rules engine triggers actions to process incoming email automatically based on the email category and threshold value that return from NLP and the predefined rule that is set up for that category. This group box does not appear if NLP is not licensed.

See Understanding Automated Mail Processing.

Associated Worklists

Reviewing Worklist Statistics for a Mailbox

Access the Worklist Routing Efficiency page.

Email Routing Statistics

Emails Reassigned and Completed in Other Worklists (Top 3)

As elsewhere on this page, the statistics in this group box relate only to email sent to the current mailbox and originally routed to the worklist whose efficiency information you're viewing.

Reviewing the Content-Based Routing Rules for a Mailbox

Access the Content Routing page.

Reload Tree

Click to update the information in the analysis hierarchy tree based on the most current content-based routing definitions.

Analysis Hierarchy

The tree in this group box provides an overview of the content-based routing rules associated with the current mailbox. Each node on the tree is a link that you can click to view the definition of the underlying object.

The tree includes the following elements:

• The root node of the tree represents the current mailbox.

  Click the link to display the Mailbox Definition page.

• Second-level nodes represent the worklists that have been associated with the mailbox on the Associate Rules and Worklist page.

  Click the link to display the Query Group/Worklist Associations page.

• Third-level nodes represent the query groups that have been associated with the worklists on the Query Group/Worklist page.

  Click the link to display the Query Groups page.

• Fourth-level nodes represent the queries (keyword lists) that have been associated with the query group on the Query Groups page.

  Click the link to display the Query/Keyword Details page.

  Note. If the query group uses custom VQL, the associated queries are not a reliable indicator of the query group content.

Key to Icons

Except for the root node, representing the mailbox, every node in the analysis hierarchy tree includes an icon that visually indicates the type of object represented.