Scenario: Implementing an e-commerce store

Overview

The term e-commerce refers to a business model in which sellers and buyers agree to buy and sell goods and services by using an online marketplace. Generally, the transaction is done by using an electronic medium such as computers, tablets, smartphone, and other devices. The online shopping segment is not a new concept. It continues to accelerate in popularity and is now one of the go-to-methods of shopping.

The types of goods and services that are available in this market sector is limitless. Nearly any goods that can be found in a brick-and-mortar store can be discovered online, including electronics, books, groceries, fashion, furniture, and all other consumable goods. Services are now also common online shopping experiences, where shoppers can book a lesson, consultation, or place an add-on service as part of an e-commerce transaction.

Advantages of e-commerce

The seller does need to invest in more resources to stand up clusters of servers to host an online market space. However, compared to the investment needed for a brick-and-mortar store, an online space does not impose any physical constraints on where the server site is hosted. Additionally, the seller does not need to worry about having sufficient physical space for shoppers. Without the physical constraints, the number of shoppers who can enter an online marketplace is practically limitless and highly scalable if the seller's online marketplace is easily discovered by shoppers.

Taking the operation cost into account, the cost of maintaining server hardware is much optimized compared to setting up a physical brick-and-mortar store. Given that success is not certain for any store location, the sunk cost to host an online storefront is clearly economical and highly flexible in terms of scalability.

Challenges of e-commerce

It is certainly an advantage to see a large influx of online shoppers on a new online storefront, but two business challenges exist. First, you need to make shoppers aware that the shopping site exists. Second, you need to facilitate a seamless product search experience for the shopper. For a homogeneous product search, most online shoppers lack the patience to dive into a website to find a product that they want. These shoppers are disappointed if they cannot locate the product in the first 30 seconds of their search. For specialty or branded products, the shopper typically is a bit more persistence. This shopper takes more time to search for what they need, moving to another online store site only to find alternatives.

The online shopper drop rate extends throughout the online marketing funnel, beginning with a product search and then moving through a product detail page, cart page, checkout page, and sales order.

This diagram shows the concept of the e-commerce conversion funnel, which highlights the importance of shopper retention by quickly showing the online shopper what they want to see.

The sales conversion rate that is shown in the preceding diagram is only half of the equation. The e-commerce seller also needs to address whether the product can be fulfilled. To ensure fulfillment, the seller needs to be certain that the order is accepted only when sufficient inventory or capacity exists across the fulfillment network. Otherwise, the order might not be fulfilled, which hurts the seller's brand reputation and erodes the shopper's trust level. A positive shopping experience can be further enhanced when the seller limits their display to only items that can be fulfilled on that day and provides transparency about the product delivery date. The seller can gain greater insights when they are aware of the product's source location and shopper-selected carrier service early in the pre-purchase capture process.

Delivery option preferences

In early phases of e-commerce sales, most of the shopping experiences involved a product that was shipped directly to the shopper's door. As a shopper shifts their attention into the next generation e-commerce experience, they develop preferred fulfillment methods. These preferred fulfillment methods can include shipments, picking up orders in a store, curbside pickup, and even picking up from a kiosk. Each of these fulfillment methods adds complexity for the seller. The seller is not just shipping a product but instead needs to account for fulfillment costs in making products available for shopper pickup.

Key factors for a positive shopping experience

Some key factors that are necessary to cultivate a positive shopper experience:

How Sterling Intelligent Promising accelerates e-commerce success

With the rise in e-commerce popularity, the primary objective of Sterling Intelligent Promising is to accelerate the seller's e-commerce transformation. This transformation is facilitated in two key product aspects: minimizing configuration time and providing flexible tools to support the e-commerce fulfillment workflow. Sterling Intelligent Promising is not a front-end store capture application but rather it is a key fulfillment determiner of when and where an item can be sold. This information enables a shopper to confidently place an order on a store site because the risk of a backorder event is minimized.

Sterling Intelligent Promising can provide a real-time fulfillment estimate by using the following factors:

Sterling Intelligent Promising can also support an end-to-end e-commerce pre- and post-order capture workflows, consisting of these steps:

