Case Study: How B2B e-commerce design has to differ from B2C e-commerce

When I was a Business Analyst / Junior Product Manager at LCBO, one of my projects was a B2B e-commerce which was fairly new at the time. As the previous Business Analyst moved onto a new project, I inherited the requirements and scope. The project was Waterfall, and scope had been signed off on. There was not much room to change.

However, there was a burning problem. It required us to empathize with users, and make changes to the plan.

LCBO Business

LCBO (Liquor Control Board of Ontario) is a state-owned company that distributes alcoholic beverages. It not only has its own retail stores and a retail e-commerce, but also sells large quantity B2B to retailers in Northern Ontario, where there are no LCBO stores.

While LCBO B2C sells any amount of bottles and cans to customers, LCBO B2B sells by case of 6, 12 or 24 bottles or cans.

Persona

As always, we have to understand the user needs and pain points. An e-commerce should have basic functionality as browsing products, searching for products, adding products to cart, removing products from cart, and submitting orders.

What differentiates B2B and B2C is the variety and quantity of each SKU (product type) in one order.

A retailer may add hundreds of SKUs, with hundreds of bottles for each SKU. And they often re-order what they got last time with the exception of some additions and removals. And they are often small business owners that have a million things to do everyday. This distinctive persona needs a way to add products to cart, adjust the quantity of each SKU, and submit the order fast.

Problem Statement

Retailers were spending hours or days to do one order. Complaints were flowing in, pointing out multiple problems. We even got on a call with a retailer to witness how they were interacting with our website. Here are the 3 main pain points:

1. No search functionality. And the product display order was not designed to show the most relevant products to users.
2. Having to browse and add each SKU to cart even though it could be the exact same order as last time. Each addition came with a delay and a refresh of the page, making user lose their last browsing spot in the page and pagination.
3. In cart, having to click the + / - buttons to adjust quantity in multiplication of number of bottles in a case. However, each change was associated with a few-second delay for the system to re-calculate product total $ amount, and cart total. During the delay, user cannot take any action.

Solutions

While these problems need a long roadmap and technical design and architecture to fix, there are quick wins.

Even though the scope has been signed off on, the team understood that the problem needed to be rectified as soon as possible to alleviate the pain that users are exeriencing. We had to postpone some of the items in scope to add the quick win fixes.

1. Adding a feature to re-order a past order.
2. Optimize the code to enhance performance and reduce delay time with each change to cart.

Longer-term solutions

Even though the re-ordering feature already helped with most of the pain that our users were experiencing, things could get better. However, because there was a plan to switch the frontend builder and hosting service away from this legacy system, we decided not to spend too much efforts in optimizing the design of the code when somthing changes in cart, search functionality, and the product display algorithm.

Once we would have the new system in place, we would leverage the out-of-the-box functionality first, then consider the above-mentioned long-term solutions.