Are you interested in automating email and Web form processing in Interaction Center (IC) using corporate rules and standards? Then let me introduce you to mySAP CRM E-Mail Response Management System (ERMS), which allows you to route and handle incoming emails automatically based on predefined business rules. ERMS leverages two mySAP CRM tools: Rule Modeler and Category Modeler. These help business users set up rules to route incoming emails to the best processor and automatically respond to emails with appropriate solutions, documents, or templates.

Rule Modeler is a graphical modeling tool that helps business users compose rules for routing and handling emails without any knowledge of ABAP coding (or any advanced degrees in computational mathematics). Category Modeler lets users create structured hierarchies that you can link to CRM objects. For example, you can create hierarchies of products, defects, or damage codes to link to CRM objects, such as solutions or email templates, to enable automation of service scenarios in IC.

SAP ships ERMS with everything you need to create rules, including a repository of default attributes (used in rule conditions), logical operators (used to evaluate conditions), and actions (used to execute tasks based on conditions). I will explain the underlying technical architecture of ERMS and show you where to find detailed information about how to set up and configure ERMS. For a checklist of what you need to do to set up ERMS, see the sidebar, “ERMS Setup Checklist.”

Categorization and Content Analysis

The ERMS runtime engine can invoke various services, one of which is called content analysis. Using SAP NetWeaver’s Text Retrieval and Information Extraction (TREX) search engine, ERMS content analysis scans incoming emails and searches for certain keywords or phrases that you have assigned to categories in Category Modeler. Based on proprietary mathematical algorithms, TREX classifies the email. If the email matches one or more categories, various levels of automation are possible. For example, if the incoming emails contain certain keywords or phrases that indicate spam (e.g., “lose weight” or “hot stocks”), you can set up a rule to automatically delete the email or route the email to a special SPAM folder. You also can do this for out-of-office replies or other bounce-back notifications.

If the incoming email is from an existing high-value customer, but contains certain keywords that indicate anger or frustration, such as “horrible,” the system can route the email to an experienced agent with expertise in dealing with angry customers. On the other hand, if the same email comes from an unprofitable chronic complainer, the system can handle the email via an automatic response.

You can also use TREX content analysis and categorization to create and send reply emails with multiple mail-form templates automatically by linking the mail forms to categories in Category Modeler (Figure 1). ERMS provides various actions that you use to compose and send reply email to the customer automatically, with or without agent involvement. When the IC agent clicks on the Reply button in the IC E-Mail Editor, the auto prepare action automatically assembles a reply email for the agent. The agent can choose to modify the auto-prepared email or send the email to the customer as is. In contrast, the auto respond action automatically composes and sends a reply email directly to the customer without any agent involvement. Both auto prepare and auto respond contain a parameter for specifying an initial mail-form template to use in the reply email. Additionally, both actions also provide another parameter for specifying the category schema, which you can use to provide additional, more specific mail-form templates via content analysis and categorization.

Figure 1

Category Modeler category with mapped standard response mail form Click here to view a larger version of this image.

Figure 2

Create a mail form with reference to a specific issue via the mail form tool and link it to a category with Category Modeler Click here to view a larger version of this image.

You also can use Category Modeler to provide additional levels of automation in IC outside of ERMS. For example, if solutions from Solution Database are attached to a particular category and an IC agent assigns that category to a service ticket, the alert modeler triggers an alert informing the agent that solutions are available for the customer’s issue. When the agent clicks on the alert, the system takes the agent automatically to the selected solutions in the Knowledge Search screen. The agent can then add the solutions to the cart (without any need to search) and email the solutions to the customer.

Email Processing

IC offers two methods for processing emails. The first method is to use Integrated Communication Interface (ICI) and a third-party Communication Management System (CMS) to push incoming emails directly to available agents via a real-time screen pop. This means that the system displays the customer data on the screen as soon as it identifies the customer based on the email address. ERMS is not available with ICI push mode.

The second method is to send incoming emails through the SAPconnect interface, which routes the emails to the IC agent inbox. SAP built ERMS on this second method; ERMS is available only with this option. ERMS uses SAPconnect rather than ICI to process incoming emails. The system converts each incoming email into a CRM workflow work item with an attached SAPoffice document. When an IC agent processes the work item from the agent inbox, the system destroys the work item and a business document (such as an interaction record or service ticket) takes its place.

In mySAP CRM 4.0 Add-on for Service Industries and mySAP CRM 2005, SAP does not provide out-of-the-box functionality for pushing ERMS emails to CMS with a real-time screen pop. However, some users have configured their own ERMS push action. Additionally in SAP CRM 2006s, SAP provides a new ERMS push action that allows third-party CMS products to leverage ERMS pre-processing capabilities (such as auto-acknowledgement) by first sending an incoming email to ERMS through SAPconnect and then passing the email to CMS for routing and further handling using routing rules defined in the third-party CMS system.

ERMS email processing works as shown in Figure 3:

• An inbound email arrives in the SMTP-compliant mail server and goes through the TCP/IP port and Internet Communication Manager (ICM) SMTP plug-in.
  
  
• The email arrives at Web AS (6.10 or higher) via the SAPconnect interface.

Figure 3

ERMS email processing (technical stack)