Enhancing the e-commerce shopping experience with Sterling Intelligent Promising

Many ways exist to implement an e-commerce workflow but Sterling Intelligent Promising provides these guidelines on how the Promising APIs can be used to improve shopper experiences on an online marketplace.

Product search

The product search can be implemented in various ways based on the size of product catalog that the seller offers. The simplest way to implement it is to allow shoppers to select a product category such as Jeans and redirect them to a product list page to showcase a list of products. In contrast, larger organizations often involve multiple sellers or a large catalog. In this scenario, you likely need a complex search capability on the online marketplace to help shoppers narrow down the displayed list of products.

Regardless of your approach, the most challenging task for a seller is the ability to narrow down products to only those products with either immediate availability or near-term delivery windows. It is a poor experience when a shopper searches for a product and realizes that each product that is listed in the first few search results is not available. This unfiltered behavior hurts the overall branding and shopping experiences. Therefore, the product listing needs to be prioritized based on the following sequential criteria where the first listed item is the highest priority.

Product delivery date and product availability date are the most important criteria. Even if a product has a 100% rating, if the delivery and availability dates do not match shopper expectations, the seller cannot ensure delivery on the date the shopper wants it. Therefore, the suboptimal search results need to be filtered out by the search system.

The e-commerce seller can build a daily search index based on the product catalog to ensure that only available items that can be delivered in the required timeframe are included. This filtering ensures that the shopper always sees items that they can purchase immediately. To support this behavior, the seller can take advantage of the Calculate item delivery date API to pre-compute a list of earliest delivery dates or order by dates. Then, the seller can use that information as filter criteria when the daily search index is built. Since search indexes are compiled in advance, the Calculate item delivery date API offers the concept of reference time to estimate delivery dates based on a future time horizon. For example, if you plan to implement a search index tomorrow, the system needs to invoke the Calculate item delivery date API with a reference time of tomorrow so the index can be built in advance.

For more information about the Calculate item delivery date API, see Estimated item delivery date.

Although the Calculate item delivery date API has a fast response time, it is not recommended that sellers look up delivery dates when pages are loading. Web servers need to perform more filtering and ranking logic that can potentially impact the shopper's experience. To provide a seamless shopping experience, do the estimated delivery date pre-calculation in advance to improve the overall product search response time.

To further improve scalability and performance, it is recommended that sellers use distributed-store web servers and that each web server handles its local search index instead of using a central server. Although Sterling Intelligent Promising a supports large number of concurrent transactions and most of the fulfillment request only inquiries, deploying a local index cache minimizes the number of estimate requests. Also, local index caches limit requests to only essential transaction such as adding an item to the cart, changing quantity, and checkout transactions.

This diagram shows a simple construction of a shopper search index workflow.

Search page components

These components are used to build a search page.

Product list page

The product list page displays a list of featured products based on the product search results. The page might show the products in a list view or grid view. Typically the same type of view is used across the e-commerce store site. Since the shopper cannot interact with the product online, the seller can compensate for this inability by displaying the delivery date for each item in the list. The estimated delivery date can help to convince the shopper that their wait for the product is acceptable.

For each item on the product list page, the seller can display the earliest estimated delivery date and show when the product needs to be ordered to meet that delivery date. Displaying these dates creates a sense of urgency for the shopper to purchase the product. When the estimated delivery date is displayed, the seller can show the delivery date for multiple shipping groups, such as for standard shipping and economy (free) shipping.

A shipping group is a shipping option that is available to shoppers and provides an estimated delivery date. A seller can configure one or more shipping groups that can be provided as options on an e-commerce website. Typically, a shipping group consists of one or more carrier services that meet the specified number of days until delivery. The seller can organize the carrier services by shipping speed or by contracted shipping cost. For more information about carrier services, see Carrier services. For more information about shipping groups, see Shipping groups.

This image shows a section of a product list page that displays shipping group delivery dates with an order by time and a pickup option.

The seller can use the Calculate item delivery date API to get the estimated delivery information for the two sample shipping groups (Standard and Economy Plus). The estimated delivery date returns two key values for each shipping group and item, the earliest delivery date and the date by when the order needs to be placed.

