Working in a call center is not for the squeamish. On an average day, an agent may handle up to one hundred or more calls from customers. On average, an agent only has 180 seconds to quickly identify the problem and resolve the issue. Needless to say, anything that helps speed up the process of identifying the issue and finding the corresponding resolution is welcomed — and that’s where Interaction Center (IC) alerts come into play.

The top portion of the IC screen contains a component called the context area, a set of three small screens that display important background information about the current customer and current customer interaction. The context area is always present on the screen regardless of what the agent is working on, and it displays a combination of information including customer name, informational alerts, and communication data. The account information and communication data let the agent know who they are talking to and how long they have been on the call. The alert area continuously provides the agent with real-time, context-sensitive information and advice.

Alerts can include free text as well as variables (i.e., attributes) that are dynamically inserted by the system at runtime. Using attributes allows for more powerful and flexible alerts compared to simple static messages. For example, rather than just using static text to indicate that a “Customer has open ticket(s),” you could create an alert using variables indicating that “Mr. Burton has two open tickets: #99801 (Very High Priority) and #99802 (Medium Priority).”

SAP delivers a significant number of out-of-the-box alert attributes organized into categories such as Current Business Partner attributes, Service Order Field attributes, System Variables attributes, and FactBase attributes. The Current Business Partner category contains variables such as Customer Last Name, Business Partner Name, and City. However, while SAP delivers many of these standard attributes, sometimes you still don’t find just what you’re looking for. For example, Customer Last Name is provided out of the box, but what if you wanted to also include the customer’s first name as a variable in an alert?

Not to worry — you can create your own custom FactBase attributes. All you need to do is write your own fact-gathering service (which is basically an ABAP class) to retrieve the desired data and store it in the XML FactBase. It doesn’t matter where the data is retrieved from — it could be from SAP CRM, SAP ERP, SAP NetWeaver Business Warehouse (SAP NetWeaver BW), Web services, XML documents, or anyplace else. In this article, we’ll show you how to create a new custom FactBase attribute to display the customer’s first name — that’s BP Name1 for all you technical folks (and computers) reading this.

Step 1. Create Data Collector Class

The first step to create and use a custom FactBase attribute is to create your data collector class. This class should contain the ABAP code that is responsible for locating, retrieving, and storing the data that you want to use in your custom attribute. The class retrieves the data from the location you specify and then stores the data in the FactBase XML document. Create your new class using the Class Builder tool, which is accessible from transaction code SE24. There are three important things to note:

1. The class must have the interface IF_CRM_SMF_SERVICE
2. Optionally, if you want your attribute to use business partner data (e.g., customer name, birthdate, and marital status), your class must be derived from the existing class CL_CRM_IC_F_G_BP
3. You must redefine and adjust the method IF_CRM_SMF_SERVICE~EXECUTE

In transaction SE24, create a new class implementing the interface IF_CRM_SMF_SERVICE. In our example, we are interested in using data that belongs to the confirmed business partner (e.g., customer first name), so we need to derive our new class from the existing business partner class CL_CRM_IC_F_G_BP (for more information, see the sidebar “Deriving a Class”). Therefore, we called our class Z_CL_CRM_IC_F_G_BP.

In the method IF_CRM_SMF_SERVICE~EXECUTE, enter the code in Figure 1. This gathers and retrieves the business partner information based on whatever business partner is confirmed at runtime by the agent in the IC.

 me->get_fb_attr_by_id 
( exporting id = 'BP_NUMBER' receiving value = lv_bp_str ).

Now you are able to get all business partner information that is needed. For example, you can retrieve the first name (Name1) of the confirmed business partner with a line of code like this: Select single name1 from but000 into lv_name1.

You must then export each piece of desired business partner information to the FactBase. In the example in Figure 2, we retrieved and exported the customer first name. However, you can retrieve and export additional pieces of customer data as well if desired.

Data: lv_value        type crmt_erms_string.    lv_value = lv_name1.    CALL METHOD me->set_fb_attr_by_id
      EXPORTING
        id    = 'ZBP_NAME1
        value = lv_value.

Note that you can enter any value you want for the FactBase ID (e.g., in our example this is ZBP_NAME1). This value will be used in step 3 for the Attribute ID when you create a new FactBase attribute. To finish this step, save your class.

Step 2. Create FactGathering Service

After you have created your new data collector class containing the necessary ABAP code to retrieve the data (i.e., customer first name), you need to create a FactGathering service that will map to the data collector class that you have just created. If you are not familiar with the Rule Modeler, it provides several different kinds of services, including FactGathering services, ActionHandling services, RuleInvocation services, and Utility services. Each of these has its own purpose within Rule Modeler applications such as the E-Mail Response Management System (ERMS) and Intent-Driven Interaction (IDI). FactGathering services are responsible for locating and retrieving data and then temporarily storing that data in a non-persistent XML document called the FactBase.

To view the list of available services or to create new services, use transaction code CRMC_ERMS_SM_SRV (or follow IMG menu path Customer Relationship Management > E-Mail Response Management System > Service Manager > Define Services). For each service that appears in the list, you can see the Service ID, Description, Service Type (e.g., FactGathering, ActionHandling), and mapped Service Class. The mapped Service Class points to the ABAP code that controls what that service actually does (e.g., retrieving data, auto-responding to a customer email, and invoking a new Rule Modeler policy).

To create a new FactGathering service, click the New Entries button. Enter a Service ID (e.g., Z_BP_FG_NAME1) and a Description of your choice (Figure 3). Select the Service Type Fact Gathering. Enter the name of the data collector class that you created in step 1, which is Z_CL_CRM_IC_F_G_BP in our example. Save your FactGathering service.

