SAP CRM

RTOM Real-Time Offer Management Technical Setup

2012-03-07T12:00:00.000+01:00

Cross and Up selling have been part of the CRM solution for many years. Only recently Real Time Offer Management has been added. What does this tool bring our customers? From the SAP website we find:

“The SAP Real-Time Offer Management software is an advanced analytical real-time decision engine that enables you to optimize any decision-making process, such as for cross-sell and up-sell offers, retention, service-level adherence, and lifetime value boosting. The software takes into account all relevant information, including up-to-the-moment interaction information, to help you to take the most appropriate next action to enhance customer relationships on all customer interaction channels”

In this weeks blog we will show you what you need to do to through the technical set-up. This is the set-up needed for standard CRM integration. For Utilities integration additional steps are required.

In a next blog on RTOM we will go in to the full functionality of RTOM. The versions that are used are CRM 7.01 and RTOM 7.1

Installation

The RTOM Solution needs to run on a Microsoft Server. We leave this to the basis guys. The URL will look something like: http://hostname/RTOMAppsToolkitWS/Applications/Login/Default.aspx

We will need a URL to the RTOM toolkit and a username and password.

For the setup we will need to edit the data sources and the landscape configuration. Before we can do that we need to prepare CRM for the connection.

Activate business functions

To use SAP Real-Time Offer Management, you must activate the business function SAP Real-Time Offer Management (CRM_RTOM_1). Also, business function CRM_SLS_SRV_1 should be active.

Setup connection with SAP CRM
Within CRM we need to create a system user to provide access to CRM from RTOM.

RTOM connects to CRM via web services. for the following web services, we have to create or edit endpoints, using transaction SOAMANAGER. In this transaction go to single service configuration and create or check the following services:

Service ==> Name of endpoint

/CRMWST/ROM_PRODUCT ==> CRMWST_ROM_PRODUCT

CRM_FDT_READATTR_WS ==> CRM_FDT_READATTR_WS

CRM_FDT_READRULE_WS ==> CRM_FDT_READRULE_WS

CAMPAIGNCRMBYIDQUERYRESPONSE_I ==> CAMPAIGNCRMBYIDQUERYRESPONSE_IN

CRM_MKT_RTOM_WS ==> CRM_MKT_RTOM_WS

/CRMWST/ROM_AGENT ==> ROM_AGENT

/CRMWST/ROM_ACCOUNT ==> ROM_ACCOUNT

/CRMWST/ROM_SALES_ORDER ==> ROM_SALES_ORDER

CRM_IC_RE_WS ==> CRM_IC_RE_WS

/CRMWST/ROM_TELCO_ORDER ==> ROM_TELCO_ORDER

To link RTOM to CRM we need to enter the URL to the web services in RTOM. This URL we can get in the SOAMANAGER. To find the URL-location, in the opened XML code find the value “soap: address location”. The URL will look like htt://host:port/sap/bc/srt/rfc/crmwst/rom_agent/client/romagent.binding Now that the bindings are created, we need to activate the generated services. This can be done in SICF. Navigate to the binding service, right mouse click on it and say activate.

Now that the landscape part on CRM is done we need to tell RTOM how to connect to CRM. So logon to RTOM and go to both Landscape en Data Sources. Here we have to assign some web services of CRM that are called by RTOM. Initially the URL locations and user details are empty. The datasource service “RTOMwrapperforSAPIC_WS” is a special one. It refers not to a service of CRM, but a local RTOM service where we should define the user name and password of RTOM.

SAP CRM: Proxy settings

In order for CRM to call the RTOM web services we need to activate a couple of proxy's. These proxy's call webservices in RTOM. We need to create the logical port for below two proxys.

Proxy: CO_OFFERSERVICE_SOAP

Name of logical port: RTOM

Path: /IngeneoSAPICSiteAdaptorWS/Service.asmx

Port: 80

Proxy: CO_OFFERRTOMPUBLISH_SERVICE_SO

Name of logical port: RTOM

