Managing Email

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

• Access inbound email.

• Work with inbound email.

• Reply to email.

Note. Throughout this chapter the term group worklist refers to both regular group worklists and MultiChannel Framework (MCF) queues.

Understanding Email Management

This section discusses:

• Agent tasks.

• Editable information in the Inbound Email component.

• Email sender identification.

• Email assignment and routing.

• Mailbox reset for email.

• Email classification.

• Assistance.

• Content sources.

• Solution and document search.

• Quick action buttons.

• Related transactions.

• Email replies.

• Email status tracking.

• Reply deadlines and notifications.

• System information for email messages.

Agent Tasks

Agents normally begin to work on an email after the Unstructured Email process routes it to the first group worklist.

Email Handling

Agents follow these steps to handle an email:

1. Access the email.

   Typically, agents access email from either a group worklist or through the MultiChannel Console. In addition, email is also accessible from the Search Inbound Emails component, from the 360-degree view of the associated customer, and on interactions lists that appear in various locations.

   See Accessing Inbound Email.

2. Accept ownership of the email.

   Only agents who belong to an email's group worklist can accept the email. Accepting ownership moves the email out of the group worklist and into the agent's individual worklist. The acceptance of an email is either automatic or agent-initiated. The method of acceptance depends on how the group worklist is defined and how the email is accessed:

   • If the agent accesses the email from the MultiChannel Console, acceptance occurs automatically when the agent navigates to the email.

   • If the agent accesses the email some other way (for example, through the Worklist page or the email workspace) and the email is currently assigned to a group worklist that uses automatic acceptance, then acceptance occurs automatically when the agent navigates to the email.

   • If the agent accesses the email not from the MultiChannel Console and the email is currently assigned to a group worklist that does not use automatic acceptance, the agent must explicitly accept the email by clicking the Accept button from the email workspace or on the Worklist page.

   • If the email has been reassigned or rerouted to an agent's worklist directly, the acceptance happens automatically, which means the agent is now responsible for processing the email.

3. Review the email in the email workspace to become familiar with its content.

   The email workspace recommends actions that agents can take based on the category of the email. The category value is either populated automatically if natural language processing (NLP) is available, or entered manually by the agent if NLP is not installed. Selecting a new category for the email on the Main tab of the Email page updates the recommended actions list immediately.

   Agents can search for additional materials (such as solutions and documents) to help resolve the issue and include them in the email response. The system uses solutions that are added to the proposed list as criterion to search for templates that can apply to the email response For documents that are added to the list, they are readily available as templates that agents can select. Documents are defined as correspondence templates in the system.

4. Modify data as necessary.

   Although most fields are not editable, agents can make these modifications:

   • Change the email sender information if the Mail Reader process (RB_MAIL_READ) misidentified the sender or was not able to provide complete sender information.

   • Change the categorization of the email, if NLP is not available or the automated mail processor (AMP) misidentified the values. Categorization attributes include category, type, product group, product, mood, and priority.

   • Modify the email subject text for greater clarity.

   • Associate solutions to the email and maintain the solution status as it pertains to the email.

   • Change the email's thread association.

   • Add notes to the email.

   • Change to a different mailbox using the mailbox reset feature if the email was incorrectly sent to the mailbox.

5. Create transactions for the email.

   • Agents can create new transactions or associate an existing transaction with the email if that is the most effective way to handle the issue.

     For example, if the email reports a product support issue, the agent can create a support case that is related to the email.

   • Agents can delete inherited transactions if they are not relevant to the current email.

     An email that the system identifies as part of a thread inherits the parent's related transactions.

   • Agents can navigate directly to related transactions to work on the sender's issue.

6. Reply to the sender.

   Agents can reply or forward the email directly from the email workspace. If there are related transactions, agents can reply from the corresponding component. Replies can be free-form text or template-based.

7. Close the email.

   Agents can update the email status on the Email page (by explicitly selecting an applicable status). If the agent is the owner of the email, replying the email in the email workspace automatically updates the editable email status to Closed - Response and the system email status to completed. The system also updates the status of the corresponding entry in the agent's worklist to completed. If the email was opened from the MultiChannel Console, it is removed automatically from the console's task list after the agent sends a response.

   When an email is closed and NLP is available, the system submits the information about the email and its category to NLP for teaching and learning purposes.

   Note. By default, the system asks agents if they wish to enter a note after they have sent email response. This feature can be disabled as part of the email user preferences.

If, after accepting an email, the agent is unable to complete the email handling process, the agent can requeue the email to its previous group worklist or reassign it to another one. If the agent determines that the email does not require handling (for example, if the email is spam), the agent can end the process at any time by setting the editable email status to Closed - Canceled.

See Setting Up Natural Language Processing.

See Setting Up Automated Mail Processing.

See Personalizing Email Workspace.

Email Modes

The ability to update data and perform various actions in the email workspace depends on the user who accesses it. The description of the conditional logic for specific fields is available throughout this chapter. This table summarizes the actions that are available to different users depending on whether the email is currently assigned or unassigned:

Note. In the email workspace, users must accept an email before reassigning it. On the Worklist page, however, users can reassign an email without first accepting it. In addition, any user can add notes to an email regardless of the state of the email or user permission.

Editable Information in the Email Workspace

After accepting ownership of an inbound email, an agent can modify certain data, including the email subject, status, sender information, and the thread information.

See Email Status Tracking.

Email Subject Text

Email subject lines help users to better identify emails. However, emails often have blank or nondescriptive subjects. Consequently, agents may want to replace an inbound email's original subject with more descriptive text. You can configure the system to add a default subject to emails with blank subject fields, but the default text should be generic. If you do not set up default subjects, the default subject is <No Subject>.

Agents can edit the subject text only after accepting ownership of the email. After the new subject text is saved, the agent cannot retrieve the original subject text. Although the original data still exists in the PeopleTools email table, it is not available to users through PeopleSoft Internet Architecture.

See Defining System Settings for Email Processing.

Email Threading

An email thread consists of a beginning email (which can be either an inbound or outbound email) and all of its descendants—that is, replies, responses to replies, and so on. When you look at an email that belongs to a thread, viewing emails that are dated earlier in the thread provides a history of the discussion.

Both the email workspace and the Outbound Email component include a Thread page that shows email threads in the tree view. You can review summary information about the emails, look at the content of the selected email on the Email Message area, and navigate to an email for detailed information. By associating with another email in the Recent Activities tab on the Email page, an agent can change the thread association as well.