Figure 3

Create a FactGathering service

Step 3. Create FactBase Attribute

The next step after creating the data collector class and FactGathering service is to create the actual FactBase attribute that stores the value of the customer’s first name. Each attribute points back to an underlying FactGathering service. You can find a list of all available attributes grouped by the Rule Modeler application (Context) in which they are used in the Rule Modeler Repository via transaction code CRMC_ERMS_REPOSITORY (or by following IMG menu path Customer Relationship Management > E-Mail Response Management System > Define Repository).

To create a new attribute, first select the relevant context. Since you are working with IC alerts that are triggered via IDI, you should choose context ID ICRULE, which has the description Intent Driven Interaction (IC WebClient). After selecting this context, double-click the Attributes folder for a list of all available attributes for IDI. Click the New Entries button to begin creating your custom attribute.

In the Attribute field, enter the value of the FactBase ID that you created in step 1, such as ZBP_NAME1 (Figure 4). In the Fact Gathering Srvc field, enter the name of the FactGathering service that you created in step 3, Z_BP_FG_NAME1. Make sure that the Show Attribute check box is checked, as this controls whether the attribute shows up for selection in the Alert Modeler later. Finally, save your attribute.

Figure 4

Create FactBase attribute

Step 4. Create the Alert

The next step after creating your own attribute is to create the IC alerts that display the attributes. Alerts are created using a tool called the Alert Editor, which is available in the IC Manager role of the CRM WebClient UI.

To access the Alert Editor, log on to the CRM WebClient UI with the IC Manager role and select the menu option Process Modeling. Click the Alert link located under the Create header. Override the default proposal for the Alert ID with something more descriptive that you will later recognize (e.g., Z_BP_NAME1). Select the desired language and enter a description of your choosing.

In the Text area in the screen shown in Figure 5, enter the text that you would like to appear in the IC when the alert is triggered. In our example, we want to create an alert that will say “Hello” and address customers by their first name. Enter the text Hello (without any quotation marks) followed by an empty space. Then, open the left Attributes drop-down menu and select Fact Base. Then open the right Attributes drop-down and select the attribute you created in step 4, which is listed by the Description field value of Customer’s First Name (rather than by the Attribute ID value of Z_BP_FG_NAME1). Now, place the cursor back into the Text field at the position where you would like the attribute to appear (i.e., after the empty space after the word “Hello”) and click the Insert Attribute button. Save your alert.

Figure 5

Create alert

Step 5. Trigger Alerts

Once they are created, alerts are triggered using business rules maintained in the IDI context of the Rule Modeler. To access the Rule Modeler, you should once again log on to the CRM WebClient UI with the IC Manager role and select Process Modeling. Click the Rule Policy link located under the Create header. In the pop-up dialog, select the context Intent Driven Interaction (IC WebClient) and enter a name for your new Rule Policy. Then, click the OK button.

Before creating any actual rules, the first thing you should do is click the very first row in the table that contains the name of your rule policy. This brings up the Rule Policy Details, Business Roles, and IC Events areas (Figure 6). You must do two important things here. First, in the Business Roles area, click the Add Entry button. Select the agent-facing business role where you want your alert to appear. You can add additional roles if desired. If a business role is not explicitly specified here, the alerts will not be visible for that role. Second, in the IC Events area, click the Add Entry button. Select the IC event that you want to use as a trigger for displaying your alert. For example, if you intend to create a rule that triggers your alert after each business partner is confirmed by an agent in the IC, you should select the event Business Partner Confirmed.

Figure 6

Enter business roles and events in rule policy

The next step after creating the rule policy and entering the basic data is to create the actual rule (made of conditions and actions) that triggers your alert. Click the Draft Rules node in the hierarchy on the left side of the screen shown in Figure 6. Click the Subnode button to create a rule folder. Then click the Subnode button again to create an empty rule.

Enter a rule name and description of your choosing (Figure 7). In the Conditions area, click the Add Entry button to generate a blank condition (unless you are on the latest release version, where the system does this automatically). Then click the Value field and select your event (e.g., BPConfirmed). If you only assigned one event in the previous step, you only have one event you can select. If you entered multiple events, you should select the event Business Partner Confirmed.

In the Actions area, click the Add Entry button to generate a new blank action. Click the Actions field and select the action Trigger Alert. Click the Value field next to Alert Name and locate and select the alert you created in step 4. Click the More button on the toolbar, select the option Release Draft Rules, and then save your work.

Figure 7

Create rule to trigger alert

You are done. The next time an agent confirms a business partner in the IC, the agent will see an alert with the text “Hello [Customer First Name]” that displays the actual first name of the confirmed business partner (Figure 8). This is just one simple example of the many options you have with custom attributes.

Figure 8

Alert with custom attribute

Deriving a Class
You can derive class Z_CL_CRM_IC_F_G_BP from another class in the class builder (transaction code SE24). When you create the new class in the class builder, the popup shown in Figure A appears.

Figure A

Create a class

In this screen, specify the name of the new class. You can also specify a superclass by clicking the inheritance icon in Figure A. The inherited super class CL_CRM_IC_F_G_BP delivers the required interface and a set of business partner FactBase methods that you can reuse for your requirements (Figure B). Diving deeper into the specifics of this is beyond the scope of this article, but you can refer to SAP Help for more information.

Figure B

Add the superclass

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.

Frank Bregulla

Frank Bregulla is a technical solution architect in the consumer product industry area at SAP. He has been involved with SAP CRM since 1999 and delivers technical expertise for mobile solutions and the Interaction Center.

You may contact the author at frank.bregulla@sap.com.

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