Path: /RTOMPublish/Service.asmx

Port: 80

Again we use transaction SOAMANAGER to create or maintain these logical ports. Go to (single) web service configuration and then Search by ‘Consumer Proxy’ and search term SOA.

For both proxys we need to go to the ‘Consumer Security’ tab and select ‘No Authentication’ Then go to the messaging tab and for the ‘Message ID Protocol’ select ‘Suppress ID Transfer’ from the drop down list. For the “Transports Settings’ we need to set the path, Computer Name (hostname), URL protocol (HTTP), Transport Binding type (SOAP 1.2) and Maximun wait for WS Consumer (1000).

For the publish-proxy CO_OFFERRTOMPUBLISH_SERVICE_SO we also need additional operation settings: For the Publish and CheckRule operation we need to link to an SAP URL. Also deselect the check box

Queue processing

One of the nice features of RTOM is the learning part. After each advice of RTOM the agent can send feedback to RTOM on how the advice was received by the customer. This feedback comes into CRM via an inbound queue. Queue registration is to be set in transaction code SMQR. Register queue RTOM* with the default values.

To be continued...

Using LinkedIn to automatically update SAP CRM

2012-02-29T12:00:00.000+01:00

In last week’s blog, we mentioned the different kinds of Social Media solutions that SAP provides and one that we at Acorel developed ourselves: LinkedIn integration with SAP CRM. As promised this week’s blog goes a bit more into the details of this LinkedIn solution.

Since LinkedIn has valuable information about your contact persons or customers, it might be useful to capture this information and store it on your CRM business partners. Just think of all the extra segmentation possibilities! Since you have to get granted access to this information, you must offer your customer an advantage to why he should grant you this.

Now there is the catch! If you have a portal or webshop where your customers have to login, you can provide them the same access, only they use their LinkedIn credentials to log in. And let’s be honest, everybody remembers their LinkedIn credentials.

So, what do you need for this?

First of all, you need the following components:

LinkedIn developer access
A SAP Java stack such as a Webshop or Portal
SAP CRM
Common sense

Tasks in the Java system

The main goal is to map LinkedIn- user’s memberID to the userID of the person that is logged in. Therefore the customer must first provide his/her ‘normal’ credentials and then click on the button ‘Connect your LinkedIn’.

This first triggers the ‘normal’ authentication flow that is used by the web shop. Then the system catches the user (his password cannot be caught) and fires the LinkedIn authentication.

The following diagram shows the necessary steps:

Step 1 and 2: SAP will first request an access token from LinkedIn by setting up an OAuth connection. There are a number of libraries to do this, in this case the signpost library was used.

Step 3 and 4: The customer then gets a question to grant your application access to use his LinkedIn information (this is the actual gold!!)

If he grants this access, SAP gets an Access token from Linkedin. This Access token allows SAP to retrieve detailed information about the LinkedIn-user. The token will stay valid until the user revokes the permission.

Step 5 and 6: The following snippets show how the Access token is used to retrieve and store LinkedIn data:

After the requested data has been parsed, it can be saved into SAP using a trusty old JCO Function Call

Lessons Learned Java

That sums up the work needed in the Java stack. There are a number of catches though:

Library availability for your platform: An Oauth connection can be tricky to set up, so you really need to use an external library. We however found that most Java based libraries need Java 1.5 and up, while the SAP Web shop still uses trusty old Java 1.4.2. We employed some tricks and wizardry to get it working.
System Time Settings: Make sure that the time settings on your Java stack are current and aren't off by more than 5 minutes. Any more than that and LinkedIn will refuse any requests for security reasons, but without a clear error message!

Tasks in the CRM system

As most of the information coming from LinkedIn will not fit in standard SAP CRM fields (think of current employer, last employer etc), we decided to save the retrieved information in custom tables that have been appended to the Business Partner, using the Easy Enhancement Workbench (EEWB) or Application Enhancement Tool (AET).

The table contains the actual LinkedIn user information, but also his authentication key and identifier:

