Types of sources and resources
The source can be a service, an employee or a place that your customers will book. The specific combination and the way you use each type of resource is up to you. Resource information is used not only in the reservation offer itself, but also in the guidepost and all booking information.
Resources describe the basic features of reservations and answer customers questions:
- WHAT I reserve (SERVICE)
- WHERE reservation will take place (PLACE)
- WHO reservation / service will be made (EMPLOYEE)
Set up and use resources
You can add, edit, or delete resources as you like. However, it is always important to keep in mind that a resource can already be tied to a event and used on specific reservations. The number of concurrently active resources is limited, based on the reenio subscription package currently purchased.
When creating resources, we recommend that you think carefully about what resources you create and how you will offer them for booking. If it is not necessary for your particular business and reservation offer, then it is not necessary to create and use all types of resources. The resource should be used if it affects the offer and choice of the reservation or specifies the booking information. In simple cases, there is no need to set the resource for the event at all, just set the name of the event. In this case, however, it will not be possible to filter or include the events in the signpost by specific sources.
You can enter up to three different types of feeds within a single event and select one specific feed within those types. You can select more than one resource for any type of resource to make it easier to create events. Typically, it is eg a PLACE type resource where you set up/use all 4 available tennis courts within one event. The system will automatically create an offer, displaying each resource separately and the customer will be able to choose from 4 different courts with the same deadline parameters.
If the event has resources set, then it is not necessary to enter its name, but the name is automatically compiled according to the assigned resources. If you still enter a name for the event, it will be used first.
Collisions monitoring in time
In addition, the resources serve as an information basis for the offer of events, incl. filtering and guidepost, and then as information for individual reservations, it is also a very important element in automating the reservation process. Thanks to collision monitoring it is possible to set up automatic evaluation whether it is possible to create a reservation for a particular time or not because of the use of the given resource, eg occupation of the sauna by another reservation at the same time. Collision monitoring is available for most types of dates, ie it is not available, for example, for a event using a seat reservation.
When activating collision monitoring within each event setting, we recommend that you consider and plan well the dependencies between resources and events. Incorrect settings can cause unnecessary deadlines!
In case two events are linked to one resource (a particular resource of the same type), two bookings cannot be made at the same time (of course in relation to a particular offer and way of booking for a particular business). An example could be the rental of a multipurpose playground where more sports activities can be carried out. One course is understood as a PLACE resource and each sport will correspond to one SERVICE resource. When booking a course for one of the sports, the course must be automatically blocked for all other sports, otherwise two customers could simultaneously reserve two different activities at the same time, but the course is only one.
Event - (Editing event) - Collisions monitoring
We must therefore use collision monitoring, when we activate it on a type of resource that is restrictive in terms of the impossibility of existing reservations. In our case, it is a PLACE type resource. The evaluation of the collision is done by taking into account all the specific resources of the type and comparing them with existing reservations. If there is a reservation (including time pauses) using a particular resource at a given time, the system will not allow you to create another "collision" reservation.
When collision monitoring is set, it is also possible to determine whether the collision should be evaluated within the given deadline or only between different deadlines. In practice, this means that if the appointment is of a larger capacity, then collision monitoring within the appointment will make it impossible to make more than one reservation at a time and with adequate resources, even if the available capacity is sufficient! This can be used when, within a deadline, resources of one type are selected in bulk, eg booking one tennis court blocks all other tennis courts at a given time.
The collision monitoring principle allows use for blocking a longer period of time, for example in case of shutdown, reconstruction or vacation. If you want to prevent bookings for certain dates or only parts of them, we will make use of booking out of date in combination with the use of collision monitoring.
Reservation - New reservation - Without event or the New Reservation icon in the taskbar
Configuring collision monitoring for out-of-date bookings will appear on the resulting booking page as an already booked event (red highlighting is slightly lighter for blocked events than for classic direct bookings), so customers will not be able to make new reservations. When setting up this special reservation, it is necessary to select the appropriate specific resources to be blocked and also to enable collision monitoring for the given resource types.
In order to block the reservation options by the customer, it is important to keep in mind that collision monitoring must be set at least once per given time. Either when setting the given date (in relation to future bookings) or when creating the reservation itself out of date.
The example below illustrates how we can simplify our work if not just 3 COURTS are set as sources, but a service source called TENNIS that will be included in all events. If you need to make it impossible to book courts in a given period (eg a tournament), we will make a reservation outside the deadline (regardless of whether or not the default deadline has collision monitoring). For this reservation, we set collision monitoring to SERVICE type resources. Of course, at this moment there must be no standard reservation for the specified source and time period, because then the booking could not be made out of time correctly!
The benefits of this two-source solution are two. We do not have to make as many out of date reservations as there are individual courts (to block all reservations). Also, if we build the resources for a guidepost, we can use the name of a specific service, ie TENNIS. If necessary, customers can be informed about restrictions or changes through the text content of the booking page or other communication channels (SMS, e-mail, etc.).
Collision monitoring functionality is a very effective tool for automation solutions within the services offered. It is thus possible, for example, to block reservations for individual tennis courts in the hall if the customer has already booked the entire football hall. However, it is important to understand the principle of functioning, to try and to design resources well and how they are interconnected.