Shopping basket management is key for omnichannel

Going omnichannel is an ambition for many service providers. A lot of companies have started by applying omnichannel to the sales domain, followed by domains like care, assurance and billing. Several IT capabilities such as product catalog management have been highlighted as essential elements to achieve omnichannel, but little attention has been to shopping basket (or shopping cart) management in an omnichannel context.

In a traditional single channel strategy where the main channel for service providers is a call center, creating the shopping basket was a mandatory step required to create an order on behalf of a customer. It was often associated with a complex order capture process that was usually accomplished in about 20 minutes in some systems.

When moving towards multichannel, where online channels started to play a more important role in sales, the shopping basket was an intermediate window for customers to be sure about their orders prior to submission. Retail e-commerce capabilities introduced cookies, which stored basket data so that the customer didn’t have to search again for a product.

Going forward in an omnichannel world, the shopping basket has to extend beyond that. Cart management has to win its own place in application frameworks (including TM Forum’s Application Framework – TAM) and application program interfaces (APIs). The cart object and its relationships should be one of the key data elements in the data warehouse, 360-degree customer hub. It should also be a key part of analytics and behavioral profiling of the customer that will enable better next best actions and offers.

The business benefits could be endless. Already unfinished shopping baskets are used in lead management but could further be used to automate such processes across multiple notification and communication channels, achieving better customer experience. Also, awareness of the basket across multiple channels would enable true channel hopping during the sales journey, potentially increasing upsell opportunities when moving from digital to assisted shopping.

Blurred lines

Traditionally a cart is considered to be part of the shopping process, while an order is part of the fulfillment process after the customer has confirmed his or her wish to purchase. More and more, though, the transition from cart to order is becoming blurry.

E-commerce tactics now allow customers to place an order and ask at a later stage for the payment details or for some order configuration details, which results in higher conversion and customer experience and decreased cart abandonment. That implies that the lifecycle of the cart is getting mixed with the order lifecycle, requiring order and basket management systems to work closely together – potentially converging – and closely related to customer interactions. Architecting such basket-to-order transitions correctly could unlock multiple possibilities for the business to tune and find the optimum customer experience based on different business needs.

An example of how this can be applied is the use case of order validation. In traditional agent systems, basket validation is a must, and one could not imagine an order being captured that does not pass all validation rules. As more channels come into play, these validations cannot always happen in real time, especially if channels do not allow it (for example, for channels like social or text message).

However an agent should be able to update an order that falls out, or even better, the order management system should validate and self-correct it. An ideal architecture should expose both the real-time basket validation capability as well as the offline long-running process order validation in a consistent way, reusing the same validation logic and rules and ideally in the form of APIs.

Shopping Cart API

TM Forum has been active the last year as part of the Open API Project to establish best practices for a Shopping Cart API specification. It is quite important that the shopping basket also finds its place in the application and capability frameworks so that suppliers can position it correctly in their solutions. Traditional configure, price and quote (CPQ) packages lack strong basket management, while at the same time ecommerce applications, primarily coming from the retail domain, lack strong CPQ capabilities.

All these capabilities around basket management have been demonstrated in the Omnishop Catalyst project, which looks at a customer journey of micro-moments spread across a set of channels and touchpoints over a period of time and demonstrates the omnichannel shopping capabilities required to achieve the journey. The project is also looking to cover the market gap in approaching omnichannel basket capability connected to both e-commerce and customer channels as well as CPQ capabilities for agent channels.