When an agent replies to an inbound email, the system threads the reply to the inbound email. If the agent sends the reply from the context of a specific inbound email, the threading association is automatic. If the agent sends the reply from the context of a transaction (for example, a case that is associated with the inbound email), the system provides a page in which the agent explicitly identifies the inbound email.

When an agent sends an outbound email (either an ad hoc notification or an email reply), the system appends an identifier known as a context tag to the body of the email. If the customer replies to the outbound email and includes the context tag in the reply, the context tag enables the system to establish the new email's thread association. An email automatically inherits its parent's related transactions.

When an agent associate the current email to another email thread, the items that are associated with it (for example, solutions, documents and notes) are moved altogether to the new thread.

The ability of the Unstructured Email process to correctly add new emails to a thread depends on customer actions that agents cannot control. For that reason, the system also enables agents to add emails to a thread manually. Access the Recent Activities tab on the Email page and select Emails as the activity type. Agents can select the desired outbound email either from the search result list that appears (where both inbound and outbound emails of the sender are displayed), or look it up from the search by clicking the Search Outbound Emails link. When selecting a new parent email, the agent selects from outbound emails. The recipient of the outbound email must match the sender of the inbound email.

Note. Changing sender information for one email does not affect the sender information for other emails in the thread. If a threaded email's sender information is inaccurate, correct the data for each email in the thread.

Email Sender Identification

This section discusses the fields that identify an email's sender and explains how these are populated.

Sender Identification Fields

These three fields in the email workspace that identify the sender. They are located in the More tab of the Email Details group box on the Email page:

If a role is identified for the sender, you can access the sender's record by clicking the sender's link on the toolbar summary area. You can also access the company or consumer record that the sender represents if it's identified as well.

See Managing Inbound Email.

Automatic Sender Identification

The Mail Reader process attempts to identify the email sender automatically. To do this, it attempts to match the email's from address with an email address in the CRM database. The system's ability to populate the Sender and Representing fields depends on the available information. The Mail Reader process functions differently under the following conditions:

• The email address is not recognized.

  Based on the mailbox-level setup, the Mail Reader process either associates the email with the unknown user that you select on the ERMS System Installations (email response management system installations) page or creates a new user based on the unidentified email address.

• The email address is associated with one person, and that person has one applicable role.

  The Mail Reader process populates the Sender field. Additionally, if the sender role is contact, and the person is a contact for one entity (either a consumer or a company), the Mail Reader process populates the Representing field.

• The email address is associated with one person, and that person has more than one applicable role.

  The Mail Reader process populates only the Sender field and the Email page (in the More tab) displays a Role drop-down list box that the agent uses to select a role for the sender.

  This condition does not apply to internal mailboxes, which always set the sender's role to worker. For partner mailboxes, the sender role is always contact.

• The email address is associated with more than one person.

  The Mail Reader process populates the Sender field with the first user it finds, and enables a multiple person indicator in the email record. The indicator displays a Mark Sender as Verified button on the Main tab of the Email page to alert the agent that the sender data needs to be verified (it may need to be changed). The agent, when satisfied with the sender data, clicks the button to turn off the multiple person indicator. When the agent clicks the button, it changes to Verified until the agent saves and exits the email. After that, the button no longer appears on the page. This button is not displayed when the agent has updated and saved the business object information of the mail.

Manual Sender Identification

The Mail Reader process does not always provide all of the sender information. Agents must sometimes verify and enter accurate sender information. Only the assigned agent can modify this data.

Identifying sender information for an internal mailbox's emails is straightforward. When agents click the prompt of the Sender field, the system performs the search against workers. The sender role is worker (this information is not displayed) and the sender does not represent any entity (the Representing field does not apply).

The procedure of identifying sender information for emails that belong to an external mailbox varies depending on the information that the Mail Reader process provides:

• If the agent needs to manually identify the sender, either because the Mail Reader process didn't identify the sender, or it identified the sender incorrectly).

  When the agent enters data or click the prompt of the Sender field, the system performs the search that enables selection of contacts and consumers. When the agent locates a sender using the business object search, it automatically identifies the sender's role. If the role of the identified sender is contact, the search presents a list of companies and consumers that are associated with the sender so that the agent can further identify as what the sender may represent. If the role is consumer, the system populates the Sender field with the selected consumer. The representing information does not apply to consumers.

  Assume that both the sender and representing values are already populated. If the agent clicks the Representing field prompt, it displays a list of companies and consumers that the sender represents as a contact. In the case where the agent clicks the Sender field prompt, the system displays a list of senders, which means the agent is essentially searching for a new sender for the email.

  Typically, agents search for the email sender, then find the entity that the sender represents if the sender role is contact. If the agent wants to change the representing value and click the prompt next to the field, the list of consumers and companies that the sender person may represent appears. In either prompt, if the agent selects a consumer from the list, this value is populated to the Sender field and the Representing field no longer appears.

  See Understanding the Business Object Search and Quick Create Process.

  See BO Searches on Configurable Search Pages.

• If the Mail Reader process correctly identifies the sender but the sender is associated with more than one role.

  An agent uses the Role drop-down list box to select a role. When the role is set, this drop-down list box no longer appears.

Identifying sender information for a partner mailbox's emails involves searching for a sender (contacts only). The search then presents a list of partner companies that are associated with the sender so that the agent can further identify as what the sender may represent.

Note. Agents must provide the sender and role information if the Mail Reader process is unable to do so. While the role remains unknown, users cannot create related transactions (for example, new cases or leads) in the email workspace.

Customer Quick Create

If the business object search cannot return a match from the database, agents can add new business objects the quick create functionality, which include:

• Create consumer.

• Create consumer with contact.

• Create company with contact.

Note. Only external mailboxes support quick create.

See Setting Up Business Object Search and Quick Create.

Business Unit Identification

The email workspace uses the business unit that is specified in the mailbox definition as the default value when performing these operations:

• Creating transactions - when the agent creates a transaction (for example, add an order) from an email, the system creates the transaction using the same business unit that is defined in the mailbox to where the email belongs.

  Note. If the setID of the email's sender or representing entity and the setID that is associated with the mailbox's business unit are not the same, the system displays an error when the agent attempts to create a transaction and the operation cannot be completed.

• Searching for transactions - if the agent wants to associate the email with an existing transaction or outbound email within email workspace, the initial search is limited by the business unit.

• Creating business objects - when the agent creates a new contact or consumer through the quite create feature, the business object is created under the setID that the mailbox's business unit is associated with.

• Searching for business objects - if the agent wants to change the value of the Sender or Representing field, the search of business objects is applicable to all setIDs.