The seller can also display the transit duration for each item. This alternative is included in the Calculate item delivery date API.

Example

If two dresses are available in multiple sizes, these dresses are also known as an item with variation. Each variation has a unique stock keeping unit (SKU) identifier. An item with variation is a nonsalable parent item that consists of one or more models or sizes. Each child item is a salable unit with its own inventory. The parent item makes it easier for the seller to track a collection of SKUs with the same design or model. For example, a small-sized red dress and a medium-sized red dress each have a different SKU. To correctly display the shipping information, the seller needs several pieces of information, including the earliest delivery date and earliest order by date for each SKU.

In this example, a red dress has two sizes and the seller offers two shipping speeds. To obtain the displayed information, the seller must make four API requests for each child SKU and shipping group:

The result set is then refined by the seller's web server to derive the earliest dates among the dress sizes. In contrast, for an item that does not have any variants, the seller needs to make only one API request per shipping group.

The complexity increases with the number of items with variation. To minimize the number of real-time estimate calls, the seller is encouraged to store the delivery information as part of the web index cache. In this way, the information is readily available without recalculating it for every page load. Most shoppers need only approximate delivery estimates on a product list page. A more accurate estimate can be displayed after the shopper reaches the product detail page. This strategy benefits both the seller's web service load and the shopper's experience.

For more information, see the Calculate estimated item delivery API.

Product detail page

This image shows a section of a product detail page that displays the shipping group estimates and available pickup options.

Add to cart

The shopper adds an item to their cart so that they can check out or purchase the item later. Since adding to cart is an uncommitted purchase, the seller typically uses business rules to guarantee that the items are available until the end of the checkout process. These rules guarantee a "soft reservation" on the item for a short period, though beyond that time period is considered cart abandonment and the item reservation is released. Other sellers might choose to omit this step and capture item reservation only before the checkout phase.

A distribution group is a logical collection of ship nodes that contribute to a target region or segment of the market. Instead of addressing a single ship node, the seller can refer to a distribution group based on its geographical region. For example, an "East coast group." Distribution groups are also referred to as networks.

For items in an uncommitted state, seller can do a network-level (distribution group) reservation to be more flexible. When the reservation is made at a network level, the item is reserved for a short period but is not explicitly applied to a ship node. This way, the seller can still ensure that the item is available in at least one ship node in the distribution group. However, a node-level reservation is not recommended because it deducts from the available inventory at the node, which affects the overall availability level of the item for other shoppers.

Sellers can make a network-level reservation by using the Create Reservation API. To reserve an item at a network level, the web service must pass the distribution group identifier. To reserve at a node, the seller passes the ship node identifier. When the reservation is made, it is recommended that the seller include the time-to-expire component to ensure that the reservation expires after a specified period such as 5 minutes. When the reservation expires, the reserved quantity is returned to the availability pool, and the reservation is automatically canceled. The seller can also set a default reservation expiry duration so the web server does not need to hardcode the duration for every request. The default reservation expiry duration can be set by using the  Update settings API.

This image shows an example of a warning message when the requested quantity is greater than the available inventory.

Cart

As a shopper browses the store site, they add items to the cart. Often the items added to the cart are similar to each other or are related items, so the shopper can compare them and narrow their product selection before checkout. In addition to the products, the shopper might be interested in the available quantity and how soon they might receive a delivery for each cart line. By showing the estimated delivery dates for each cart line, the shopper can easily compare which of the items they want. For example, in a use case in which a shopper is deciding between a blue dress and a red dress. If the red dress arrives tomorrow and the blue dress arrives in two weeks, the seller selects the red dress based on their scheduled needs.

One difference from the cart as opposed to the product detail page, is that each cart line consists of the quantity of the item. Since the Calculate item delivery date API accounts for single availability and valid capacity windows, it cannot provide an accurate estimate for a cart line. For this reason, Sterling Intelligent Promising provides the Calculate checkout assignments API to support this use case. This API addresses the complex calculation that is needed to determine the earliest delivery date based on the shipping speed for the requested quantity. The seller might realize that when the number of item increases for the same cart line, the overall delivery date might change. The date might change because each shipping location might not have all requested quantity or have different availability dates.

