Design Guide: Pricing for Websites

A simple website will interface to the retailers instore management systems and extract products and pricing information. This works well initially and everything works well. In store though, retailers often implement quite advanced pricing rules and want the website to reflect these same pricing rules.

Reproduce Store Pricing on Website

The problem around pricing is simply the complexity of the different options:

• Products start with a retail price for each item. This is the ticket price observed by customers in the shop
• This single price per product may be extended by having multiple prices against each product, called pricebands. A priceband is often selected based on the customer. For example, some retailers create a "Trade Price" priceband which is granted to trade customers.
• Spot pricing rules might be created handle specific pricing exceptions. These are called "Pricemaps" in Fieldpine. For example, a pricemap might be created to allow a single customer A, buying item B in store C, during the month of July to pay only $z

The above pricing is relatively simple to implement with a products table

Product	Ticket Price	Priceband Trade Price	Priceband SPCA members
Dog Food 10kg Bag	$14.95	$11.40	$12.16
Cat Food 500gm tin	$2.95	$2.06	$1.97

And also a pricemaps table for exceptions

Product	Customer	Date	Price
Dog Food 10kg Bag	Bob	July	$9.88
Dog Food 10kg Bag	Sues Kennel and Boarding	July to Sept	$9.14

Now lets throw some discounts into the mix. Consider a 10% off coupon for dog food. Who does this apply too, Normal retail (ticket price)? Trade Price? SPCA? What about Bob and Sues Kennel - are these special prices entitled another 10% discount or is this the final price? While this can be done with flags and listing the exceptions, it is not uncommon to have 500,000 pricemap entries., although only a small fraction of them will be needed for a single sale.

When kits/combo pricing is used, pricing becomes dependent not only on the current item in isolation, but also the combination of items. Fieldpine has a wide range of different kits/combos available, which means that implementing them is difficult to reproduce. Some examples of kits

• Buy an X and a Y for $z. This is the classic combo everyone thinks off
• Buy an X, and get either and A or a B for 20% off.
• Spend $100 on brand Y and get $10 off, spend $200 and get $50 off.

Kits are not represented as a simple table like other pricing methods. Rather each kit is defined as a descriptive set of instructions that are interpreted at sale time. This provides a high degree of flexibilty, but the code is more complex.

Pricing API

An alternative approach to trying to implement pricing is to call the pricing API while the sale is being created. This offloads all pricing to Fieldpine and offers the best alignment with instore pricing. The downside is that you need to call an external API and interface into your shopping cart.

1. Sale is created and first item added
2. A "sale object" packet is created and sent to the OpenApi to price the sale.
3. This API returns the "sale object" with pricing, potential layout changes and other details
4. Your code updates the shopping cart with this pricing
5. Steps 2...5 are repeated as items are added and removed, or as other sale relevant factors are discovered, known customer, has a voucher, etc

Summary - Which to choose?

If your site is "simple" and the retailer only ever wants static pricing, implement pricing the classic expected way.

If you need to fully mirror instore pricing for Omni-channel selling, use the pricing API

If you are not sure, thinks about the following

	Code your own Pricing	Pricing API
Range of Pricing Methods	Limited to those you implement	Extensive
Easy to implement	Yes, for simple pricing. No for complex pricing	Depends on shopping cart integration options
Development Cost	Initial, and ongoing as new pricing methods required	Initial only
Ongoing Cost	None	Usage charged