User Tools

Site Tools


doc:initial_setup

Initial Setup for Owners

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.

Enter your property data

AvailApp uses the following hierarchy: Property → Category → Unit.

  • A unit is a hotel room or apartment that is part of a property.
  • A property is a hotel or apartment complex you own/manage typically distinct from other properties through its location/branding.
  • A category is a set of units from the same property that are equivalent or almost equivalent. For example if you own a city hotel with 20 single rooms and 20 double rooms, you should create two categories. That's because a couple interested in staying at your hotel probably does not care exactly which of your double bed rooms are still free, they just want to know if any of the 20 double bed rooms is still free. If your hotel is located at the beach though, only some rooms might have unobstructed beach view and are therefore more attractive than others. In such a case it might make sense to have 4 different categories, i.e. single room seaview, single room non-seaview, double room seaview and double room non-seaview.

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.

Edit custom states and fields

Custom fields

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:

  • field type: Depending on the amount of data you want to potentially store in that field you can either select “one-line” or “multi-line”. The former is best suited for e.g. phone numbers and the later is best suited for e.g. “special wishes”. This setting can be changed later on, so if you are unsure, select “one-line”.
  • show in journal?: If you want to have the contents of this field printed in your day's journal, enable this setting. For example if you have a “special wishes” custom field, you could write things like “needs one baby cot”. Such info would be handy to in a list for all customers arriving at one particular day, so that arrangements can be made accordingly.
  • partner access: If you give some of your partners backend access (see below), this determines whether these partners can view/edit the contents of the custom field. Note that partners with view only backend access will not be able to edit the field, regardless of this setting; partners without backend access won't be able to view/edit any of the custom fields.

Custom states

By default, AvailApp knows only the 3 “base states” that a booking can have:

  • occupied: This is a confirmed booking.
  • option: An option is a booking that is not yet confirmed. Availability requests will show the unit as occupied during that period, but users with backend access will be able to see that it is only an option.
  • out of service; This is not actually a booking but rather a way to tell AvailApp to display a unit as occupied even though the unit is not actually generating any profit during that time. For example, the unit might be closed due to renovation.

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.

Add your partners

A “partner” in AvailApp is someone that you can

  • share your availability information with
  • assign/attribute a booking to (i.e. mark a booking as being brought by that partner)

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.

  • no access: No access to neither the availability nor the backend. This setting only makes sense if you manage multiple properties and for some reason you won't allow a certain partner access to some of your properties. It might also make sense if you just want to keep record of bookings made by this partner.
  • check availability on property level: This is the lowest level of access. The partner will only be able to see if a certain number of people can be accomodated in a certain time period. Please note that if you have the tariffs module enabled, the partner will also be able to see a price range for his request which might make it possible to deduct a little bit more insight.
  • check availability on category level: Similar to the above, but with access to category level as well, i.e. the partner will be able to see which categories are still free.
  • check availability on unit level: Full availability access, i.e. the partner will be able to see whether each individual unit if occupied or not.
  • backend access (view only): Includes the above, but the partner will be able to see the same occupancy table as you do. Well, almost: The bookings will be colored according to your partner's settings, not yours. The partner will not see your custom fields and also not the partner associated with the booking (hence only the partners “own” bookings will have a different-colored strip at the top). The partner will not see any statistics, can't access the journal and can't change the bookings.
  • backend access (insert & edit own bookings): Similar to the above, but the partner will be able to create bookings (including options). Such bookings will automatically be associated with this partner. The partner will also be able to edit bookings that have been associated with him/her.

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.

doc/initial_setup.txt · Last modified: 2013/12/03 08:24 by admin