E-Mail Response Management System (ERMS) within SAP CRM handles free-form emails as well as Web forms. Free-form emails often contain ambiguously worded descriptions, missing information, and sometimes even multiple, unrelated questions or issues. This reduces the effectiveness of your ERMS solution, resulting in reduced accuracy of automated responses and solutions. For example, if ERMS misinterprets the problem description, the solution will likely be sub- optimal. It also increases the workload for agents because the system cannot process the emails automatically.

By using Web forms instead of free-form email, you can increase the ability of ERMS to correctly categorize, respond to, and route incoming customer emails — resulting in increased first contact resolution and higher customer satisfaction. We’ll explain how you can use Web forms instead of free-form emails to increase your company’s ability to correctly respond to and route incoming customer emails with ERMS.

How Web Forms Work

Web forms are similar to emails, except that Web forms contain structured data rather than free-form text. For example, whereas regular email might report several issues or topics per email (or might contain insufficient information for a reported problem), a properly designed Web form ensures that every submission reports only one issue — with all the required information and details. Web forms can also provide greater convenience to customers, allowing them to report an issue directly from your corporate Web site without opening a separate email client application.

To submit a Web form, a user generally goes to an organization’s Web site (or other Web-based application) and fills out various fields, which could include text boxes; drop-down, multi-value list boxes; buttons; and check boxes. When the user clicks on the Send button, the Web form contents are submitted.

ERMS processes Web forms much the same as regular emails. To facilitate processing of Web forms, the system first converts Web-form data into standard email format (i.e., SMTP) with an XML attachment. Typically a Web-form scenario involves a Web application that hosts the Web form. When the Web form is posted from the Internet browser, the Web application that hosts the form converts the Web-form content into email format and forwards the email to ERMS.

Alternatively, the hosting Web application can submit the Web form content directly to the SAP ERMS Web Form Connector Business Server Page (BSP) application (CRM_ERMS_WF_CON). It in turn generates the email representation of the Web form and passes it to ERMS. This process of converting a Web form into email format is sometimes referred to as Web-form handling and the application that does the conversion is known as the Web-form handler.

This choice of processing is up to you. Most companies opt to do the conversion themselves, especially if they are running an external Web application outside of the SAP environment. The option to submit the Web-form content directly to the ERMS Web Form Connector makes more sense when you have copied and reused the SAP-delivered sample SAP BSP-based Web- form application.

Regardless of whether the Web application converts the Web form directly or whether SAP Web Form Connector does the conversion, the ERMS runtime engine handles the Web form email like any other email. The only difference is that for Web- form emails, ERMS uses a special fact-gathering service that reads the Web form data from the email and adds the data to the ERMS Fact Base. Regular emails use the fact gathering service FG_EMAIL, whereas Web form emails additionally use the fact-gathering service FG_WEBFORM.

The ERMS Fact Base is an XML document that stores information (referred to as fact-base attributes) about the email that the system is currently processing. ERMS uses the fact-base attributes (e.g., issue = crash, product = server X200) to trigger various ERMS actions, such as send an auto-acknowledgement and route email to, for example, server X200’s queue. Fact-gathering services, which are ABAP classes, collect this information by processing the email content. Either the ERMS Service Manager profile (based on IMG configuration) or the business rules invoke the fact-gathering services, which are necessary for any rule evaluation.

To evaluate any rule, the system has to check data in the Fact Base to determine if the rule condition is true or false. For example, if a rule condition says, “If customer correspondence language equals English,” then the system needs to retrieve the correspondence language of the confirmed customer from the business partner master data. This data is collected via a fact-gathering service (in this particular instance, FG_BP).

You have two options to invoke the required fact-gathering services. One option is to explicitly execute the relevant fact-gathering services for every email that ERMS processes. To do this, you include the desired fact-gathering services in the list of directly called services in the ERMS Service Manager profile in the IMG activity Define Service Manager Profiles.

The second option is to optimize performance by using “lazy invocation.” In this case, you don’t explicitly execute the relevant fact-gathering service for every email as part of the Service Manager configuration. Instead, you let the system execute the appropriate fact-gathering service when a rule contains a condition that requires a service. I describe these options in my article, “ERMS Under the Hood: Configuration Tasks and the Service Manager Profile”, which is available in the CRM hub of SAPexperts.

You may choose to execute mandatory services via directly called services in the Service Manager profile and to use lazy invocation for less frequently required services. In either case, the system invokes the required fact-gathering service — otherwise the system would not be able to evaluate any rules.

In situations in which a dependency exists between fact-gathering services, for example, when one service (e.g., service B) relies on data collected by another service (e.g., service A), you should use the first option above to explicitly execute both fact services in the desired order (i.e., service A followed by service B). Also, you must always execute the Web form fact-gathering service FG_WEBFORM explicitly — you cannot invoke it using lazy invocation.

ERMS Web Form Components

ERMS Web-form processing consists of three components. SAP expects you will want to write your own Web form and Web- form-to-email conversion applications. However, SAP does provide a sample Web form as well as a conversion program that you can modify and use if desired. The only one of the three SAP-provided components that you absolutely must use is the fact-gathering component.

