Skip to Content

Options for Processing E-Mail in the SAP CRM Interaction Center

There are numerous options for email handling in the SAP CRM Interaction Center. You can route emails to a shared inbox where a team of customer service agents take turn picking the next message from the queue. Optionally you can also leverage SAP’s E-Mail Response Management System (ERMS) capabilities to semi or fully automate the process including sending auto-acknowledgments, categorizing the content of the email, and the routing the email to the best suited agent. Alternately, for emails that are urgent, time-sensitive or from important customers, you can skip the Inbox and route the email directly to an available agent via screen pop using your underlying CTI software, just as you would do for a phone call or live Web chat.

Which email option should you choose? Well, as you might expect, it depends. In the below sections I’ll try to walk you through the different email processing options and help you determine which option(s) best suit your organization based on your business processes and preferred customer experience.

Agent Inbox and ERMS (“Pull” Mode)

Let’s start with the Agent Inbox and ERMS. Using the SAPConnect interface, you can receive emails from your SMTP corporate email server (e.g., Microsoft Exchange). These emails are then converted into work items using SAP business process workflow. The work items are then assigned to one or more agents using partner determination, and then presented to the assigned agents in the Agent Inbox in the Interaction Center.  The agents then work in “pull” mode, manually selecting items to process from the inbox.

Technically, you can use the Agent Inbox with or without ERMS. However, ERMS is highly recommended as it not only gives you greater control over agent assignment, but it also provides a host of automation options like auto-acknowledgement, auto-categorization, and auto-response.

Using ERMS you can automatically send auto-acknowledgments, pre-parse and pre-categorize an email, automatically find and link relevant solutions, route the email to the best suited agent, and automatically compose draft response emails leveraging a set of stored email templates. See SAP note 940882 for more information about ERMS. In addition, please see my other blog post, “ERMS Configuration Guides and Documentation”.

Another advantage of using the Agent Inbox for email (as opposed to the pure ICI Email push method that we will discuss below later) is that you can take full advantage of all of the customer-service business processes built into the Interaction Center such as automatically linking together all emails belonging to the same email thread, automatic creation of linked follow-up business transactions (like Service Requests and Service Orders), and usage of multi-session handling in Interaction Center to process multiple emails in parallel.

Using ERMS and the Agent Inbox is perfect for companies who want to use a traditional email inbox approach where agents process the emails in an “asynchronous” fashion – working on the emails whenever the agent has spare time. This approach is ideal for organizations who want to give first priority to “synchronous” customer communication channels like telephone or live Web chat, and have agents switch over to the inbox and work on emails during slower periods of lower call volume. However, companies who want to treat incoming emails with the same priority as telephone calls and Web chats should look at the options below for using the ICI interface or ERMS Push to pop emails directly onto an agent’s screen via the underlying CTI software.

ICI E-Mail (“Push” Mode)

While ERMS and the Agent Inbox is ideal for companies with very complex customer-service processes, companies who only require a basic email solution to support a simple help desk might be more interested in the ICI push approach which allows emails to be routed directly to an available agent via screen pop using the company’s CTI software. To implement this approach, you would leverage SAP’s Integrated Communication Interface (ICI) rather than SAP Connect. You can find more details about ICI configuration here in this blog.

The advantage of using the ICI “push” approach to email handling, rather than the Agent Inbox “pull” approach is that emails are popped on to the screen the next available agent for immediate processing rather than being routed to a inbox where they could potentially sit for hours – or even days, depending on your SLAs for email response. It’s really a question about whether your organization wants to give emails the same priorities as other synchronous communication channels like telephone calls and live Web chats, or whether you want to treat emails as less time-critical work items that should be processed during off-peak times of lower call/chat volumes.

However, while the ICI email approach can provide a basic solution to organizations with simple requirements, there are a number of restrictions associated with the ICI approach that make it impractical, and hence not recommend for most companies. One of the major drawbacks of the ICI approach is that it does not allow you to leverage any of the ERMS capabilities. That means no automatic parsing and categorization of messages, no automatic recommendation of relevant solutions and other documents, no automatic creation of follow-on service transactions, and no ability to automatically link related email exchanges that are part of the same conversation using a tracking ID.

Additionally, the ICI approach does not support the new multi-session capabilities introduced in CRM 7.0 EHP1 that allow agents to process multiple emails (from different customers) in parallel. Please see SAP notes 161075 and 1611836 for more details about the restrictions of the regular ICI e-mail approach.

While the regular ICI email approach is not recommended for most organizations – except for those with only the most basic requirements for a simple e-mail help desk scenario – an alternative ERMS Push hybrid solution is available which offers the best of both the ERMS and ICI approach. See below for more details.

ERMS Push (Hybrid)