The business unit of the email is not editable. The value changes, however, when the mailbox reset operation takes place, which changes the business unit to match the business unit setting of the new mailbox that the email is routed.

Email Assignment and Routing

This section discusses how emails are sent to group worklists, individual worklists and can be rerouted to different mailboxes. The History page in the email workspace includes a link that you click to see the email's entire routing history, including a routing method and routing reason for each reassignment.

Group and Individual Worklists

An email begins its route through the system in a group worklist. Before an agent can work on the mail, however, the agent must accept it (either explicitly or automatically). When an agent accepts the email, the system assigns it to that agent and moves it to the agent's individual worklist.

The options that are available in the email workspace to process emails change after they are accepted. Before the acceptance, things that agents can perform on emails are minimal: accepting them or adding email notes. After the acceptance, email owners can choose to reassign them, modify certain email data, work on them and search for solutions and documents to resolve email issues, manage relationships with other CRM transactions, and last but not least, respond to them or forward them to other people. Agents who belong to the same group as the email owner can reassign, reply and forward the assigned email. However, when the email is closed by a group member, it is neither closed automatically nor removed from the worklist. This functionality applies only when the email is closed by its owner.

After an email is assigned to an agent, the email is displayed in an individual worklist. The system still keeps the name of the previous group worklist and uses this information to:

• Set worklist-level response deadlines.

• Identify the group worklist owner and group worklist members.

  The group worklist owner and the other group worklist members can take ownership of a email even after it is assigned to someone. The mailbox owner is the only other user with this privilege.

• Identify where to send an email that an agent requeues.

  Requeuing returns the email to the previous group worklist.

• Route subsequent emails in the same thread.

  If the Unstructured Email process identifies a new inbound email as a continuation of an existing email thread, it routes that new email to the group worklist of the most recent inbound email in the thread. For example, suppose that an agent replies to inbound email A by sending outbound email B. If the customer sends inbound email C in reply to email B (and if email C contains the code that enables the Unstructured Email process to identify the thread), the Unstructured Email process routes email C to the group worklist for email A.

  See Understanding Unstructured Email Routing.

Routing to a Group Worklist

The Unstructured Email process initially routes all emails to group worklists. After that initial routing, agents have two ways to route emails to a group worklist:

• Reassign an email to a different group worklist.

  To do this, the agent clicks the Reassign Selected button on the Worklist page or the Reassign button on any page in the email workspace. The system prompts the agent to select a routing reason code and to enter a comment explaining why the email is reassigned.

• Send an accepted email back to the previous group worklist and let it be assigned to another member in the group.

  To do this, the agent clicks the Requeue toolbar button in the email workspace.

The system keeps statistics to show what percentage of email is routed to a group worklist other than the one selected by the Unstructured Email process. Use this information to assess and fine-tune the unstructured routing rules.

See Reviewing Worklist Statistics for a Mailbox.

Assignment to an Individual Worklist

The system routes an email to an individual worklist when an agent accepts the email—that is, when the email is assigned.

Email is routed to an individual worklist when:

• The agent opens an email from the MultiChannel Console.

• The email is routed directly to the agent's worklist.

  An agent can reassign the email (owned by the agent) to another agent's worklist as appropriate. Prior to selecting an agent, you must select a group worklist so that the system can base the internal response time computation on the corresponding group worklist setup. In other words, the agent selection is refined by the group that you choose in the first place.

  Emails that are routed to agents show up in their individual worklists only (not available in the MCF task list). Agents should access their own worklists for the complete list of emails that are assigned to them.

• The email's group worklist uses auto-acceptance, and an agent who belongs to the email's group worklist navigates to the email.

  The agent can either requeue the email to the previous group worklist, reassign it to a different group worklist or a different mailbox, but the routing history still shows that the email was previously assigned to the agent.

  Auto-acceptance of email occurs when all these conditions are met:

  • The group worklist that the email routes to supports auto-acceptance.

  • The email is not assigned to any agent and is not closed.

  • The email is opened by an agent of the group worklist to which the email is routed.

• An agent explicitly accepts the assignment.

  When the worklist does not use auto-acceptance, agents must explicitly accept email. They do this by clicking the Accept button on any page in the email workspace or by clicking the Accept Selected button on the Worklist page.

• A group worklist member, the group worklist owner, or the mailbox owner explicitly takes ownership of the email.

  These users can accept email even if it is already assigned to someone else. To do so, they click the Take Ownership button on any page in the email workspace. This button is not visible to other users.

Routing Reasons

The system uses routing reasons to provide additional details about an email's routing history.

When the Unstructured Email process routes an email, it sets one of these routing reasons:

• Routed: The Unstructured Email process routed the email, and none of the other routing reasons apply.

• Bypassed: The Unstructured Email routing process sent the email to the mailbox's default worklist because the mailbox's automatic routing option was not selected.

• Oversized: The Unstructured Email routing process sent the email to the mailbox's default worklist because the system could not perform thread-based routing or content analysis on an oversized email.

  Because of the way the system stores the content of an oversize email, the email's body text is not available for thread analysis or content analysis. The Unstructured Email routing process can still perform customer-based and context-based routing on an oversized email, but if neither of these subprocesses routes the email, the system does not perform the content analysis subprocess, and it sends the email directly to the mailbox's default worklist.

• Encoding: The Unstructured Email routing process sent the email to the mailbox's default worklist because of errors reading the email.

When users perform certain routing actions, the system sets these routing reasons:

• Accepted: A user has accepted the email, either explicitly or because the email belongs to a worklist that uses auto-acceptance.

• Requeued: A user who accepted the email sends it back to the previous group worklist.

When users manually reassign an email to a group worklist, the drop-down list box for routing reasons includes all of the preceding values as well as the these additional values. The business rules of the organization determine how these values are used:

• Escalated.

• Misrouted.

• Overridden.

• Reassigned.

• Other.

  When you use other, you must include a comment to describe this routing reason.

Mailbox Reset for Email

If the system assigns an email to a mailbox by mistake, agents can initiate the mailbox reset functionality to remove all the mailbox-related data from the email. The email is then sent to the system and be reprocessed by the ERMS system. They can select any mailbox that is currently active in the system. When the reset is completed, a routing history entry is logged. The email workspace resets some data (for example, existing categorization, recommended actions, suggested solutions, assignment and status that is not New) of that email so that the mail reader application engine process can process it as if it's newly fetched from the email server. This type of emails have a special status, and the mail reader process doesn't get them from the mail server but from within CRM because they are already stored in the database. The processing is the same for new emails and those that are reassigned to different mailboxes. As a result of a mailbox reset, email workspace recomputes the external response time for the email so that the alert notification doesn't get fired prematurely.

