One of the most exciting yet challenging jobs when we work on an eCommerce engagement is catalog modeling. There's no single solution that works for all clients, and it's also an area where teams significantly underestimate required effort.
One of the most exciting yet challenging jobs when we work on an eCommerce engagement is eCommerce catalog models. It’s exciting because there is no single solution that works for all clients. It’s also an area where teams significantly underestimate the effort required.
Typically, an enterprise decides to invest in eCommerce when they realize the need to elevate their customer’s online shopping experience. This, in turn, results in better revenues over a period of time. When a team attempts to do this without a good grasp of the existing business processes and systems related to product development and/or supply chain management, they significantly underestimate the complexity of the task at hand.
This is because eCommerce catalog modeling has an intrinsic relationship to the upstream and downstream business processes.
Let’s take a look at some of the nuances of catalog modeling.
The SKU (stock keeping unit) is what is priced, stocked, tracked, and sent to customers. Irrespective of how you present your products on the storefront, every selection and purchase done on the store needs to be defined in terms of SKUs for the order to be handled via your order fulfillment processes.
See “Nike Air Zoom Pegasus 36” (see picture) that is being presented as a single product. This product represents up to 150 unique SKUs in your order fulfillment systems: 2 (types of fit) by 5 (colors) by 15 (sizes) = 150 unique SKUs.
The mapping between products and SKUs may not always be available in a consumable form. Enterprise Resource Planning (ERP) systems, which are often the data provider for Product Information Management (PIM) systems or eCommerce systems, may not have a mapping between products and SKUs.
Effort will be required to either manually do this mapping, or to get the required automation built. If there are multiple dimensions for the variations, the effort would be higher both for the mapping exercise, as well as to build the user interface.
Most eCommerce systems will allow you to define different product types. You will need different product types if you have sets of products that follow very different business processes.
A great example is a pharmacy store that sells prescription drugs, non-prescription drugs, and personal care products. Another example could be a big-box store that sells products that are widely different from each other - like groceries and electronics.
Making the decision on the product types is critical. If you have product types that are too granular, you might be adding complexity to maintenance of your platform and its integrations with upstream systems. If you do not have any product types at all, you could end up with your storefront being very rigid in its user experience. So having the right balance is essential.
When considering various eCommerce catalog models, there are different types of product bundles that you would want to present in your store. These go by different names - “bundles,” “kits,” or “multipacks.” The way these are presented and promoted in the store may be uniform. However, how these are handled in fulfillment and revenue recognition could be different.
These are cases where you are running a promotion to offer a deal to the customer who is ready to buy multiple products or multiple quantities of the same product. These bundles do not have any meaning outside of the eCommerce platform. When you send the order for fulfillment, you will be expected to send the information of the constituent SKU.
The virtual bundles differentiate themselves from standard promotions as they need the eCommerce merchandising team to create custom content (for example, the image of the bundle) to support the promotion.
There may also be bundles that have been defined by the manufacturer. In this case, the bundle itself is a unique SKU. If the eCommerce catalog is able to get information about the constituent SKUs of this bundle, there may be some automated upselling possible on the store to the customers who are looking at purchasing the constituent products.
These are bundles with a unique SKU. However, the SKU itself can be assembled by the customer. See an example in the picture below showing two different ways the single SKU for “Custom Mix Gift Bag” has been assembled. There are two levels of complexity here:
Another feature that is popular in eCommerce catalog models is the ability to present products that can be used together as one ensemble. This goes by different names such as “looks” or “collections.”
See the example here. Three products - a top, jeans and sneakers - have been presented together. These three products are unique SKUs. The concept of this ensemble doesn’t have any meaning to your order fulfillment systems. They differ from the virtual bundles, since the customer has an option to purchase one or some from the ensemble.
Your eCommerce system or your PIM will be the source of truth for these ensembles. There will be ongoing effort required from the eCommerce Merchandising team to set up these ensembles.
Product versioning is an important concept for eCommerce catalog models used by manufacturers or retailers selling electronic products on their storefront. You can see in the picture below where the user is automatically redirected to the product page of a newer version of the product (upon searching for the old version).
If you are a manufacturer, your Product Lifecycle Management (PLM) system is the source of truth regarding product versions. This information needs to flow all the way to your eCommerce store if you want to give an elevated experience to your customers who are in the store looking for one of your discontinued products. Often, it is the ERP system and not the PLM system that provides data to your PIM or eCommerce platform, and the ERP system may not necessarily be concerned about the product versioning information.
Manufacturers often sell product parts in their store, in addition to complete products. Both of these - the part product, and the complete product - represent unique SKUs. However, how the data on these products are maintained in upstream systems such as the PLM or ERP system could be different. The “part” is usually a constituent of the Bill of Materials (BOM) representing the “complete product.”
You may also have products where you allow your customer to add their own customizations. There are multiple levels of complexity to be handled here:
These are products where you allow the customer to configure them. Stores selling computers, cars, or telecom products are great examples. There are usually complex configuration rules behind these products that define what configuration combinations are allowed, and how each configuration impacts the price.
These rules could be housed in the eCommerce system itself, or in the ERP system. When it is a high value configurable product, typically the customer will have an option to generate quotes for different configurations. These are usually supported by a CPQ system that is integrated with the eCommerce system.
The taxonomy of products in CPQ systems often is different from the taxonomy in the eCommerce systems. This difference needs to be accounted for when building the catalog model for the eCommerce system.
Another area of eCommerce catalog models is the use of products with multiple price choices. This applies to a marketplace that allows customers to compare and contrast products from multiple sellers before making a selection. You might find the same SKU available on the store with two different prices. Another scenario where you would find two SKUs available on the store could be on stores that sell used products. Depending on the quality of the used item, the price could be different for the same SKU.
In these cases, the catalog model in eCommerce platform needs to cover the extra information that is needed for these products. It may be the “seller” information associated with a SKU, or it could be a “unique identifier” associated with each used item. This information needs to flow back to the fulfillment process once the customer has placed an order on the storefront.
If you are in a B2B model, you are likely to have customer contracts that define the prices that you offer to your B2B customers. The contract prices are typically maintained in a Customer Relationship Management (CRM) system or in a CPQ system.
Your eCommerce system could end up getting prices from two different systems - one system for the contractual prices, and the other system for regular prices. Depending on how the SKUs are modeled in these systems, this could have an impact on your catalog modeling.
Before setting out to do eCommerce catalog modeling for an online store, it is essential to understand the lifecycle of products, and how these products make their way to the customer’s home or office. The associated business processes and systems will help you understand the nuances you need to cover in your catalog modeling exercise.
Ready to dive into eCommerce catalog modeling? Reach out to the team of experts at Object Edge today.