For organizations who want to route emails directly to an available agent via screen pop, SAP recommends the new ERMS Push hybrid approach rather than the old regular ICI approach. ERMS Push offers the best of both worlds. Emails are first sent through the SAP Connect interface where ERMS can be leveraged for pre-processing activities like parsing, categorization, and auto-creation of follow-on service transactions. Then, instead of routing the emails to the Agent Inbox via workflow, the emails (along with any relevant routing information) are passed over to the ICI interface where the organization’s underlying CTI software can be used to route the email to an available agent via screen pop – just like an incoming telephone call or Web chat.

Additionally, in CRM 7.0 EHP1 an enhancements was made to ERMS Push, allowing greater control in selecting the most suitable available agent to whom to route the email. A new ERMS action “Add Routing attribute” was delivered that can be used to transfer any ERMS Fact Base attribute as a routing attribute along with the e-mail to the CTI software. See this blog and SAP notes 1655959 and 1790251 for details.

Finally, please read this discussion forum thread for answers to some commonly asked questions about ERMS Push.

You must be Logged on to comment or reply to a post.
  • Hi John,

    great blog, and talk about good timing, I am looking at a requirement includng handling incoming emails at the moment, and one of the questions has been acknowledgements etc and your tip on SAP ERMS and the OSS Notes and documents attached to the OSS Note and your explanations of the functionality are very useful.

    Nice weekend,


  • Hi John,

    I have read the OSS Note and the Attachments.

    Well, Marilyn Pratt , I have said it before and I will say it again, this is the power of the SCN, putting the Customers in direct contact with the people at SAP who are owning the solutions and processes. Is there any other Enterprise software company which does that ? This is something SAP can be proud of.

    John, Thanks for writing that OSS Note and the attachments.

    Question, is ERMS Add-on only for CRM, or can the ERMS Add-on be installed on other SAP systems, eg for sake of argument SCM.

    Imagine, you had a business requirement to email data files to SCM, can we put the ERMS Add-on onto SCM and then utilise the acknowledgement functionality to send acknowledgements back to the sender that the email was successfully received ?

    Or is ERMS only for CRM ?

    Thank you again and kind regards,


    • Hi Andy,

      Thank you! I'm glad to know that people actually read these posts and find them useful!

      Regarding your question, ERMS was coded directly inside CRM and is therefore tightly coupled to the CRM processes. It relies on CRM workflow, for example. I doubt SCM has similar capabilities. Also, the ERMS fact-gathering and action-handling services are coupled directly to CRM business processes such as the Interaction Center, Agent Inbox, and Service Request.

      Warm regards,


  • Hi John,

    Excellent blog thanks for sharing valuable info across, we plan to configure ERMS however had a query about the same appreciate if you could let me know

    Currently the mail server of our client is zimbra which is other than Microsoft Exchange or Lotus Notes hence would zimbra integrate with SAP CRM with regards to incoming E-mails which can be viewed in the agent inbox

    Kind Regards


    • Hello Atul,

      The choice of mail server is completely unrelated to the ERMS processing. Rather this is more a NetWeaver basis issue. You can to make sure that your mail server is compatible with SAP NetWeaver's SAPConnect interface which is how mail servers and SAP ultimately communicate. SAP Note 455140 discusses how to integrate an SMTP mail server; As per the related SAP Note 1236270, SAP no longer supports RFC based mail servers for example.

      I've never heard of Zimbra before, but looking quickly at their web page it does seem to be SMTP based, so if that is the case then it should work with SAP NetWeaver, and thus ultimately with ERMS. At least that is my understanding.



          • Hello John!

            What is the exact difference between ICI-CTI 3.07 and ICI-MAIL 3.07 ?

            For me it is the same software, the same functionality, the same coding?

            It is just an marketing difference?



          • Hello Ralf,

            The naming conventions you mention above are the terms that the SAP Integration Certification Center (ICC) has created to designate the various certifications offered to third-paty Communication Management Software (CMS) vendors. So rather than insisting that a vendor comply with the entire Integrated Communication Interface (ICI) specification for all communication channels, the ICI offers three different certifications for telephony, email, and chat so that a vendor can get certified for only one or two channels if it prefers. So, I guess you can think of these naming conventions as subsets of the ICI specification.



          • Hello John!

            THX, got it.

            From CRM perspective: the agent can accept the mail similar to calls by accepting in the toolbar.

            Though mail and telephony use the "same" ICI Interface (Integrated Communication Interface) in CRM?

            There is no seperate mail or telephony CTI-codeline in CRM?



          • Hello Ralf,

            Please have a look at my other two blogs:

            SAPphone versus ICI (Integrated Communication Interface)

            What is Computer Telephony Integration (and Why Do I Need It?)

            In short, the ICI interface can be used for real-time "push-mode" of phone calls, chats, and emails using the multi-channel soft-phone communication toolbar in the Interaction Center. There is also an option for emails (but not for phone or chat) to the use SAPConnect Interface and the Agent Inbox in the Interaction Center for "pull-mode" processing of emails; this is more common in a back-office approach. Hope that helps.