Important! Exercise caution before using the mailbox reset functionality. It involves the removal of some email data to complete the process and the operation, when finished, cannot be reverted.

Email Classification

Classification of emails is crucial when it comes to providing accurate recommendation of solutions and materials to resolve emails, and suggestion of correspondence templates to use for the email response.

Types of Classification Data

An email can be classified by:

• Category: a high level classification of an email, for example, problem, inquiry, or complaint.

• Type: a sub-categorization within a category, for example, within the problem category, types can be printer, monitor, or processor.

• Product Group: a high level product categorization.

• Product: a sub-categorization within a product group.

• Mood: the email sender's general disposition, for example, upset, neutral or happy.

• Priority: the urgency of an email.

• Language.

  The language of the email is based on the mailbox setting. After the email is accepted, the owner can update the language.

While inbound email classification data is only editable by the email owner, the group worklist owner, or the mailbox owner, the classification data that is displayed on the Response page is always editable. If NLP is available for email processing, it returns suggested values for these classification fields, which are populated in the email accordingly. The email owner can modify any classification data when responding to the email. If NLP is unavailable, the email owner can enter classification values manually. Classification data is not required, but it helps the system to perform more effective search on correspondence templates or solutions.

See Setting Up Automated Mail Processing.

Classification Data Usage

Classification data is used in these areas:

• Recommending actions on the Email page based on the category selected for the email. You establish the relationship between categories and recommended actions to perform for categories at the mailbox level.

• Suggesting solutions and documents on the Email page and the Search Solutions/Documents page. NLP must be available for automatic suggestions on solutions and documents.

• Searching for correspondence templates on the Response page based on the available classification data.

If NLP is available to suggest classification data for the email, you can view the score of each returned classification type on the History page.

Assistance

The email workspace provides a central area where agents find ideas to resolve email issues. Before an email becomes available to the agent, it goes through a mail process that can return recommendations on actions and suggestions on solutions and documents (available with NLP). The agent can take the advice that is available on the email workspace, or reclassify the email to get new recommendation and suggestion.

There are three types of assistance:

Action Recommendation

Emails get action recommendations based on their category, which is retrieved either automatically by NLP or entered manually by agents. The system displays the recommended actions that are associated with the email category as specified in the mailbox definition. Changing the category in the email workspace updates the recommended action list.

Email workspace delivers three recommended actions:

• Respond to sender - transfers to the Response page to compose the email response.

• Compose auto acknowledgement - transfers to the Response page and applies the auto-acknowledgement correspondence template that is specified in mailbox definition.

• Close as duplicate - cancels the email setting and updates the status to closed - duplicate.

Solution and Document Suggestion

Available only with the presence of NLP, suggested solutions and documents appear as a result of content analysis. The agent can select items from the solution and document lists, which are then placed in content source list ready to be used in the email response. In addition, the agent can reclassify the email to refresh the lists or search for additional solutions and documents that are not on the lists.

Documents are defined using the correspondence template component. To make a document available for suggestion, select the Document check box and the ERMS Response usage in the template package where the template is selected.

Recent Activities

When this tab is displayed for the first time, it lists out recent activities that pertain to the email sender, for example, cases that have been created under the sender or associated email correspondence. In this tab, the agent can:

• Create, search for different types of transactions (that are enabled to interact with ERMS) and associate them to this email.

• Search for other emails that are related to this email and associate them to this email.

You establish a list of activities (transactions) that can be performed at the mailbox level, which becomes values of the Activity Type drop-down list box of the Recent Activities tab. In addition, set up the list of default activities that are retrieved every time the email is opened. Agents can personalize the default activity list in the User Preferences page and select the type of activities that they want to see in the results grid. The user-level preference overrides the mailbox-level definition for default activities if the former is available.

When the agent replies to the email with transactions or emails selected from the list, it causes the automatic association of the selected items to that email. Among the list of enabled activities that are specified in the mailbox definition, the actual values that are available in the Activity List drop-down list box are filtered by what the sign-on agent is authorized to access. For example, if internal helpdesk agents do not have the permission to access support cases that are external-facing, they cannot create or search for support cases from the email workspace even if the activity is specified in the mailbox definition.

Note. The ability to create new transactions is unavailable if users don't have the permission to create that transaction.

The agent can search for and relate other emails to the current email, which changes the thread association. When the association occurs, only one outbound email can be selected at a time. If the outbound email has other threaded emails, the system updates their relationship with the current email as well.

See Also

Setting Up Automated Mail Processing

Defining Mailboxes

Understanding Natural Language Processing

Content Sources

The email workspace collects information from content sources to build email response. There are implicit content sources that provide data to construct some portions of the response in a template format, such as the agent information for the closing part, the sender information for the greeting part and the email information for the email history part. For the content of the reply, it comes from these explicit content sources:

• Transactions that are enabled for ERMS.

  The concept of related transaction ensures that subinteractions are represented properly in the CRM system.

• Solutions.

  Solutions are thread-wide attributes, which means that when they are associated to the current email, they are actually linked to every email in the thread. So adding a solution to an email at any level associates this content with the entire thread.

When the agent works on the current email and selects solutions or related transactions on the email workspace, the system is essentially collecting content sources that can potentially be used in the email response. Collected items are displayed in the Template Search section of the Response page. Email workspace uses the selected content sources to refine the list of templates that are available in the Template drop-down list box for the agent to select. The selected items are also used as the content of the response to which one or multiple templates apply.

Similar to solutions, the agent can search for documents on the email workspace to be part of the email response. Documents are defined using the correspondence template package component and the behavior of selecting a document is slightly different from selecting a solution. When the agent adds a document to the proposed list, the system automatically populates the document in the Template drop-down list box, which the agent can apply to the response if applicable.

Solution and Document Search

Solutions and documents are the two types of materials that an agent searches for to resolve email issues. They are kept in separate repositories even though they act similarly in terms of searching behavior. When an agent performs a search, only one repository is being searched on at a time. The agent can set up email workspace preference to the default repository and other search options.

Autosuggestion is available with NLP. The email workspace presents a list of suggested solutions or documents (depending on the selected repository) when the agent accesses the Search Solutions/Documents page for the first time. The same list is also displayed in the corresponding tab within the Assistance group box on the Email page. The agent can select items from the lists and add them to the collection of attempted solutions and documents, which become content sources to be associated with the email and its response. Regardless of the presence of NLP, the agent can always perform keyword search that is run by Verity. Set up user preference and select the default search mode (basic, advanced or advanced with options) and additional search options, for example, word variation and number of search results to display.