To enable the customer to continue, he will log in to the web shop using an initial password that replaces his original SAP password. Therefore he can not use his SAP password again, and is forced to login using LinkedIn, or request a new password.

This whole flow wouldn’t make any sense, if the information isn’t shown anywhere. Therefore we made the fields available as an assignment block on the Business Partner overview in the CRM Web UI.

The first block in the screenshot is always available and can be automatically updated as long as the customer has still granted you permission. The second one is an online view of the public profile of the customer.

Conclusion

So, you question: “What is the use of it, if you have captured this information once, while in the current fast-moving world everybody changes jobs once every 3 years?”. LinkedIn provides the possibility to do an update of up to 100.000 profiles every day! So, if you have less than this amount of BP’s, you could update all of your Business Partner’s daily!

Oh and by the way, we can do this trick with the Facebook login as well!

Wanna get Social...?

2012-02-22T12:00:00.000+01:00

“If Facebook would be a country, it would be the 3rd largest country in the world!”… and among its inhabitants there are a lot of customers, prospects, suppliers and competitors.

The last few years a shift has taken place in the area of (marketing) communication. The user is becoming more and more the central point and with this gained a more active role in the creation, circulation and interpretation of media content. The rise of social media is a development which pushes us to take another look at the way we use of SAP CRM. Responding to ‘buzz’ and using social networks proactively is the way forward!

From Social Media…

The term Social Media is not yet included in our (Dutch) dictionary. But if it would be included, the definition would be something like this:

So-cial Me-dia the; pl Online platforms or networks where members, with or without the intervention of a professional editor, create, maintain and share content.

Twitter, LinkedIn and Facebook are without a doubt the most known social networks. But for instance article reviews on eBay are a form of Social Media too, as well as the posts on a consumer forum. A lot of consumers share their experience with products or services here.

…to Social CRM

Geographical borders do not exist on the internet and with the emergence of Social Media finding friends, people who think alike, reviews, advice and answers only becomes easier. The opinion of, sometimes, total strangers can prevent or stimulate the purchase of a certain product. Are you looking for a specific TV and you only find negative reviews on the internet, then you probably will not buy the TV or at least get some doubt. And 15 years ago “Uncle Bob” was the man for advice on buying a new car; now the opinion of “car_lover_78” on the Top Gear forum has more value.

Traditional marketing is sender oriented where you as an organization are the sender. In the Social Media era this is where the danger is lurking, because on different online platforms people are talking about your organization, your products and services without you being involved or even being aware!

The solution is quite simple: as an organization you have to be present on Social Media proactively, so that you are aware on what is being said about your products. This “buzz”, positive or negative is all free advice! And are chances to respond to them and start the dialogue. Besides that you can check which persons are considered as influencers. Think about starting a relation with these persons! Where 15 years ago Ford would send all the information about the introduction of a new car to “Uncle Bob”, now a days it would be far more interesting to share this information with “car_lover_78”.

… to Social SAP CRM

Naturally SAP recognizes the increase in power of this communication channel as well. That is why they have developed three Social Media solutions:

Target Marketing via Facebook business add-on by SAP
Twitter Customer Service business add-on by SAP
Twitter Marketing Campaign business add-on by SAP

We at Acorel created a fourth one, which we call ‘LinkedIn Integration with SAP CRM’.

On Facebook you can use Target Marketing via Facebook to ask your customers to install your Facebook App (Like your fan page). They can use this app within Facebook to check e.g. their account settings and order history. You can start specific loyalty programs for your Facebook friends; the customer receives an extra discount when he or she promotes one of your products or your App to their own Facebook friends.

Imagine that people are complaining on Twitter about one of your products. With Twitter Customer Service you are able to respond to these complaints without leaving the comfort of the SAP CRM environment. And thus be able to help the customer using the same communication channel. This SAP solution makes it possible to filter Tweets on predefined sentiments and respond to these tweets by creating a tweet or direct message yourself. For a complaint you can create a service ticket within this Social Media Cockpit and this service ticket is then handled via the standard SAP service process.

