New tools for catalog managers building complex pricing schemes in an enterprise e-commerce application
Mozu was an enterprise e-commerce platform I worked on at Volusion.
Background
A typical merchant sells a single catalog of products on a single site at a single price. Larger merchants with multiple channels — B2C, B2B, education, government, etc. — typically offer each channel its own set of products with unique pricing.
To manage the more complex use cases, Mozu offered its clients two objects:
- Sites — Their websites, for ex: Acme.com, AcmeKids.com, Acme.co.uk
- Catalogs — Collections of products and pricing
Here’s an example using a fitness seller:
- Individual catalogs for footwear, active wear, and equipment handled by different managers
- Unique sites for adults, kids, and schools, led by different business units
- One or more catalogs set to run on each site
The problem
Some clients wanted more control on pricing to do things like:
- Sell a subset of a catalog running on multiple sites at different prices for one of those sites
- Discount a few products for a particular customer segment(s)
- Discount certain products for a date range
- Change pricing for certain currencies
- Various combinations of all of those
Our solution
A price list was a new child object of a catalog. Each price list contains a subset of products from the catalog, the prices they were to sell at, and one or more conditions to be met for the price to apply.
There were two user expereiences to consider:
- The client admin managing price lists
- The logged-in shopper
An early shopper flow we captured looked like this:
We added quite a few more criteria over time, and solved the yellow sticky about multiple price lists by including a rank field for each price list.
The admin UI
At first, Price Lists was another tab in the Catalog editor:
This worked well for a user working on one price list, but each edit to a different list required a trip through its parent catalog, and sometimes a currency selection.
To reduce the amount of clicking, we gave price lists their own space with a catalog filter:
We worked with engineering to determine the price list object, which defined the creator/editor:
Select products from the associated catalog are added to the price list manually or by import.
For each product in the list, the admin sets conditions under which the price is valid, and the pricing:
Less common pricing aspects are kept in the Advanced tab:
A minor UI problem
The pricing editor displays the parent catalog’s pricing for each field as placeholder text. If nothing is entered in the field, the default amount is used on the site. But what happens if an admin wants to override the default price with null? Use case: MAP restrictions only apply to B2C or a certain country.
Our solution was to use a checkbox to indicate a null override, which has some complexity. For our dev team, I mapped out the possible scenarios and documented how the checkboxes should react to user input in each one:
User feedback
During the beta period, some users thought they might be changing the price everywhere; an understandable fear. We changed the name of the Pricing section to “Adjustments” to be more clear that these are local changes, not global.
After going live, we added volume pricing adjustments, and a new “Pricing” table (later renamed “Reference Pricing” to be more explicit) which showed the current product’s pricing in other catalogs; a helpful reference for admins juggling all this stuff in their heads.
Results
With price lists, our most advanced clients had the power to do just about anything they wanted with a product’s pricing.
For our company, the feature brought Mozu one step closer to feature parity with our clients’ previous e-commerce solutions, easing client relations.