It is recommended that the seller display the estimated delivery date for each cart line. The shopper can then compare individual cart lines to determine which items meet their delivery acceptance criteria. Some sellers might include all cart lines into the estimate, under the assumption that the shopper knows exactly what they wanted from the beginning. This use case suits sellers that have a small catalog and primarily offer flagship items or limited product choices.

For the cart estimate, the seller can choose to show similar information as can be displayed on the product detail page. This information can include the shipping speed and associated earliest delivery date, and the earliest date the items can be picked up at a nearby store.

This image shows an example of a cart page with a request that exceeds the available inventory.

To obtain the estimated delivery information, use the Calculate shipment assignments API. The Calculate shipment assignments API provides the earliest delivery estimate and accounts for the full requested quantity for a cart line item. The API also returns information about any backorder or quantity that cannot be fulfilled by the network. For this reason, the seller needs to proactively verify whether the quantity is complete and report any backorder amount to the shopper. This communication ensures that the shopper is aware of any quantity that cannot be fulfilled before they move to the order capture phase.

This estimate can also be derived by using a combination of the Calculate item delivery date API and the Get node availability by dates API. The estimated delivery date also provides the fulfilling ship node that meets the reported earliest delivery date. By using this information, the seller can identify the available quantity at the target ship node by using the Get node availability by dates API. Based on the inventory threshold of the item, the seller can display a short message that indicates that the item has only a limited availability to urge buyer to purchase it sooner.

Checkout

After the shopper finalizes the list of items in their shopping cart, the cart can be forwarded to the checkout phase. At checkout, the shopper does a final review of the cart, which consists of multiple cart line and item quantities. Since that the shopper is likely to be committed to purchasing the items, the seller needs to provide a delivery estimate for the entire cart. This delivery estimate ensures that the shopper is aware of the overall delivery date for the items.

The difference between a cart page and a checkout page is that a cart page contains all the cart lines that are considered together to obtain the fulfillment estimates. When multiple cart lines and multiple quantities are considered together, it is likely that the cart is going to require split shipments when availability is low.

On a checkout page, the shopper must be able to choose the shipping speed they want, delivery methods, and fulfillment preferences. The shopping experience is further enhanced when the seller gives the shopper a sense of commitment by providing an accurate delivery estimate for the cart items and quantities. Fulfillment preferences can either be predefined by the seller or provided as options for the shopper. Fulfillment preferences indicate the way that the shopper receives the delivered items, such as all the items delivered together or delivered as soon as they are available. Earliest delivery means that the shipment leaves the ship node as soon as the items are available. Delivery together refers to scheduling all cart items to arrive on the same earliest possible delivery date.

The shopping experience is further enhanced with the cost-based promising. The seller can now not only provide accurate delivery estimate but also fulfill orders at the lowest overall cost-to-serve. The shopper can choose Apply cost optimization as a fulfillment option. When the shopper selects this option, the seller promises the delivery for the cart items by calculating per-purchase shipment assignments to minimize the overall cost-to-serve. As the shopper chooses for Apply cost optimization option, Calculate checkout assignments using costs API accounts for the minimum cost-to-serve considerations when it derives the delivery date for the cart. For more information about cost-based promising, see Scenario: Calculate prepurchase shipment assignments and minimize the cost-to-serve.

The Calculate shipment assignments API accounts for all of these considerations when it derives the earliest delivery date for the cart.

Similar to cart page, the seller must be sure to capture any backorder quantity reported by the Calculate shipment assignments API early in the checkout cycle so that the shopper is aware of the shortage. This communication can minimize a negative fulfillment experience.

This image shows a checkout page that shows a shipping group with delivery dates and line breakups based on delivery methods between shipment and pickup.

The Calculate shipment assignments API returns the following information to support the key information that the shopper needs.