Note. The email workspace prevents solutions and documents that have already been attempted from being added to the content sources list again.

Solution Status Update

After the agent sends the email response that is associated with solutions, the agent can come back to the email and update the solution status based on customer's feedback. The system populates the Attempted Solutions grid of the More tab on the Email page with a list of selected solutions that were attached to the reply. If the customer contacts the agent later on about that email and confirms how effective those solutions were in resolving the issue, the agent can update the solution status accordingly. The feedback is then submitted to the NLP system knowledge base for teaching and learning purposes.

See Also

Managing Inbound Email

Quick Action Buttons

The email workspace provides action buttons that allow agents to perform common email actions quickly. These buttons are context-specific; they appear in pages and sections where their operations are appropriate. These buttons represent generic email actions such as reply, reply all and forward, as well as other common actions that agents perform to resolve email issues, which are subcategorized into these types:

• System-wide actions. Examples are mark as spam and mark as duplicate. When the agent clicks any of them for an email, the email workspace updates the email's categorization information (spam or duplicate email), close it and removes its entry from the agent's worklist automatically.

• Transaction actions that are defined at the mailbox level. You can set up quick create action buttons for these types of CRM transactions to be created for emails if so configured: all types of cases, issues, orders and quotes, leads, opportunities, service orders, and service management objects. To minimize scrolling, PeopleSoft recommends that only one quick action button is specified for a mailbox. Scrolling is necessary if there are more than one transaction action button.

  Note. If the agent clicks an action button to create a transaction, the same operation takes place if the agent accesses the Recent Activities tab in the Assistance group box on the Email page and create the same transaction.

Related Transactions

Certain types of emails can be handled through a direct response—much as you might respond directly to someone who calls you on the phone. Other types of emails can be handled more effectively through other CRM transactions, such as cases or leads that provide full-featured handling of customer support issues or product inquiries.

Related Transaction Types

You can associate emails with these types of CRM transactions:

• Cases, including:

  • Support cases.

    These include standard cases and cases that are specific to industry solutions. Support cases are called issues when they are used in the financial services solution.

  • Both PeopleSoft Help Desk and Help Desk for Human Resources cases.

    If you use ERMS with either of these applications, pay attention when associating emails with cases. Associate email from external customers with support cases; associate email from internal employees with help desk cases.

• All types of captures in PeopleSoft Order Capture, including:

  • Orders and quotes (both standard and specific to the insurance solution).

  • Service management, start service, stop service, and transfer service transactions.

  • Product application.

• Leads.

• Opportunities.

• Service orders.

You can relate an email to an existing transaction or create a new transaction. For example, if a customer sends an email with a support question, you can create a new case for that customer. If the customer later sends another email related to the question, you can relate the new email to the case that you already created. (If the new email is threaded with the original email, the system automatically carries over the case relationship to the new email.)

When you relate an email to an existing transaction, the system displays the appropriate search page for the transaction type that you select.

When you create a new transaction, the system saves the inbound email before transferring to the new transaction. You can create new transactions only if the email sender is fully identified, otherwise the system gives an error and does not create the transaction. One way to verify this is by looking at the toolbar summary area. If the sender and the representing values are displayed as active links, that means the system has successfully identified the sender. If they are inactive, you must complete the identification manually before you can create transactions. For external mailboxes (in which case the email sender is customer), the system gives an error and does not create transactions if the setID of the customer does not match the setID that is associated with the business unit of the mailbox.

When creating new leads, opportunities, and service orders, the system does not transfer data from the inbound email into the new transaction. Other types of transactions, however, include some default data that comes from the email (unless the default values are invalid for the user's default business unit). For example, the system populates the email sender information, subject and body to new cases, and email sender to orders and quotes.

When possible, the system uses data from the email as default data in the search page and in new transactions. In particular, the business object associated with the email is the default contact, whether you search for an existing transaction or create a new one.

Note. Access to secured cases in PeopleSoft Help Desk for Human Resources is available only to users who are members of the provider group to which the case is assigned. Users, who do not have this access, do not have secured cases available to them when they associate emails with cases. If a secure case is already associated with the email, users who do not have access to the case cannot see the case subject or access the case details.

Security for Related Transactions

The security profile of users controls their ability to associate transactions with an email. For example, an agent who has security access to the support case component can also associate emails with support cases. In addition, the ability to relate or create transactions for an email comes from its mailbox. You specify at the mailbox level which CRM transactions agents can associate with and create for its emails in the Assistance group box on the Email page.

Because all types of captures use the same component, a user who has access to the component can create orders, quotes, and the various service-related transactions used in the industry solutions.

Email Replies

Agents reply to an inbound email through:

• The Response page of the email workspace.

  This page is used when the agent reviews an inbound email from the email workspace and wants to reply to it. It can be done by accessing the Response page within the same component). Or, when the agent works on a transaction and wants to reply to an email that is associated with the transaction, the Response page for the selected email appears.

• The Outbound Email component.

  This page is used when the agent works on a transaction and wants to create an email from that transaction (not responding to any email).

  The Outbound Email page is also used to view sent emails. Email approvers can access this page to approve emails from agents whose emails require approval before delivery.

They function in a similar fashion. They enable agents to:

• Compose a message using predefined correspondence templates or free-form text.

• Address the email and select the delivery channel (email or worklist) for each recipient.

  Normally, one sends the reply to the same address from which the inbound email was received, but if the agent copies other agents on the reply, the copies can be sent to those agents' worklists.

• Send the reply immediately or schedule it for future delivery.

  However, an agent who is associated with an approver (on the Agent Setup page) must submit the reply for approval instead of sending it. The system sends the reply only after the approver approves it.

  See Specifying User Settings.

See Also

Sending Manual Notifications

Replying to Inbound Email

Email Status Tracking

After an email arrives in a group worklist, its status is shown in the Status field. The agent assigned to an email can manually change its status in the email workspace. The system automatically updates an email's status when certain actions occur.

Note. The agent-facing email status is different from the process status that ERMS processes use.

See Email Process States and Incompletely Processed Email.

Email Statuses

There are three types of email statuses:

• Editable email status

  This is the set of statuses that agents can update and is available on the Email page under the Email Details section. Values are:

  • Open

  • Closed - Response

  • Closed - Canceled

  • Closed - Duplicate

  • Closed - Auto Response

