Skip to Content

Multi-channel order management challenges – What does batch processing have to do with cross-sells?

Using one order management backend for capturing orders in multiple customer interaction channels is a goal that many SAP customers i talk to daily want to achieve. It increases operational efficiency, customer satisfaction and consistency in in-bound marketing activities. But other than the different channels there are also different interaction models in which orders are created. In this blog i would like to spell out 3 of these models that i have observed in the past: Browse & Search, Fast Order Entry and Batch. 

Interaction Models 

 The first model is browse and search. In this model the end user is not on a clear path to create an order but while he researches the product he might as a side-effect put items into a shopping basket or flag them for later purchase. The most prominent example of this is the Web Channel (Web Shop) where the focus is much more in supporting the customers buying decision. In this model the order management application needs to offer its functionalities in a very modular fashion so a list of up- and cross-sells is available in many different customer-facing channels. Key metric i have found to to judge if an order management application can handle this scenario well is the number of parrallel user requests (mostly read-only) that the system can handle.

The second model is the fast order entry model. This is most common in the call center. But also in partner channels or in the web channel customer employees need an ability to place recurring orders or orders with many line items rather quickly and efficiently. In this case the ability to do the order entry with a minimum number of clicks ideally all with the keyboard is critical. Confirmations on anything affecting the order entry task (availability of product in stock, availability of service technician, pricing) need to be immediate and reliable. Processing of functionality not affecting the order capture should be deferred to not stop the end user from entering the next line item as fast as possible. “One order a minute” was a statement from a Beverage company i talked to last week.

The batch input of orders has different challenges. In this case the throughput to get the orders to the database is the key challenge. Secondly i found it important to deal with exceptions and resolve these exceptions effectively. To optimize throughput a lot of the interactive functionality available to a call center agent can be neglected and the checks  that are done when capturing an order need to be restructured. For example a credit check for an order of 200 line items does not need to be performed with every line item but only at the start (does the customer have credit at all) and at the end (now that we know the total net value it makes sense to check the credit for the whole thing). For the exception handling efficient mechanisms for monitoring and post-processing the orders must exist.

The SAP Suite 7 supports all of the above models both on the ERP and on the CRM side. Most notable functional improvements in the Suite 7 release have been in the area of fast order entry and product proposals (SAP CRM 7.0 – Fast Order Entry , SAP CRM 7.0 – Sell More with Cross-Sells, Real Time Event Based Recomendations in SAP CRM 7.0). On the browse & search side the provision of ESOA service bundles (What’s new in Order Management). On the batch other then EDI support in both CRM and ERP we had for a long time we have partners who can help with scenarios where orders come in via FAX or other technical channels and get them into SAP quickly and efficiently (See different fax solutions available at For order post-processing SAP offers composite apps for both CRM and ERP (see the Procter & Gamble example at

Interaction Models
You must be Logged on to comment or reply to a post.
  • In the case of browse/search - the biggest difficulty is to ensure pricing and availability consistency between start of transaction and commit. It annoys customers when they finally decide on something only to find that when they hit submit - the price and delivery date both look different than when they started.

    This is a challenge in EDI too - say you get 10 orders from a customer on a day, each having one line item common (or one item inside the BOM being common). By the time the tenth order comes in, the price would have changed due to volume discount, but now you have to identify these orders, reprice and issue credit memos or something. Another variant - an EDI techhnical error causes a big order to fail, and then subsequent orders don't get volume discounts. Once the EDI problem is fixed, we need a manual intervention usually to sort out the issue and correct several documents.

    I don't have first hand experience - but I did hear from a friend that in an SOA model his client used for order entry, they ended up with several duplicate orders in their first release - since the calling application could not issue an external commit. I have sent this blog link to him to post more details if he cares too.

  • I believe you have accurately categorized the top level interaction models for order entry.  However, I don't think they are as black and white as portrayed.  Our experience is that in the B2B world, the dominant model (with respect to transactions if not revenue) is the Fast Order Entry model.  So that is where we start each of our implementations and then we embrace users that want Browsing capabilities as well as Batch Entry capabilities.  However, there are many B2B "infrequent buyers" who know they are going to buy product but just need a little help making sure they've selected the right one.  Also, there are many frequent B2B buyers, but they can't afford EDI integration with their suppliers.  We accommodate both of those with Digital Print Catalogs and Shopping Cart uploads respectively.

    Lastly, we have found that from a Manufacturer  configured in multiple Sales Areas perspective, they would like to develop "Microsites" that present local (and perhaps different) interaction rules in different territories.  These differences could include available products, shipping modes, currency, languages etc.  The Interaction Modes must accommodate these user preferences as well.

    Sam Bayer