External Web application. Typically a Web-form scenario involves an external Web application that hosts the Web form. The Web form normally contains a number of input fields depending on the purpose of the form. To later enable ERMS processing, certain fields are mandatory, including the Web form ID, “From” email address of Web form, ERMS email address, and sender/customer email address. SAP delivers a sample external Web application — BSP component CRM_ERMS_SAMPLE — that you can use for testing purposes (Figure 1).

Figure 1

Sample external Web application from SAP

You can copy and use the SAP sample Web application or use your own Web application. The SAP sample Web application uses BSP technology, whereas your Web application could be based on other technologies such as Sun Java 2 Platform, Enterprise Edition (J2EE).

Web-form to email conversion. You must convert the Web form to email before ERMS can process it. Technologies such as Sun JavaMail or Microsoft ASP.NET can perform the conversion as long as the resulting email contains an attached XML document with the following mandatory tags:

• : name of the Web form
  
  
• : ID of Web form email address as defined in the SAP CRM system (transaction CRMC_IC_AUIADDR); determines the “From” email address
  
  
• : ID of the inbound ERMS email address as defined in the SAP CRM system (transaction CRM_ERMS_OUTG_EMAIL)
  
  
• : email address of the individual customer/user

Figure 2 is an example of an XML attachment. Although the SAP-supplied sample Web form test application submits the Web form to the SAP ERMS Web Form Connector BSP application, a non-SAP-supplied Web application should convert the Web form to email format and then pass the email to the incoming ERMS email address.

Figure 2

Sample XML attachment

Web form fact-gathering service. When a Web-form-based email arrives in the ERMS system, the system parses the email contents, extracts the Web form values from the XML attachment, and adds them to the ERMS fact base. The ERMS generic fact-gathering service (ABAP class CL_CRM_ERMS_FG_WF) performs the extraction. SAP provides the ERMS fact-gathering service component.

Create Custom ERMS Web Form Attributes

You must define ERMS fact-base attributes for any fields that appear in your Web form — except, of course, for the mandatory fields mentioned in the previous section, for which SAP provides out-of-the-box fact-base attributes. You can define new fact-base attributes in the IMG via menu path Customer Relationship Management>Email Response Management System>Define Repository. Refer to IMG documentation for details. In your project, you can create additional fields such as State/Region, Zip/Postal Code, Product, Order Number, Question/Comment, Telephone, or Fax. Figure 3 shows a custom field, Subject, that we created for the “contact form” Web form.

Figure 3

Custom Web form field Subject

When defining new attributes in the ERMS Repository, it is important to select the Show Attr. check box if you want to make the attribute available in the Conditions area of Rule Modeler. If you want to use values from particular fields in your Web form for routing and other decision making, then you need to select this check box and then later include the attribute in rule conditions. For example, you could create a rule using the Priority field that routes high-priority issues to a special queue of agents that is staffed around the clock, whereas the system routes medium-and low-priority issues to the general queue that is staffed only during normal business hours.

When defining new attributes, you must specify the location of the attribute inside the ERMS Fact Base using an XPath expression. You should also specify the default fact-gathering service FG_WEBFORM in the Fact Gathering Srvc field as shown in Figure 3.

Web Form Set Up Checklist

Here is a checklist of tasks you must complete to include Web forms in ERMS. These tasks are in addition to the other regular tasks required to implement ERMS in general as described in the “ERMS Under the Hood: Configuration Tasks and the Service Manager Profile” article.

• Copy and reuse the SAP sample Web-form application (BSP CRM_ERMS_SAMPLE) or create your own Web form application
  
  
• If using your own Web-form application, the application is responsible for converting the Web form to SMTP email format
  • The email must have an XML attachment named WEBFORM.XML.HTM
    
    
  • The XML attachment must contain the mandatory tags , , , and
    
    
  • You must maintain the values for and in transaction CRM_ERMS_OUTG_EMAIL, which you can access via SAP menu path Interaction Center>E- Mail Response Management System>Settings>Maintain Sender E-Mail Addresses
    
    
  • The application must send the email (with XML attachment) to the email address maintained for the ERMS system (e.g., ERMS@. .r3.sap-ag.de)
    
    
• You must define your own ERMS attributes for any custom fields that you want to use in your Web form. SAP delivers four sample Web-form attributes WF_CNISS_COUNTRY, WF_CNISS_DESCRIPTION, WF_CNISS_PRIORITY, WF_CNISS_PROBLEM that you can use for reference. 

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.

Rai Ramprasad

Rai Ramprasad is a senior developer at SAP for the CRM development team in Palo Alto. Having joined SAP in December of 1995, presently Rai is engaged in the integration of rule framework in SAP CRM Marketing applications. He has experience in a wide array of technologies and applications: assembly language programming, real-time kernels to ABAP, and CRM on-premise and on-demand applications.

You may contact the author at r.rai@sap.com.

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