Besides pulling data from Twitter, you can also use the medium to push content like a marketing campaign. So besides the traditional call center team and e-mail campaign, also a tweet is published on Twitter by using the Twitter Marketing Campaign solution. When your campaign is successful your tweet will be retweeted by your followers thus the reach of your message increases and the number of potential responders increases as well. The impact of your campaign and the comparison between the different channels can be displayed in the Social Media Cockpit.

The solutions which SAP is providing until now are only for Facebook and Twitter, but what about the third one in the “Big Three”…LinkedIn…?

LinkedIn is a real steady network especially in the Netherlands and more important the profiles on LinkedIn are maintained pretty well by its users. At Acorel we thought about where SAP CRM could meet LinkedIn in such a way that both the “company using SAP CRM” as the “people using LinkedIn” would benefit from the integration.

Our answer: making it possible for people to login with their LinkedIn credentials on a SAP CRM Web shop.

With this solution a company can provide the customer a simple way to access their products or services offered on the SAP CRM Web shop; they do not have to remember or search the specific web shop credentials anymore. And the company itself gets a ton of profile data that is probably better maintained then on the web shop itself, which can be used to target the customer even better!!

In next week’s blog we will go into more detail of this LinkedIn – SAP CRM Web shop integration. Share some of the technical challenges and show you the result.

To end this blog I just need your answer on the title question; …so, are you gonna get social…?

ERMS routing in detail

2012-02-15T12:00:00.000+01:00

In last week's post, I discussed the working of the ERMS1 workflow and how the workflow works together with the rule modeler and the ERMS service manager.

I ended the post with a few complexities that might occur when using ERMS in an Interaction Center context.

Let's take a look at them one by one.

What if a user moves from one department to another?

'Why would this even be important?', you might think. This is important, because in standard ERMS, the agent assignment is done upon receiving the email. This means that if a user moves from one department to the other, despite the change in the organisational model, the emails assigned to the agent, will keep being assigned to the agent. Still no real harm done. New emails will flow into 'his inbox' correctly based on his new assignment. This is no surprise when you think of an email as a workflow item. If you think of an email as a communication item that needs to be processed by 'someone from the department it is meant for', this seems kind of strange. Also note that it is the same the other way round. A new employee in the department will not automatically see the emails that were received before his assignment in the organisational model.

What if you use ERMS in a B2C (Interaction Center) environment?
In the Interaction Center, email workflow items are processed using the agent inbox (former Universal Agent Inbox). The agent inbox (apparently) has quite some ERMS-specific logic, and it seems SAP has been struggling with exactly the issue as described above. Would you see an email as a a workflow item, or a communication item that needs to be processed by a group of people?

What happens if I use 'My Groups' in the IC Inbox?

This is what happens in the B2C environment:

The email is received.
The workflow is triggered
The servicemanager is called
The ERMS rule policy is processed
The agent determination is performed

As the IC Inbox is based on searching for emails, you can then search for email items assigned to 'me', 'my groups' and to specific organisational units.

If you would have the agent inbox search for 'open emails assigned to me', this would be fine, but if you choose to search for emails assigned to a specific org unit or 'my groups', what the system automatically does, is determine the relevant group(s), then determine all agents assigned to the group, and then determine all emails assigned to all the agents.

This means, that emails could be mixing up between the Agent Inbox groups when agents are assigned to multiple organisational units or when agents are moved from one department to the other.

Also take a look at note 1375170. This note implements a change in the workflow so that the determined organisational unit is also saved to the workitem description. The organisational unit is mapped to a variable that can be used in an implementation of the before_search badi of the CRM_IC_INBOX_BADI badi.

How does the IC Inbox cope with all the workitems waiting to be processed?

