Knowing the processes, stakeholders and systems involved helps Optimizely Commerce developers being more effective in identifying key components, communicating with stakeholders, identifying challenges and setting up the appropriate testing and quality assurance.
Are you starting a project that is about to implement the commerce solution based on Optimizely B2C Commerce Cloud (Commerce) and you only have the Optimizely Content Cloud (CMS) experience? You probably know that having experience with CMS helps to start working with Commerce but that’s not enough. Having the experience in CMS will help you as a developer to understand some of the terminology and some of the central interfaces for the Commerce but many concepts will be completely new to you. To better understand the differences, and to learn faster how to implement business requirements for Optimizely Commerce it’s good to understand the business processes that are behind those requirements.
While both CMS and Commerce products are tools for managing the relationship with the customer, they are part of different business processes. These processes are at high level applicable to any company but each of our customers has a version that is adapted to their needs. Often our customers are the experts of those processes and have a very specific needs and wishes they want you to implement. Their needs and wishes are based on the way their business is run today and on changes and improvements they wish to introduce. Being able to grasp these processes helps us as developers to understand and when needed, to challenge those business requirements during our refinement and planning meetings. While describing the processes I’ll mention some of the systems that you might needs to integrate into your commerce solution, and I invite you to research (Google, ChatGPT) their purpose on your own. Those systems may “own” the part of the business logic which is behind the business requirements we’re implementing.
Some of the processes involved are:
- Order-to-cash: a series of activities that are necessary to complete a sale, starting with order creation and ending with payment by the customer.
- Customer returns: the process of handling customer returns and exchanges.
- Marketing-to-lead: the process of converting leads into customers through marketing efforts.
These are not exhaustive but covers most of the cases you’ll have to deal with. In this post I’ll talk only about the Order-to-cash process.
The order-to-cash process is a series of activities that are necessary to complete a sale. The process on a high level consists of the following activities:
- Order creation
- Order processing
- Order shipping
There may be more but I’m focusing only on the most important ones for clarity purposes. The implementation of the process varies for each company depending on the business needs and specifics of the industry. This is applicable to companies of any size and in any industry and it often involves systems such as Customer Relationship Management (CRM) and Enterprise Resource Planning (ERP). While Optimizely Commerce does not belong to any of the mentioned categories of systems, it does have some of the essential capabilities of those systems that enable it to function as a completely self-standing e-commerce platform. Larger customers will use the Optimizely Commerce mostly as a storefront and integrate it into their existing IT ecosystem that likely includes both CRM, ERP, and other systems while smaller companies might use some of the commerce sub-systems as their main systems.
This happens when we are capturing and registering a customer order in the system. The order capture is done in two main phases: cart creation and cart checkout. The most important stakeholder is the customer buying the product. How the items are added to the cart and how the customer is funnelled towards the checkout is a very important part of the customer journey user experience.
Some of the Optimizely interfaces and services involved in this part of the process are: IOrderGroup and its extensions by ICart, IPurchaseOrder and IPaymentPlan. In case you need to integrate with other systems during the order capture you’ll probably want to understand how IOrderEvents works. For example, do you need to register the order creation in the ERP before the cart is checked out, or only during the checkout phase?
Another possible scenario to consider is if you need to manage any special logic during IOrderGroup creation or loading. In such case you may want to extend the IOrderRepository.
When adding items to the cart you’ll want to understand ILineItem and how it relates to the Stock Keeping Units (SKUs).
Related to order creation and inventory management, the availability of a product often determines what the customer sees and can do. For example, if a product is not available in the product inventory, the question arises if the customer should be able to see and place an order anyway? The problem we’ll often need to deal with is how close to real time we can get the inventory status for the product. Large customers may already have a system that keeps track of inventory that they want you to integrate with instead of keeping all the inventory related information in the Commerce solution. Those systems are called Order Management Systems (OMS) and Warehouse Management System (WMS). For these purposes you will want to understand the IInventoryService (Adjust method in particularly) and IFulfillmentWarehouseProcessor.
When an order is captured a pick list needs to be created for packing of the physical products before shipment is initiated. For this there will likely exist an external system (one or more) that needs to be integrated that will manage the dispatch of pick lists, printout of the packing slip, inventory etc.
Here the important interfaces are also related to the inventory but there is also the IPurchaseOrderProcessor interface that you can use to manage the statuses of the order based on the processing status. Stakeholders involved during the requirements process are usually responsible for the warehouse management.
The shipment of the order will usually be done by some shipment or logistics provider managing parcels. This means that the stakeholders involved in the definition of the business logic is not necessarily directly your customer but the partner companies that they use for the distribution. They will have an API that you are required to integrate, and it will be standardized so not very flexible to changes.
To be able to efficiently integrate different shipping methods with the Optimizely based storefront you need to implement IShippingPlugin for each external shipment provider in a separate class library and configure those according to the documentation. These providers may expose one or several shipping methods (for example: home delivery or delivery to a pickup place) that have different prices and packaging. Other key classes to understand here are ShippingManager and ShippingMethodDto
This is a part of the Optimizely Commerce product that is a bit more complex to understand from the implementation point of view. The complexity is understandable as it must deal with many different external integration scenarios.
Similarly, to shipment, payment also requires integration with external providers and their APIs. Payment can happen immediately as part of the checkout, or it can be credited to the customer and captured at later time (for example business customers have agreements on 60 days payment terms). This last case is less interesting here and we’ll focus on the immediate payment.
To integrate the external payment providers, you’ll need to implement IPaymentPlugin interface for each provider. You will also need to create the implementation of the IPayment methods, one or many, that are associated with payment plugins. Payment methods are instantiated and added to the IOrderGroup during the checkout of the order. The important class for retrieving payment methods is the PaymentManager.
Stakeholders involved in the business requirements creation usually have expertise in finance and accounting.
I’ve intentionally left the invoicing process to the end of this blog post since invoicing is not done in Optimizely Commerce even though it’s an important part of the Order-to-cash process. Invoicing can be done manually or more likely by a specific external system that’s usually orchestrated trough an ERP.
Even here the stakeholders are finance and accounting experts, and they will have specific business requirements related to regulatory demands on contracts (for example “Does the customer receive the invoice in a specific language?” “Should it be printed or electronic?”), payments (delayed payment), deciding when the order can be booked in the accounting ledgers (this depends on when the shipment is done) etc. All these requirements will impact the status of the shipment and the order.
Another stakeholder that is concerned about the status of the orders, shipments, and payments is the Customer Service Representative that is managing the end customer demands, complaints and returns.
The Order-to-cash process is revolving around the sale, but to be able to sell you need to have a product to sell. Products can be physical products, digital products, services etc. To simplify things, we’ll focus only on physical products those may be sold in a physical store or via web/mobile app and marketed through different channels. The product information needs to be consistent across all these different channels. Large companies use specialized systems called Product Information Management (PIM) and ERP systems to manage all the product information in one place. Optimizely Commerce can handle a lot of the product information on its own and is extendable. This is the part that is easiest to understand for the typical CMS developer. The data describing the product is the content for the “product page” in the same way that any editorial text or image is the content of a web page. The most important part to understand here if you are just starting with commerce is the concept of the Stock Keeping Unit (SKU) and how it relates to products and categories.
We will cover this topic in a future blog post.
In summary, the Commerce implementation differs from CMS in many aspects starting with the business process. To be more efficient in implementing the business requirements for the e-commerce use cases it is good to understand the Order-to-cash process. Also, it’s important to understand which stakeholders that are involved and the problems they are facing, and in the end how you as a developer can technically solve those problems. I hope that this helps in bringing some clarity to the entire journey.