Understanding Email Management
These topics discuss:
Agent tasks.
Editable information on the email workspace.
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.
Note: Throughout these topics, the term group worklist refers to both regular group worklists and MultiChannel Framework (MCF) queues.
Agents normally begin to work on emails after they are routed to the first group worklist.
Email Handling
When agents are ready to work on emails, they:
Access the email.
Typically, agents access email from either their worklists or from the Multichannel Toolbar. 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.
Accept ownership of the email.
Agents must be members of the group worklist to which emails are routed to accept those emails. 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 Toolbar, acceptance occurs automatically when the agent navigates to the email.
If the agent accesses the email some other way (for example, through My Worklist 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 Toolbar 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 My Worklist.
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.
Review the email on 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. Agents can enter the value manually as they set fit. 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 these materials in the email response. The system uses solutions that are added to the proposed list as the 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 to send. Documents are defined as correspondence templates in the system.
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.
Specify values to categorize the email.
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 this mailbox.
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 and associate it with 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.
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.
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 to 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 Toolbar, it is removed automatically from the task list after the agent sends a response.
Note: By default, the system asks agents if they want to enter a note after they have sent an 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.
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 these topics. This table summarizes the actions that are available to different users depending on whether the email is currently assigned:
User |
Actions If Email Is Unassigned |
Actions If Email Is Assigned |
---|---|---|
User who is not associated with the email's group worklist. |
No actions available. |
No actions available. |
Member of the email's group worklist. |
Accept the email. |
Take ownership or requeue email to group. |
Group worklist owner. |
Take ownership, reassign email, or requeue it to group. These users can also intervene if the email process is unable to route the email to a group. |
Take ownership, reassign email, or requeue it to group. |
User who is assigned to the email. |
Not applicable. |
Reply, reassign email, or requeue it to group. |
Note: From the email workspace, users must accept an email before reassigning it. From My Worklist, 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.
After accepting ownership of an inbound email, an agent can modify certain data, including the email subject, status, sender information, and thread information.
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.
Email Threading
An email thread consists of a beginning email (which can be 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 on 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 associates the current email to another email thread, the items that are associated with it (for example, solutions, documents, and notes) are all moved to the new thread.
The ability of the 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 appear), 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.
This topic discusses the fields that identify an email's sender and explains how these are populated.
Sender Identification Fields
These three fields on the email workspace identify the sender. These fields are located on the More tab of the Email Details group box on the Email page:
Field or Control |
Definition |
---|---|
Sender |
Identifies the person who sent the email. |
Representing |
Identifies the consumer, company, or partner company on whose behalf the email was sent. This information further quantifies the sender and appears under these conditions:
This field does not apply to internal mailboxes. |
Role |
Select the sender's role if the sender has multiple roles and relationships and the system has not yet identified the appropriate one for the sender. Choose from values such as individual consumer or contact of XYZ, where XYZ can be a company or a consumer. This is similar to the Role drop-down list box that is available in the 360-Degree View, with the exception that only valid ERMS roles and relationships appear as values. This field applies to external mailboxes only. This field does not appear after the agent has identified the sender role and saved the email. |
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 Email Page.
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 Customer Relationship Management (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 anonymous user that is specified on the Anonymous Object page of the Installation Options component 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 that 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 (because 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, the button label changes to Verified until the agent saves and exits the email. After that, the button no longer appears on the page. This button does not appear 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 emails of an internal mailbox 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 does not appear), 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 must 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 clicks 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 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.
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 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) from the email workspace.
Customer Quick Create
If the business object search cannot return a match from the database, agents can add new business objects using the quick create functionality, which include:
Create consumer.
Create consumer with contact.
Create company with contact.
Important! Only external mailboxes support quick create. Creation of workers are not supported.
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.
In an example where the system creates a case for an inbound email routed to a group worklist that has enabled the Create Case for Every Inbound Email option, the system uses the business unit that is specified in the group worklist definition as the business unit of the case. If this default value is not available, the system accesses the mailbox definition to identify an email business unit using the setID of the case customer, who is also the email sender (for external mailbox type), or use the default business unit that is specified in the definition as the email business unit (for internal mailbox types). Using the email business unit, the system identifies the business unit to use for creating support cases (for external and partner mailbox types), as well as the business unit to use for creating helpdesk cases (for internal mailbox types).
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. 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 quick create feature, the business object is created under the setID with which the mailbox's business unit is associated.
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.
An agent can change the business unit of an email , and the change is limited to business units that belong to the same setID as the current business unit. The also value changes 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.
This topic discusses how emails are sent to group worklists and individual worklists and discusses how emails can be rerouted to different mailboxes. The History page of 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 on the email workspace to process emails change after they are accepted. Before the acceptance, things that agents can perform on emails are minimal: accepting emails 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 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 appears 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.
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 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, if the Process customer response as new email option is selected at the system level. 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 process routes email C to the group worklist for email A.
Suppose that the Process customer response as new email option is selected, and the inbound email is associated with a case that is currently assigned to a provider group, the email process routes the email to the group worklist of that provider group.
If the option is not selected, the system routes the inbound email to the group worklist of the sender (an agent) of the previous outbound email.
Note: You may need to make the name of the process generic if the unstructured email process has been renamed or if it doesn't handle thread based email.
Routing to a Group Worklist
The 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 button on the My Worklist page or the Reassignbutton on the email workspace toolbar. 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 on 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.
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 toolbar.
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. 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 that 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 the toolbar of the email workspace or by clicking the Accept button on My Worklist.
A group worklist member or the group worklist 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 the toolbar of 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 email process routes an email, it sets one of these routing reasons:
Routed: The email is routed to a group worklist successfully. None of the other routing reasons apply.
Bypassed: The email is routed to the mailbox's default worklist because the mailbox's automatic routing option was not selected.
Oversized: The email is routed 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 that the system stores the content of an oversized 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. It sends the email directly to the mailbox's default worklist.
Encoding: The email is routed 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.
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 reprocessed by the ERMS 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, and assignments and statuses that are not New) of that email so that the mail reader process can process it as if it's newly fetched from the email server. This type of email has a special status, and the mail reader process doesn't get it from the mail server but from within CRM because this type of email is 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. Resetting involves the removal of some email data to complete the process and the operation, when finished, cannot be reverted.
Classification of emails is important when it comes to providing accurate recommendation of actions to resolve emails, and suggestion of correspondence templates to use in 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.
The classification data that appears on the Response page is always editable. The email owner can enter classification values as they see fit. Classification data is not required, but it helps the system to perform more effective searches on correspondence templates or recommend actions.
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.
Searching for correspondence templates on the Response page based on the available classification data.
The email workspace provides a central area where agents can find ideas to resolve email issues. Before an email becomes available to the agent, it goes through a process that can return recommendations on actions. Agents can take the advice that is available on the email workspace, or reclassify the email to get new recommendations and suggestions.
There are three types of assistance: action recommendations, solution and document suggestions, and recent activities.
Action Recommendations
Emails get action recommendations based on their categories. 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.
Note: You must specify a correspondence template in the mailbox definition to enable this auto acknowledgement action.
Close as duplicate: cancels the email setting and updates the status to closed - duplicate.
Recent Activities
When this tab appears for the first time, it lists recent activities that pertain to the email sender (for example, cases that have been created under the sender or associated email correspondence). On this tab, the agent can:
Create, search for different types of transactions (that are enabled to interact with ERMS), and associate them to the email.
Search for other emails that are related to the email and associate them with it.
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 on the Recent Activities tab. In addition, set up the list of default activities that are retrieved every time that 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 of 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.
The email workspace collects information from content sources to build an 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. As 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 with 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 appear 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.
Solutions and documents are the two types of materials that an agent searches for to resolve email issues. They are kept in separate repositories, although the ways to search for them are similar. When an agent performs a keyword search on solutions or documents, only one repository is searched at a time. The agent can set up email workspace preference to specify the default repository, default search mode (basic, advanced, or advanced with options) and additional search options (for example, word variation and number of search results to display) for document and solution search.
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 email workspace provides action buttons that enable 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. These common actions are subcategorized into these types:
System-wide actions.
Examples of system-wide actions are mark as spam and mark as duplicate. When the agent clicks any of these actions for an email, the email workspace updates the email's categorization information (spam or duplicate email), closes 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, and service orders. To minimize scrolling, PeopleSoft recommends that only one quick action button is specified for a mailbox. Scrolling is necessary if there is 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 creates the same transaction.
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.
Support cases.
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.
Orders and quotes in PeopleSoft Order Capture.
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 appear 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 a 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 the default data on 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 secured 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 abilities 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.
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. The agent can respond to an email 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 Notification 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). If the Use Email Workspace while responding to an existing notification option is not selected at the system level, the Outbound Notification page is used for responding to existing email from a transaction as well.
The Outbound Notification 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.
These pages 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.
An agent who is associated with an approver (on the Agent Setup page) must, however, submit the reply for approval instead of sending it. The system sends the reply only after the approver approves it.
After an email arrives in a group worklist, its status is shown in the Status field. The agent assigned to the email can manually change its status on 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 status sets:
Editable email status.
This status set includes statuses that agents can update. This status set 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. This status set is 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. This table lists the values:
Status
Description
New
The email process assigns this status after routing the email to a group worklist but before the email is assigned to an agent. It sets this status for the email 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 its 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 email workspace.
Process state.
Process states are statuses that the mail processor assigns to emails. The mail reader process refers to the process state of emails when resending them through the system. Process states are 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 mail route process (based on type of email).
Auto Responded by System.
The 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.
You can close an email (as completed or canceled) whether or not any replies are sent. Normally, however, an email is closed after one reply is sent. If you suspect that additional correspondence maybe necessary to resolve an issue, you can create an appropriate related transaction (such as a case) from the email prior to closing it out. The same set of values are used in interactions to represent email statuses.
See Message Details Page.
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.)
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 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 under the ERMS Alert type (unlike email assignments, which belong to the ERMS type).
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. The deadlines represent the organization's external commitments for timely replies. The mailbox reset operation, however, can affect the mailbox-level deadlines. The new deadlines are computed based on the time that 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.
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. System information includes 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.