Before implementation of note 1375170, when changing the organisational assignment of a user, all emails that have been determined for this user in the workflow, will stay assigned to the agent.
After implementation of note 1375170, when searching for emails assigned to 'my groups', the selection will change when the agent's organisational assignment is changed.
For non-interaction-center users, emails received and assigned to the agent will stay assigned to the agent, even after a change of the organisational assignment.

So... when implementing ERMS, I would recommend to always also implement note 1375170. This will improve both the functionality and the performance of the agent inbox.

ERMS under the microscope

2012-02-08T12:00:00.000+01:00

When implementing ERMS, part of the work is to implement a workflow called ERMS1. Another part is to implement routing rules in the IC Manager as well as set up the ERMS Service Manager. The two apparently are more interdependent than I would have thought.

Workflow Task 'Invoke ERMS service manager'

When you look at the workflow, its functionality lies in the ERMS Service Manager node (task TS00207915), where using BOR object ERMSSUPRT2, several functions are performed, like interpreting and mapping of the data from the email to the BOR container.

During this step, the ERMS Service manager is also determined and executed.

The ERMS Service Manager is actually a customizable pile of functions that can be changed in the IMG

SAP Customizing Implementation Guide --> Customer Relationship Management --> E-Mail Response Management System --> Service Manager

We have already seen how the service manager works in the blogpost about IDI. The services consist of Fact Gathering, Rule Invocation, Action Handling and Utitlities.

The standard SAP ERMS service manager profile consists of 6 services.

The SVC_PARAMS actually does nothing.

The FG_WEBFORM is a service that is able to read an attachment called WEBFORM.XML, and maps the contents of the XML to the factbase (enabling use of the data in the rule modeler)

The UT_WORKITEMTEXT is actually a strange one (being a Utility maybe explains it), because this one updates the workitem that has been created. The workitem is yet to be assigned though.

The RE_RULE_EXEC is the rule execution service that consumes the rules as applied in the IC Manager. This service reads the rule policy and runs the rules that have been applied there, which might be for instance forwarding the email, which in its turn is actually another service, AH_ROUTE to be precise. Even though we would expect this to actually handle the routing of the email, it doesn't. It only checks if an organisational unit has been mentioned in the rule. The actual forwarding is not done here.

The AH_DEF_ROUTING actually checks if a ROUTE or ROUTETORESP etcetera has been applied in the rule modeler, and also does not really forward the email.

The UT_ERMS_REPLICAT for some reason moves the receiving email addresses from the rules to table CRMD_ERMS_RLSNPT. This thus is an easy view on the contents of the (sometimes complex) rules.

Reporting logs are also handled in the programming exit attached to the workflow task.

So, as we have seen, the steps that occur in the 'Invoke ERMS Service Manager' include fact gathering from a webform, adjusting the workitem text and executing the routing rule. Actual routing of the workitem does not take place here.

Workflow Task 'Route'

The route task is a manual step, which contains agent determination (so assignment of the workflow task to one or more agents. This determination is handled in function module CRM_ERMS_AGENT_DETERM1, and uses the in the prior steps determined organisational model from the ROUTE action in the rule modeler. Based on the determined organisational unit, all agents from the orgunit are now determined.

The task in the workflow item is actually a dummy. The method 'donothing' pretty much describes it perfectly.

So, we now have a workflow item with an attached email object assigned to all agents (users) of the determined organisational unit.
Note by the way there is also a 'rich' programming exit in the Route Workflow Task handling the Push_Email action that might have been added by the ERMS service manager.

Inbox

Cool, when a user is assigned to an organisational unit and an email arrives that is mapped to the organisational unit, the workflow item will automatically be assigned to all employees of the organisational unit.

You can influence where a inbound email is assigned to in the rule modeler (use ROUTE to assign it to all users of an organisational unit, or ROUTETORESP to assign it directly to a specific user)

Complexities

What if a user moves from one department to another?

What if you use ERMS in a B2C (Interaction Center) environment?

How does the IC Inbox cope with all the workitems waiting to be processed?

What happens if I use 'My Groups' in the IC Inbox?

Let's look at that next week...