• System email status

  This status set is maintained by the system and is not editable by agents. It's available on the toolbar summary area and the Message Detail page. The system email statuses are used in the interaction tree of 360-Degree View. Values are:

  Status	Description
  New	The Unstructured Email process assigns this status after routing the email to a group worklist but before the email is assigned to an agent. The Unstructured Email process sets this status automatically.
  Processing	This status is used to indicate that the system has not finished processing this email and cannot be accepted until the system has completed it work.
  Reassigned	The email is manually routed to a group worklist (either by requeuing or reassigning it), and it is not currently assigned to a specific user.
  Assigned	The email has been assigned to a specific user, but no reply has been sent. The system sets this status when the email is assigned to an individual, regardless of whether the user explicitly accepts the email or the assignment occurs by auto-acceptance.
  Completed	A user has handled the email and replied to it if necessary. The email workspace automatically closes the email after the user has submitted a reply on the Response page.
  Canceled	No action was required, and no reply was sent. Users can cancel email from the Inbound Email page.

• Process state

  Process states are statuses of the application engine mail processor in regards to the email. The Mail Reader process refers to the process state of emails when resending them through the system. It's available on the Message Detail page. Values are:

  • Email Instance Created

  • Queue for Routing

    The email is processed by the Mail Reader process but is not yet processed by either the structured or unstructured mail process (based on type of email).

  • Auto Responded by System

    The structured mail process responded to the email automatically.

  • Email Routed

    The email is routed to a group worklist and is ready for to be processed by the agent.

  • Mailbox Forwarding

    The mailbox reset functionality is performed.

The system allows you to close an email (as completed or canceled) regardless of whether any replies are sent. Normally, however, an email is closed after a reply is sent. If you suspect that additional correspondence is necessary to resolve an issue, you can use the email to create an appropriate related transaction, such as a case. The same set of values are used in interactions to represent email statuses.

See Reviewing Email Message Properties.

Email Status and Worklists

When viewing only ERMS worklist entries (and not ERMS alerts or all transactions), the worklist grid displays the email status; this makes it easy to see which emails are closed and to remove them all from the worklist at the same time. Sort the worklist grid by status to see which worklist entries can be marked complete.

The system prevents you from marking an ERMS worklist entry complete if the underlying email is not closed. This ensures that every email remains on a worklist until it is closed. (However, if you reopen an email after removing its worklist entry, the worklist entry is still marked complete. Do not rely on the worklist when working with reopened email.)

Reply Deadlines and Notifications

ERMS mailboxes and ERMS group worklists have a warning notification time period and a final notification time period. These are optional for group worklists but required for mailboxes. The ERMS Alert processes trigger notifications based on these time periods. The system sends notifications if an email is still open at the notification deadline.

Note. Replying to an email does not completely prevent the system from sending the alert notifications. Although an email is automatically closed when its owner performs a response, the agent can reopen the email. Notifications occur if the editable email status on the Email page is open at the scheduled notification time.

The system sends notifications to the group worklist owner if the email is associated with a group worklist; otherwise, the notifications are sent to the mailbox owner. Email alerts are always sent to worklists, never to queues.

When filtering a worklist by transaction type, the email notifications appear in the ERMS Alert Worklist (unlike email assignments, which go to the regular ERMS Worklist).

Warning notifications alert the recipient that the organization may miss a deadline, and final notifications alert the recipient that the deadline has arrived. Worklist notifications are calculated from the date and time that the worklist receives the email. If the email is reassigned to a different group worklist and then back to the original group worklist, the notifications are based on the most recent arrival time. Assignment of an email to an individual worklist does not affect the deadlines—nor does requeuing an assigned email back to its group worklist.

Worklist-level deadlines change as an email is reassigned to different groups. The deadlines represent the service organization's internal standards for timely replies.

Mailbox notifications are calculated from the time that the email enters the system. If the PeopleTools email table has a record of the time that the mail server received the email, that time is used. When the mail server data is unavailable (for example, POP3 mail servers do not provide this data), the system uses the time that the email was first saved in the PeopleSoft database. The delay between the time the mail server receives the email and the time that the email is saved in the PeopleSoft database depends on how often the Mail Reader process polls the mailbox.

Mailbox-level deadlines do not change as the email is reassigned to different groups. They represent the organization's external commitments for timely replies. The mailbox reset operation can affect the mailbox-level deadlines; the new deadlines are computed based on the time the email entered the system, not when the mailbox reset operation was performed.

The mailbox-level final notification time represents the final deadline for replying to the email. This deadline is the only one of the four notifications times that is visible on the toolbar; it is considered the email's due date.

All time periods are is calculated using a 24-hour clock, without regard to the organization's business hours. The warning dates and due dates (both internal and external) for these notification alerts are available on the Message Details page.

See Also

Worklists and Queues

The Email Alert Process

Setting Up and Using Worklists

System Information for Email Messages

Email workspace provides information that helps administrators to diagnose issues with emails from a system perspective. Similar to viewing the message source or message properties in other email systems, administrators can view email data that comes from CRM and PeopleTools in the Message Details page. They include the email status, state for the corresponding application engine process, email routing and assignment information, internal and external warning deadlines, message header details and various parts that constitute the email.

See Also

Reviewing Email Message Properties

Accessing Inbound Email

This section discusses how to:

• Access inbound emails from the worklist.

• Access inbound emails from the main navigation.

