Log in

Dorridge Village Hall (Staging)

Pricing Guide

Hallmaster Conditional Pricing Guide
Conditional Price Rates Initial Setup Before proceeding with this guide, you should have setup in your venue: 1. Your rooms 2. Your Charges Matrix 3. Your Activity Types Unlike the main User Guide, this guide is not set out in numbered steps for you to follow along in order. Instead we recommend that you read through the guide in full before starting to enter your Conditional Price Rates. You will find the link to Conditi onal Charges on the Admin > Charges Matrix page. You can then of course refer back to this document as a ‘cheat sheet’ for future use. If you have any questions after reading the document, then please contact us (see details at the end of this document) Note: If you are looking to set your room prices to change based on time of day, then you need to look in the Setup and User Guide, rather than this document. What are Conditional Price Rates? Conditional Price Rates are special Hire Charges tha t automatically select other Hire Charges based on Condition s you have setup. This can be used to automatically assign price rates to your bookings based on the details of that booking, for example assigning your ‘Week Day’ price rate to any week day boo kings etc. Conditional Price Rates alone do not have monetary Costs in your Charges Matrix, and are instead tools to select a cost in the Matrix automatically. You assign Conditional Price Rates to your Customers exactly as you do with any other Hire Cha rge, by adding an Activity and linking the chosen rate that way. By choosing a Conditional Rate however, you can skip assigning new activities to the customer for each Hire Charge, and instead just assign the one Conditional Rate, which will then do the re st for you for each booking.
Create a New Conditional Rate To Create a new rate, go to the Admin > Charges Matrix page and Click the blue ‘Manage Hire Charges and Conditional Rates’ button menu and press ‘Create New Hire Charge’. Enter the name and any notes for this rate, then s elect ‘Conditional’ in the Status box . Once selected, you should see a panel appear below this section titled ‘Setup Conditional Price Rate’ You can use this panel to enter the logic for this price rate, then press Save when you are done. To edit an existing price rate, use the ‘Edit’ icon from the Hire Charges list. Entering the Price Rate Logic A Condition al price rate is made up of Branches. A Branch is a set of Condition s that ends with one of the Hire Charges in your Charges Matrix. The basic structure of a Branch is “If [a list of Condition s] are all TRUE then the Price Rate is: [the resulting price rate]“. Every Branch will have at least one Condition , and will always result in a single Hire Charge from your list. A Condition is then made up of a Property (some info about the booking such as start date, rooms used, booking duration etc) and a State. The States available depend on the Property selected – for example for the ‘Booking Duration’ Property you could have a State of ‘More than’, ’Less than’ or ‘E xactly’ a certain number of hours. For a Branch to match, ALL of the Condition s in that B ranch must be true. If any Condition s are not true, then the system will check the next B ranch until it comes across one that does match. If two or more Branches are both true, then whichever appears first in the list is used. You can reorder your Branches using the provided arrow buttons.
If none of the B ranches match, then the Hire Charge selected in the final ‘OTHERWISE:’ dropdown menu at the bottom of the page w ill be used. Note: The logic you have entered for this price rate may work out so there is always a matching B ranch. In which case this final OTHERWISE box can be ignored, however it cannot be removed purely so the system has a ‘catch all’ in place . To ad d a new Branch, click the green ‘+’ button To add a new Condition to a Branch, click the green ‘AND’ button You can then remove a Branch or Condition using the red Dustbin icon For each Condition in a Branch, you select a Property from the first dropdown menu. Once you select a Property , the available States will appear in the next dropdown menu. Some States may require extra information or ‘Parameters’, in which case another input will appear next to the State, which could be a list of days, ro oms, or a text box for you to enter a number etc, depending on the State. In each Branch there is a dropdown menu after ‘THEN:’ which contains a list of your Hire Charges. This is where you select the resulting Hire Charge if all of the Condition s in this Branch are true. See below an annotated display of a full Conditional Charge – this may look complicated, but it should soon become clear what all of this means!
A Simple Example We’ll start with a simple example of a common scenario you may find. Your venue charges a different price rate depending on if the booking is on a Week day or a Weekend. You have already setup your weekend prices as a Hire Charge called ‘Standard Weekend’, and your week day prices as ‘Standard Weekday’ – these are b oth Hourly rates, and the costs of these can be seen in the Charges Matrix. The Logic for setting this up is shown below. If you go through reading the text on that page, you should find that you are basically just reading out the logic you want in plain English – for this example: “If Start Date is A Weekend Day Then Standard Weekend (Hourly). Otherwise Standard Weekday Hourly” And that’s it! Your first Condition al price rate is finished and could now be assigned to your customers. Next, we’ll c over a slightly more complicated example.
A More Complicated Example For this example, we’ll continue to build upon the previous logic we setup. In this scenario, we still have our Weekend and Weekday prices, but we charge extra for bookings with more than 20 attendees – bookings of more than 20 attendees are put on ‘Large Group’ rates . The logic for this is set out below Again, this can effectively just be read out in English to see the logic for each Branch. You will see that the Conditions fo r ‘Number of Attendees’ has an extra input for you to enter a number of people. As mentioned previously, some States will need extra information like this. You will see that these Branches have multiple Conditions inside them, joined by the word ‘AND’. This means that in order for this Branch to match, both of the Conditions must be true. For example in order for the first Branch in the list to match, the b ooking in question must start on a Weekend Day AND must have more than 20 attendees. If either of these things is not true, then this B ranch cannot match and the system will check the next B ranch and so on .
You may have noticed that some of the Condition s in this example aren’t actually needed, and the logic could be simplified to have fewer properties and Condition s. This is certainly the case, the example here has been written out very explicitly for clarity’s sake, and if you prefer to write the logic out in the more verbose way then that will work just fine. Likewise if you prefer to have more concise logic, you can set this up in the same way . Explicit or Implicit? Taking the previous example again, you will see that every possible outcome of the rate has been explicitly entered. Assume the booking we are dealing with takes place on a Weekend and has 10 attendees. We are expecting this booking therefore to be using our ‘Standard Weekend (Hourly)’ rate. Take these two B ranches: The firs t Condition of both Branches checks if the current booking starts on a Weekend. The second Condition then checks the number of attendees. The first Branch checks if the number of attendees is more than 20 people. If this is not true, then it moves on to the next B ranch . The second Branch then checks if the number of attendees is less than 21, which for our example booking with 12 attendees is indeed true, so the Standard Weekend rate is used.
Since we are only using whole numbers, if a number is NOT mo re than 20, then it can ONLY be less than 21. As such the second Branch does not need to check for this explicitly, as we already know that if the previous B ranch did not match, then the number of attendees HAS to be less than 21, so this Branch could be s implified down to: Additionally from this example, take the final Branch This is effectively checking that – if none of the previous B ranches matched – is the booking on a Weekday – AND is the Number of attendees less than 21 – if so, use the Standard Weekday rate. As mentioned previously, every Condition al price rate ends with a ‘catch – all’ result – you can think of this as an ‘if none of the above are t rue’ result. In this example, the previous B ranches have already checked: 1. Does the booking start on a weekend – if so, are there more than 20 attendees? 2. If the above is NOT true, then does the booking start on a Weekday – if so, are there more than 20 at tendees? 3. If neither of the above are true, then does the Booking start on Weekend? So if we have reached this fourth Branch, we have already ruled out that the booking – does NOT start on a weekend, and does NOT have more than 20 attendees. Since we aren’ t checking any other details for this example, we know that our fourth B ranch is just explicitly checking ‘Are none of the above B ranches true?’, in which case it could be removed altogether, as we already have a ‘none of the above’ option by default.
A fter applying the reductions discussed, the whole price rate logic now looks like this: This logic is exactly the same as the original example, and all of the results would come out exactly the same using either method. The original example was being s trictly explicit, and every outcome was written out specifically, and the ‘catch – all’ result was never met. This simplified example allows Condition s to be implicit, so only the Condition s that are specifically needed are written out, and any Condition s that are implied have been reduced out to produce a more minimal price rate. Which of these methods you use is entirely down to personal preference. Being more explicit can help make the logic easier to read and write out, and can help avoid mistakes. Be ing more implicit can help reduce the amount of information you have to enter and can make for a more efficient set of Branches and Conditions.
Things to Watch Out For The final thing we want to cover is a few items that you should watch out for when setting up your rates. These are small issues that could make your rates come out wrong, but might go unnoticed if you aren’t looking for them specifically. 1. If a Branch c ontradicts itself, then it can never match. Take this example Branch In this Branch, we are first checking if the bookings starts on a weekday. If this is true, then we check the second Condition – does the booking start on a weekend day? Since a booki ng cannot start both on a weekend AND a weekday, this Branch will never match as true. In a situation like this it’s likely that the second Condition was accidentally added, and does not need to be there. This would be resolved by removing the contradictin g Condition using the dustbin icon next to the ‘ADD’ button. 2. The order of your B ranches matters Take these two B ranches: For our pricing structure here, weekday bookings with more than 20 people should use the ‘Large Group Weekday’ rate, and other we ekday bookings use the ‘Standard Weekday’ rate . You may have already noticed where the problem with the logic above is, but we’ll run through each B ranch in step with an imaginary example booking.
The example booking is a Weekday booking with 50 attendees. We are therefore expecting the rate to be ‘Large Group Weekday’. We start at the first Branch – if this B ranch matches, we would get the ‘Standard Weekday’ rate. Then check the first Condition of this Branch – “IF Start Date IS A Weekday” This Condition is true, the booking does indeed start on a weekday, and since there are no other Conditions in this Branch to check, we know that this Branches matches as true, and we therefore get the ‘Standard Weekday’ rate. But that’s not wh at we were expecting, so what happened? As we mentioned before, the first Branch to match is the one that is used, regardless of if there are other B ranches that also match later on. So in this instance, had our first Condition been second instead, we wo uld have had the expected rate come out, as seen below Here we come back to the idea of Conditions being Explicit or Implicit. Had we been writing our logic explicitly (ie specifically checking that the number of attendees was ‘less than 21’ in order t o get the ‘Standard Weekday’ rate) , then it would not have mattered which B ranch came first as they could not both be true. Basically this means you need to make sure your Branches are in the correct order for your logic to work. You can reorder the Branc hes using the up and down arrows next to the ‘OTHERWISE’ label. SUPPORT – here to help! On your dashboard you will see a button for ‘Contact Us’ C lick on this button to log a support ticket for any questions you may have , or email us directly at support@ hallmaster.co.uk