Price formula example: How to create seasonal prices
Stores may need to set the price of their products differently based on the time of the year. For example, rooms and services of a resort could be more affordable when it is low season and more expensive when the demand is higher.
Thanks to price formulas, WooCommerce Product Options makes setting up a similar price model very easy. Let's see a simple example.
Room booking
A website promotes an apartment for rent on a mountain that becomes a popular tourist attraction during the ski season but also in the summer. The owner of the apartment wants to set different prices for reservations throughout the year, according to the following plan:
- base price, from June to August (mid season)
- 25% OFF, from March to May and from September to November (low season)
- 30% UP, from December to February (high season)
What we need for this configuration:
- A Date option for the check-in date. We will call this Checkin.
- A Date option for the check-out date. We will call this Checkout.
- A Price formula option for the price calculation.
For the sake of simplicity, we will consider that a reservation falls into one of the three price brackets when the Checkin date does. With this assumption, we will take advantage of the month property of Date options, which returns the month of the date selected by a customer, as a number from 1 to 12. We will also use another property of Date options, which is daycount. That will help us count the days of the reservation. The price formula is:
if( and( gte( [Checkin.month], 6 ), lte( [Checkin.month], 8 ) ), 1, if( or( gte( [Checkin.month], 12 ), lte( [Checkin.month], 2 ) ), 1.3, 0.75 ) ) * [product_price] * ( [Checkout.daycount] - [Checkin.daycount] )
In a much shorter form, this formula could be conceptually visualized as follows:
if( [is_mid_season], 1, if( [is_high_season], 1.3, 0.75 ) ) * [product_price] * [total_days]
Let's analyze that shorter form:
if( [is_mid_season], 1, if( [is_high_season], 1.3, 0.75 ) )represents the price factor of a room depending on the season: it will return1,1.3or0.75depending on the reservation being in mid, high or low season respectively;- when we multiply that by
[product_price], we get the cost of the room per day; - finally, we multiply that result by the number of days and we get the total price of the reservation.
While the first version of the formula works as intended, it is long, complex, and prone to errors if we ever need to adjust it over time. For this reason, we will follow the shorter rendition we offered above and take advantage of custom variables to break down the formula into smaller parts. When it comes to custom variables, the most important fact to remember is: Use them! The custom variables we are going to create are:
is_mid_season, defined asand( gte( [Checkin.month], 6 ), lte( [Checkin.month], 8 ) );is_high_season, defined asor( gte( [Checkin.month], 12 ), lte( [Checkin.month], 2 ) );room_rate, defined asif( [is_mid_season], 1, if( [is_high_season], 1.3, 0.75 ) );room_price, defined as[room_rate] * [product_price];total_days, defined as[Checkout.daycount] - [Checkin.daycount]
With all the above variables, the main price formula becomes:
[room_price] * [total_days]
Much more neat, isn't it?!
There is one final improvement that we could add. The apartment owner might want to adjust the pricing factors every once in a while and meddling again in complex formulas is never a good idea. So, why don't we create two new custom variables that simply contain the two price multipliers 1.3 and 0.75 as constants? With that change, we would have:
low_factor, defined as0.75;high_factor, defined as1.3;room_rate, defined asif( [is_mid_season], 1, if( [is_high_season], [high_factor], [low_factor] ) ).
One major benefit of using multiplying factors, here, is that the whole price structure will change by simply adjusting the base price, which is the product price.
Let's now look at this formula configuration in the real plugin's user interface.
View our demo page to see this formula in action.