The following guide will explain how to to the initial work you need to do in order to start sharing you availability information through AvailApp.
AvailApp uses the following hierarchy: Property → Category → Unit.
Assigning categories to units is optional. If you are having trouble with the concept of categories, then just set up your properties and units first and don't assign any categories until you get more familiar with AvailApp. A good rule of thumb is to assign the same category to all units that have the same pricing rules.
Pro Tip: If you don't want a specific room to be visible anywhere except when you're logged in into your AvailApp account, you can assign the special category “unpublished”. This sort of think makes sense for rooms that are only for private use etc.
You can set up custom fields to store additional data together with your booking. By default, each booking only has a name, a state, checkin/checkout date and a partner. If that's all the information you want to store in AvailApp, you don't need to setup any custom fields. However, you might find it convenient to have additional data e.g. the guests' flight numbers stored together with the booking. That way you can see and edit this information whenever you click on a booking.
You can create a new custom field by clicking on the “add custom field” button. For each custom filed you have the following settings:
By default, AvailApp knows only the 3 “base states” that a booking can have:
No matter what state a booking is in, it will always cause a unit to be displayed as occupied in an availability request. The difference is only the visual representation in the backend. Another difference is the calculation of occupancy percentage: Let's say we want to calculate the occupancy percentage for a property with 10 units for the month of January. Normally, to have a occupancy of 100 %, you must have a “occupied” booking on all 310 unit-nights. Bookings in the “option” state will be treated as non-existent for calculating the occupancy percentage. Also, if 2 of your units are being renovated for 14 days each, these bookings will not be counted towards your occupancy percentage. In fact, the max. number of unit-nights in this month will reduce to 282.
For each state you can select a color and whether you want to be able to see a report for all bookings in this state.
You can also create more one state with the same base state. Let's say you require your guests to pay upfront: 30 % of the invoice total are to be paid at the time of booking and the remaining 70 % are to be paid 14 days prior to arrival. If you want to store whether the client has paid 0 %, 30 % or 100 % in AvailApp, you could create a custom field to hold this information. However, if you want this information presented more visually, you could create two more states with the base state “occupied” and rename the existing “occupied” state so that you effectively have three “occupied” states with the names “unpaid”, “partly paid” and “fully paid”. You can then select different colors for each state and enable the report for “unpaid” and “partly paid” bookings.
Another example would be allotments that tour operators have placed. For that, you might want to create a new state with the name “allotment” and the base state “option”. Than you can create bookings for the alloted units and use this state to represent that they are not actual bookings.
Please note that there must always be at least one state for each base state.
The “partner access” column determines whether a partner with backend access (see below), can view/edit a particular state. If you give your partners only “read” access to a state, they will not be able to select this state when they edit a booking. If a booking already has such a state (probably because you selected it earlier) they will not be able to change the state of the booking to any other state. If you set the partner access to “none”, the same behaviour applies; in addition, your partners will not be able to see the name of the state even if a booking has this state. Instead, they will see the basestate along with an asterisk e.g. “occupied*”. For example, you might employ states that reflect whether or not a booking has been paid yet. You might want to restrict your partner's access to such states. This is especially true if your partner could have a reason to change the state without you knowing it e.g. if a state codes for whether or not your partner has collected his/her commision. It might also make sense to restrict rarely used states in order to avoid mistakes or confusion. For example, a “closed for renovation” (out of service) state should probably be “read” only because none of your partners would/should create a booking with this state. Please note that you have to give “write” access to at least one of your states if you want your partners to be able to create any bookings at all.
The “maximum ttl in hours” (ttl = time to life) column determines after how many hours an option is forced to expire. If you do not set a value, setting an expiry time is optional for such options. This feature is pretty useful as I prevents you and your partner from accidentally creating stale options. Please note that the setting only applies for newly created or edited options. The setting applies for both you and your partners with backend access. If you want to have different “maximum ttl in hours” for you and your partners, you need to create two different kinds of options and give your partners write access to only one of them.
A “partner” in AvailApp is someone that you can
A partner could be a Sales Agent that logs into the AvailApp backend to check the availability or it can be someone who uses the API (e.g. your own website or a third party website).
For each partner you can select a color. This color will be used as the top border for booking that you have assigned to this partner.
For each partner and each property you can set different access levels that determine how much insight the partner gets into your business.
If you select “check availability on X level” access, you will also be able to select up to which level the partner has “daywise” access. That means he/she will be able to see exactly what days are occupied during the requested period. If you don't give daywise access, the partner will only be able to get a “yes or no” answer. Note that it is possible for example to give a partner access up to unit level, but daywise access only up to category level. As a security measure, partners that do not have backend access will not be able to make availability check for periods in the past.
If you are not yet familiar with the access levels, create a partner for some email address you own (other than your main account) and play around with the settings until you think you have found the right trade-off between allowing you partners to perform and keeping your data safe. When making an availability request with your main account, you will also be able to test drive the settings you've made for your partner by using the “Simulate how one of your partners sees these results” feature.