Items on the cart or cart line are likely to be split into multiple shipments, so the Calculate shipment assignments API response includes both the earliest and latest delivery date. For this reason, the seller can use both of the values or use only the earliest delivery date. In the latter scenario, the delivery breakdown is shown on the shipment detail page.

A seller who plans to supports pick up options needs to separate the cart into two different requests, one for the shipment delivery method and one for the pickup delivery method. The Calculate shipment assignments API does not support mixing pickup and shipment in the same request. The nature of pickup is different than shipment because it does not involve last mile delivery. Also, most sellers publish availability dates based on the shopper's preferred store location. For example, if the shopper's cart consists of one shipment line and one pickup line, the seller must explicitly split the cart between the shipment and pickup. In this way, an isolated request can be made for each delivery method.

In this example, the cart is split into pick up and shipment.

The seller runs the Calculate shipment assignments API for SHIP1 cart line. For the PICK1 cart line, the seller must request the Get node availability by date API to retrieve the availability date on the selected ship node and make an inventory reservation for the defined store by using the Create Reservation API. At this stage, the seller might want to make a "hard reservation" by reserving against the assigned ship node as provided by the Calculate shipment assignments API.

When the user provides the payment and completes the checkout transaction, the seller can create an order by using an Order Management System or a record demand from the checkout process. In the example, two demands are created in the checkout process, one for each cart line (SHIP1 and PICK1). For the PICK1 scenario, the seller must use the shopper's pickup date as the ship date on the demand request. For more information, see Review shipment details.

Review shipment details

When the shopper enters the final stage of the checkout flow, such as payment capture, it is recommended that the seller display the shipment breakup for the cart lines. This shipment breakup helps the shopper understand how many packages to expect to be delivered. Depending on their fulfillment preferences, more than one shipment might exist.

If a cart has multiple cart lines, each with various quantities, the shopper is likely to receive multiple packages from the seller, especially if they originate from different ship nodes. Some example scenarios of shipment breakups are as follows.

• One cart line is fulfilled by a single ship node in a single shipment.
• One cart line with multiple quantities can be shipped in different packages from different ship nodes.
• Multiple cart lines can share one shipment.
• Multiple cart lines can share multiple shipments to fulfill the complete requested quantity. For example, Line1 and Line2 can share Shipment1 and Shipment2 based on availability schedules.

In this example, a ship node has limited availability, so Sterling Intelligent Promising optimizes the availability by breaking up the cart into two shipments based the earliest delivery fulfillment preference. Each shipment indicates the quantity that is assigned to the shipment.

Before the shopper confirms the order, the seller needs to create a brief inventory reservation until the checkout is finalized, so the inventory is not consumed by another process. The preceding images also indicate the amount of time before the current checkout screens expires. After it expires, the seller needs to renew the reservation by creating a new one. If any request item has a shortage, the shopper is notified that the quantity is no longer available.

After the order is confirmed, the seller has two options to capture the order:

• Use the assignment provided by the Calculate shipment assignments API, including the commitment date, ship node, and carrier service.
• Use an Order Management System and note the committed delivery dates so they appear as they were presented to the shopper.

To use the assignment provided by the Calculate shipment assignments API, the seller must perform all of the following steps:

1. Create an inventory demand by using the Adjust Demand API for the assigned quantity and ship node assignment.
2. Consume the reservation by using this API and pass the reservation identifier.
3. Process the fulfillment request by using the carrier service at the assigned ship node. The seller can use an external integration solution or an Order Management System to manage ship node task and operations.

Regardless of the method used, since the delivery date was presented to the shopper, this date becomes the commitment date. The seller must ensure that this date is not violated to avoid customer dissatisfaction. While this commitment date is used as a delivery benchmark, the seller can also use this data to perform another layer of fulfillment optimization as more demands arrive in the system. In this way, the seller can achieve optimal shipment balancing across all nodes. Even if a cart line was assigned to a ship node, the seller can change the ship node and carrier service assignment for a lower-cost option if the delivery date is maintained.

Prerequisite checklist for Promising service

To ensure that Sterling Intelligent Promising is working correctly, IBM recommends that you verify that all of the following configuration data exists for your tenant account.