This process is the same for both normal IC agent inbox and ERMS emails. An experienced Basis consultant should configure it.

Technical Setup

Now the interesting stuff begins. First, inbound ERMS emails call the IFRECEIVE interface of Business Object Repository (BOR) object ERMSSUPRT2 (whereas regular agent inbox emails use BOR object ICAUISUPP). Based on the email address mapping maintained in transaction SO28, the inbound distribution function invokes receive method ERMSSUPRT2 (ERMS support 2). That in turn creates a type SOFM (email document) BOR object and an SAPoffice document that represents the email (Figure 4).

Figure 4

Inbound ERMS email addresses mapped to BOR object ERMSSUPRT2 (ERMS support 2) in transaction SO28

After selecting ERMS support 2, choose the ReceiverAddress that you defined in transaction CRMC_IC_AUIADDR (Figure 5). Next, the receive method of ERMSSUPRT2 calls the function module CRM_ERMS_RECEIVE_DOCUMENT, which triggers mapped workflow ERMS1 via the BOR event MailReceived.

Figure 5

Select the ReceiverAddress

The workflow ERMS1 contains three tasks. Do not modify the workflow tasks. You must make all changes to ERMS technical processing in the Service Manager profile, which you access via the IMG by following menu path SAP Implementation Guide>Customer Relationship Management>E-Mail Response Management System>Service Manager>Define Service Manager Profiles.

Service Manager loops through the directly-called services, which typically include fact-gathering services for content analysis, Web forms, service tickets, and the rule execution service (Figure 6). The fact- gathering services retrieve contextual information and make it available in an XML document called the fact base.

Figure 6

Service Manager profile contains a list of directly called services which the system invokes in order as specified in Define Service Manager Profiles configuration

The rule execution service checks for an assigned Rule Modeler policy and then executes the programmed rules, accessing contextual data from the fact base as needed. The system assigns the Rule Modeler policy as a property of the RE_RULE_EXEC service in the Service Manager profile, along with the default routing (DEF_ROUTING) location and log level (Figure 7).

Figure 7

Rule Modeler policy assigned to RE_RULE_EXEC service of the Service Manager profile

If necessary, the rule execution service can invoke fact-gathering services that were not invoked directly earlier — this is referred to as “lazy invocation”. Say a rule contains a condition that requires data that is not available in the fact base because the system has not called the associated fact-gathering service. ERMS invokes the required fact-gathering service, even though the service was not explicitly assigned to the Service Manager profile. For performance considerations, SAP recommends you assign the most commonly used fact-gathering services directly and call occasionally used fact-gathering services via lazy invocation.

The system executes actions at the end of rule evaluation. The system also may execute actions while it evaluates them, depending on the configuration in ERMS Repository. For each action, you can specify whether the system should execute the action at the end of rule evaluation (default setting) or whether you want to execute the action immediately (Figure 8).

Figure 8

Configure whether the system executes ERMS actions immediately or after rule evaluation

For most situations, the recommended practice is to wait and evaluate all rules before executing any actions. In mySAP CRM 2005 and later, you can use the ERMS conflict resolution feature to decide how to handle situations in which the system invokes the same action twice, but with different values. For example, if one rule says to route an email to first-level support, but another rule says to route the email to second-level support, you can use the conflict resolution settings to determine how to proceed.

Next, specify how you want the system to handle conflicts by using ERMS Repository, which is the collection of attributes, operators, and actions that you use to create rules via the Rule Modeler. Access ERMS Repository by following menu path SAP Implementation Guide>Customer Relationship Management>E-Mail Response Management System>Define Repository. For each action in ERMS Repository, you can specify whether the system should handle conflicts based on the first occurrence of an action, last occurrence, any number of occurrences, occurrence with highest priority, or even by custom coding in its own ABAP class. You need to exercise common sense, however. For some actions that manipulate a partner function, such as route, the last occurrence overrides any previous occurrences, even if you choose the Any Number of Occurrences option. For example, the system sets the processor based only on the last occurrence.

Also, you can perform the delete action only once, so regardless of the conflict resolution setting, the system performs this action on the first occurrence only (Figure 9). If the system triggers a routing action, workflow task 00200136 (ERMS routing) determines the responsible agent for the work item via function module CRM_ERMS_AGENT_DETERM1.

Figure 9

Conflict resolution allows you to specify whether the system should decide conflicts for each action based on first occurrence, last occurrence, or a custom ABAP class

After the IC agent processes the email work item, the system creates a CRM business document (e.g., service ticket or interaction record) and terminates the workflow. The system saves the SAPoffice document representing the email with the CRM business document (i.e., interaction record or service ticket) and the work item is set to complete.

ERMS Setup Checklist
Here is a checklist of tasks you must complete in mySAP CRM to use ERMS.

John Burton

John Burton is a director of product management at SAP and is responsible for the SAP CRM Interaction Center (including ERMS) and social CRM topic areas. John has 13 years of experience at SAP and has been involved with SAP CRM and the Interaction Center since 1999. He is also the author of Maximizing Your SAP CRM Interaction Center, available at the SAPinsider Store. John is an alumnus of the University of Michigan and Central Michigan University. John can be found on LinkedIn at www.linkedin.com/in/sapjohnburton.

You may contact the author at john.burton@sap.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.