Note. You can also access an inbound email by navigating to it from the MultiChannel Console, by using an interaction list (for example, from the 360-degree view or in a transactional component's interaction history page), and on the Thread page of another email that belongs to the same thread.

See Also

Working with Interactions

Enterprise PeopleTools 8.45 PeopleBook: PeopleSoft MultiChannel Framework

Pages Used to Access Inbound Email

Accessing Inbound Emails from the Worklist

Access the Worklist page.

Worklist entries are associated with a specific worklist. Inbound emails that you have accepted appear in your individual worklist. Emails that have not been accepted appear in group worklists. Notifications related to email deadlines appear in the individual worklist of the group worklist owner or, if the email was never assigned to a group worklist, in the individual worklist of the mailbox owner.

Worklist entries are also categorized by transaction type:

• Inbound email worklist entries have the type ERMS Worklist.

  These entries represent email assignments; they are created when an email is assigned to a worklist.

• Notifications related to deadlines have the type ERMS Alert Worklist.

See Also

Setting Up and Using Worklists

Accessing Inbound Emails from the Main Navigation

To access inbound emails from the main navigation, use the Search Inbound Emails (RB_EM_IB_SRCH) component.

Access the Search Inbound Email page.

You can control the behavior and appearance of this page using the CRM search configuration utility. The search criteria fields and search results fields are the same as the identically named fields in the email workspace. Click each page within the search results grid to view corresponding values of the emails that return.

See Also

Configuring Searches

Working with Inbound Email

This section discusses how to:

• Manage inbound email.

• Find solutions and documents.

• Review email event history.

• Review email routing history.

• Review email audit history.

• Review email content analysis scores.

• Review email message properties.

• Review thread information.

• Reassign an email.

• Add email notes.

• Personalize email workspace.

• Submit email to another mailbox.

Pages Used to Work with Inbound Email

Managing Inbound Email

Access the Email page.

Toolbar Elements

The toolbar appears on all pages in the component. Many of the toolbar elements are standard for all PeopleSoft CRM toolbars. The following field descriptions describe only those elements that are specific to the inbound email. Some toolbar elements appear only in specific contexts.

The area beneath the toolbar button displays summary information about the email, which includes the email sender, email status, the computed email due date (based on the mailbox-level final notification time period. If the final notification time period for the email's mailbox is two days, then the due date is two days after the email was received), assigned agent and group, and customer value. The customer value comes from PeopleSoft Enterprise Performance Measurement. It appears if the sender is a consumer or the representing value is either a company or consumer.

See Understanding the Configurable Toolbar.

Email Message

This group box displays basic information and the content of the inbound email. It is displayed on the Email page, the Response page and the Search Solutions/Documents page to provide persistent email information wherever agents perform research.

Email Details: Main

This group box contains two tabs, Main and More.

The Main tab displays the email's status that agents work with. If NLP is installed and suggestions are available, the system prepopulates the categorization information accordingly. Agents can update these values manually.

The system provides action buttons to perform common email functions quickly. They can be defined at the system or mailbox level.

See Defining Products, Defining Template Categories and Types, Defining Priorities and Moods.

Email Details: More

The More tab displays customer information. It also lists any CRM transaction that the email is associated with or any solution that the email has attempted to resolve its issue.

Business Unit and Sender	Displays the email business unit that is specified in the mailbox definition. The email business unit cannot be updated; the only way to change this values is to perform the mailbox reset functionality and associate with a mailbox that has the desired business unit setting. You cannot create transactions from the email if the setID of the email business unit does not match the sender's setID.
Language	Displays the language to be used to handle the email. You can modify the value if the system identifies the language incorrectly.
Sender	Displays the sender of the email. If you select a different sender, the system automatically updates the corresponding value in the toolbar summary area. The role of the sender is shown if the selected sender has more than one role. You must identify the sender completely (by specifying the sender role) before attempting to create transactions.
Representing	Displays the company or consumer that the sender represents. If you modify the value here, the system automatically updates the corresponding value in the toolbar summary area. This field applies to external and partner mailboxes and is still displayed in the toolbar summary area even if the value is unavailable.
Related Transactions	Displays CRM transactions that are selected on the Response page to associate with the email, if available.
Attempted Solutions, Status and Update Solution Status	Displays solutions that are associated with the email. This grid appears after the email response, including selected solutions, is sent. Agents can update the solution status based on customer's feedback. The result is then submitted to the NLP system knowledge base for teaching and learning purposes. For example, if the customer sends a reply and confirms that the solution resolves the issue, the agent can select the solution and change its status to successful resolution. If the solution doesn't solve the issue, change the status to failed resolution instead. Click the Update Solution Status button to submit the result to the NLP system.

See Defining System Settings for Email Processing, Email Sender Identification, Quick Action Buttons.

Assistance

This group box provides agents suggestions to resolve issues raised in emails. Possible suggestions include activities, solutions and documents.

Contains a list of recommended actions for the agent to perform. The list is based on email category.

Contains a list of suggested documents recommended by automated mail processor (AMP), which is available only with NLP. Fields below appear if the system returns suggested documents.

Contains a list of suggested solutions recommended by AMP, which is available only with NLP.

Contains a list of most recent activities that are associated with the sender of the email.

See Also

Assistance

Content Sources

Solution and Document Search

Finding Solutions and Documents

Access the Search Solutions/Documents page.

This page is available regardless of the presence of NLP. However, the appearance of this page will vary slightly if NLP is not available. The Search group box does not have tabs because auto-suggestion is not available without NLP.

Proposed Solutions/Documents

This group box contains the collection of solutions and documents that can be content sources for the email (for example, to perform template search) and can potentially resolve customer issues. You can select items in the list to send to customers. Selecting an item means that you are adding it to the list of content sources to be associated with the email and its possible response. When you perform search on solutions or documents on the Email page or the Search Solutions/Documents page and click the button to add selected items to the proposed list, the system populates those items here in the Proposed Solutions/Documents group box.

Search

The group box contains two tabs, Auto-Suggestions and Search, if NLP is available. The Auto-Suggestions tab lists the suggested items for the selected repository (either solution or document) that NLP returns. The interface resembles the Suggested Documents and Suggested Solution tabs on the Email page. You can select items from either repository and add them to the proposed solutions or document group box. The Search tab allows you to perform keyword search by Verity. If NLP is not available, there are no tabs in this group box and the type of search you can perform is keyword search.

See Also

Solution and Document Search

Personalizing Email Workspace

Reviewing Email Event History

Access the History: Actions Taken page.

Actions Taken

This grid displays email history events that the system captures.

See Also

Understanding ERMS Setup

Reviewing Email Routing History

Access the History: Routing History page.

This Routing History grid displays email routing events. The system creates a new row of data every time the email is reassigned to a new group worklist or individual worklist.

See Also

Understanding Unstructured Email Routing

Reviewing Email Audit History

Access the History: Audit History page.

The Audit History grid displays record level and field level audit information, including the type of change performed (add, update, or delete), field values before and after the change, the user ID of the person who made the change, and the date and time of the change.

The PeopleSoft system is delivered with auditing features turned off. Turning on auditing can have a significant impact on application performance. Analyze your audit needs carefully to ensure that you turn on auditing only when there is a strong business reason to do so.

See Also

Setting Up Auditing for Cases and Inbound Email

Reviewing Email Content Analysis Scores

Access the History: Content Analysis Scoring page.

The Content Analysis Scoring tab is available if NLP is licensed. The scoring data for different email classification and assistance types is available only with NLP. AMP retrieves these threshold scores as a result of the content analysis that NLP performs.

Reviewing Email Message Properties

Access the Message Details page.

Computed Message Body

This group box displays essentially this same email message you see on most pages. The bigger display area allows for better readability.

System Disposition

This group box contains information about the email regarding status, routing, assignment, and response time deadlines that comes from the CRM system. It provides a visual indicator next to each response date and time that indicates if this email close to missing the deadline.

Message Header

This group box displays email data that comes from PeopleTools (with the exception of Mailbox ID field). The Date Sent and the Date Received values are followed by a number, which is the respective time zone offset.

See Enterprise PeopleTools 8.45 PeopleBook: PeopleSoft MultiChannel Framework

Multichannel Message Parts

This group box lists the message parts as stored by the PeopleTools Email Repository. A message part can be:

• The inline text, which can be a representation of the computed message body displayed on the left of the page.

• A sender specified attachment, which has a specific filename and content type.

• A PeopleTools generated attachment that is created when a system size threshold is violated (meaning that the size of the text exceeds the threshold value) or the content type is not plain/text. For example, if the mail client is configured so send both plain text and HTML email messages, two different parts appear in this section: a plan text part and an HTML part.

Reviewing Thread Information

Access the Thread page.

The construction of the thread tree on the left is based on the interaction thread information that is stored as part of a conversation. When you click an email link, the email content shows in the message area on the right. If you want to change the association of the current email (change email threading), perform the action in the Recent Activities tab on the Email page by relating the current email to another email as the new parent.

Reassigning an Email

Access the Select Worklist page.

Group Worklist Name	Select the group worklist where you want to reassign the email.
Individual (Optional)	Select the person in the selected group worklist to whom you want to reassign the email.
Reason	Select a routing reason. Use the following values for manual rerouting: Escalated, Misrouted, Overridden Reassigned, or Other. Other values that are used during automatic rerouting are also available. These values are Accepted, Bypassed, Encoding, Oversized, Requeued, and Routed.
Comment	Enter a comment that provides information about the reassignment. This is required if the routing reason is Other.
OK	Click to reassign the email to the selected worklist.

Note. Similar functionality is available on the Worklist page.

Reassign to Selected Worklist

If Verity returns worklists in the Worklist Scores grid of the History: Content Analysis Scoring page, the Reassign to Selected Worklist grid is displayed. From the grid, select a group worklist and optionally select a member of the group. The last row of the grid is a free form field where you can enter any group worklist and optionally select an individual from that worklist.

See Also

Reassigning Worklist Entries

Adding Email Notes

Access the Note page.

Here's some considerations for adding notes in the email workspace.

• You cannot email notes that you create for email

• Email notes don't use the visibility feature.

See Understanding Notes and Attachments.

Personalizing Email Workspace

Access the Email Workspace User Preferences page.

Message Action

General Setting

Document/Solution Search

Default Settings

Basic Search Options

Advanced Search Options

See Also

Understanding PeopleSoft CRM Searching

Submitting Email to Another Mailbox

Access the Mailbox Reset page.

Replying to Inbound Email

This section discusses how to:

• Reply to inbound email from email workspace.

• Send emails from CRM transactions.

• Send emails from CRM transactions that are associated with emails.

• Review outbound email.

• Review outbound email thread information.

• Review outbound email notes.

You can reply to email either from the context of the email itself, or from the context of a transaction that is associated with the email. The methods are similar, except that when you reply from a transaction, you must explicitly indicate that you are replying to an email. In addition, you must identify the email to which you are replying.

Pages Used to Reply to Inbound Email

Replying to Inbound Email from Email Workspace

Access the Response page.

Compose

If the system is unable to find any matching template for the email response when agents access the Response page, a warning message appears and the Template Search section is expanded automatically. The agent can modify the classification criteria and refresh the template list.

If you set up the system to request a note from agents after they send email response (including submit them for approval), it prompts the message whenever agents submit email. If agents are email owners, sending response automatically updates the email status to closed - response, removes the email item from the owner's individual worklist, and deletes the email task from the MCF console if the email was opened from the MCF console. In this case, the message about adding a note, if enabled, is displayed after these tasks are completed.

Sending Emails From CRM Transactions

If you click the Send Email button (or the Email button) on the toolbar from a transaction to send an email, the system either transfers you to the Outbound Email page to start a new email thread or displays a page, where you select to start a new thread or reply to an existing email of the transaction. If you select to reply to an existing email, the Response page of the email workspace appears. If you select to start a new thread, the Outbound Email component appears in the edit mode where you compose the new message. On the left of the Outbound Mail page, the transaction summary appears as a visual aid for the composition of the email. The transaction and the email classification data you enter all serve as inputs to the template search. Solution and document search is not available in the Outbound Email component.

Note. The Thread page is not available when you create an outbound email; you will see the information when you review the outbound email by navigating under Correspondence, Outbound Emails, Outbound Email.

Sending Emails From CRM Transactions That Are Associated With Emails

Access the Email Reply or Start New Thread page.

Email Operation

When you click the Email or Send Emailbutton on the toolbar of a transaction, you see this page if you previously navigated to the transaction from an email or if the transaction is associated with other emails. This button is available only if ERMS is licensed.

Note. This page does not appear if the transaction is not associated with any inbound emails. Agents are transferred to the Outbound Email page to start new email thread.

Reviewing Outbound Email

To search for and review outbound email, use the Search Outbound Emails (RB_EM_OB and RB_EM_OB_SRCH) components.

Access the Outbound Email page.

The Outbound Email component is in the read-only mode when you access it from the menu navigation. The interface is similar to the Response page of the email workspace. You can review the content of the outbound email and the corresponding inbound email. It also lists any related transactions and solutions for the email, and as well as the template used to format the final email body.

Email approvers uses the Outbound Email component to approve or disapprove emails. If you associate an agent with an approver in the system, it sends an action request worklist entry to notify the approver whenever the agent sends an email. The approver must approve the email before it is delivered. When the approver clicks the approval request link from the worklist, the system opens the email in the Outbound Email page. The approver can edit the subject and message before clicking the Approval button on the toolbar, or disapprove it. The email is sent when it's approved; if it's not, the system sends a notification to the agent indicating that the email has been disapproved.

For agents whose emails require approval before delivery, the Submit for Approval button appears on the Response page instead of the Send button.

Reviewing Outbound Email Thread Information

Access the Thread page.

The system uses the same Thread page for inbound and outbound emails.

See Reviewing Thread Information.

Reviewing Outbound Email Notes

Access the Note page.

The system uses the same Thread page for inbound and outbound emails.

See Entering and Viewing Notes.