This may seem obvious, but it's worth considering. I-Reserve can be used in many different ways and has clients in various sectors. Therefore, it's wise to determine in advance what can be booked through i-Reserve now (and potentially in the future). For example, are these rooms, bungalows, chalets, boats, courses, golf courses, guided tours, training sessions, fitness classes, etc.?

This information is also important for determining the corresponding license and the sector of the institution. For example, a sports center is more likely to offer classes than a brewery offers tours, a school offers courses, and a conference center offers rooms.

The standard answer will be website visitors. But who are these?
Are they participants in a course, visitors on a tour, or dogs at a grooming salon? Should a distinction be made between adults and children? Is it perhaps necessary to differentiate between older and younger children for children? For example, because children under 3 don't have to pay.

Are there situations where multiple spots need to be booked for one person? For example, people in wheelchairs attending a theater or boat trip, where the wheelchair is wider and two spots need to be freed up.

Will you use i-Reserve as an internal application, with bookings made solely by employees, or will visitors be able to book and pay directly online? Direct online booking flows from your own website to a separate link with the booking dialog. Perhaps there are affiliates/partners who can also handle bookings. Will they have their own template/style? Will they be entered through the same channel?

What days and times are bookings available? Can I book by the hour, half a day, or perhaps per activity? Is there a high or low season? Are there recurring activities or activities that last multiple days?

i-Reserve offers various dialogs, including the calendar, schedule, search & book, and course list. Depending on whether the activity is related to courses, training sessions, tours, or objects like halls, boats, or bungalows, specific dialogs are available.

There are four options for using customer accounts when making a reservation:

Don't create a user account
Always create a user account
i-Reserve automatically creates a username and password
Customers can create an account but aren't required to do so
i-Reserve supports all four options.

Whether a customer needs to log in has advantages and disadvantages.
If a customer does need to log in, the advantage for you as the end user is that they only appear in the system once. This ensures all reservations are properly registered under the same customer. Otherwise, a customer would have to re-enter the customer form for each reservation. If the information doesn't match exactly, a new customer will be created.

The advantage for the customer is that they don't have to enter all their information every time, as it's requested when logging in. Customers can also view their reservations and/or invoices or cancel any reservations online. The disadvantage is that customers have to create an account during the reservation process, which can be an additional hurdle. They also have to store a username and password. This last issue could be resolved by allowing users to log in with, for example, their Facebook or Google account.

Are there spaces that can be subdivided to make them more likely to be booked? Are there multiple locations? Are there trainers/instructors who can only be scheduled once on a specific day/time?

What information do your customers need to provide when making a reservation? Is it just a name and email address, or do you also need company information, billing information, gender, and date of birth? What's mandatory and what's optional? Do you want customers to be able to sign up for a newsletter?

During the process, from making a reservation to completing the activity, a reservation can have a specific status. This status can change throughout the process. A simple example is that when a reservation is paid, it will be marked as PAID.

We document this process in a workflow. Within the workflow, one or more emails can be sent to the customer, an external party, or internally within your own organization based on the status changes. It's also possible to automatically send emails or text messages, for example, before the reservation starts as a reminder or the day after as a thank you.

A reservation comes in, what actually happens with it? Try to write out various scenarios beforehand, starting with the most desirable scenario where everything goes well. Then, consider what happens if things don't go as planned, for example, a cancellation, someone not paying, a change of product/service, etc. All the statuses a reservation can have are then included in the workflow.

A workflow can be very simple or very complex. Below is an example of a relatively simple workflow, which you can use as a basis for setting up your own.

If you want to review the incoming request yourself, the administrator must manually confirm or reject it.

If you also want to process a mandatory payment in the workflow:

Once you've defined all the reservation statuses and connected them, you'll see a workflow emerge. You might need to perform some automatic actions within the workflow. For example, sending an email reminder if payment hasn't been made 30 minutes after booking. Or automatically closing a reservation if payment hasn't been made 1.5 hours after the reminder. These actions are indicated in the workflow with dotted lines.

Decide which emails need to be sent within the workflow. These could be emails when a status changes (e.g., new arrival, canceled, or paid), but also automatic emails at specific times. For example, 30 minutes after a reservation is made and no payment has been received.

Write down all the emails you need, number them, and think of a subject line and text that should appear in the email template. Also consider emails that need to be sent internally, for example, to a manager or the restaurant. Include these in your workflow as well.

You might want to notify the customer by text message a few hours before the reservation takes place. Or, assuming the customer will be there half an hour beforehand, you might call them to the counter by text message five minutes before the reservation.

It's always a good idea to test everything you've configured or modified yourself. For example, run through the entire reservation process after modifying an item. Test your email templates by entering a reservation number and clicking the "Preview" button.

It's even more important to thoroughly test settings after we've configured or modified something. This could include settings made during the workshop. Testing after a workshop is crucial, as many settings are often configured during workshops. We also expect this after a support request in which we've configured something for you.

Conduct these tests within two weeks and report your test results. Try to compile all your findings and submit them in a ticket to our support team. We'd also appreciate hearing from you via a support ticket if the settings are satisfactory.

Testing Email Templates
You can test the email templates in several steps.

First, enter the reservation number or invoice number in the email templates, depending on the context, and click the "Preview" button. Next, send the email from a reservation to test whether it displays correctly in the mailbox.
Testing Object Adjustments
The easiest way to test object adjustments is to fully review the reservation dialog on the client side.

Have you adjusted the calendar? Then click on all the dates you've adjusted to see if they've worked.
The same applies if you've adjusted the opening hours. Check if you can click on all the expected opening hours.
Has a price schedule been adjusted? Then check if all prices are correct. If you've added options, check if they work as expected.
Testing Color and Other Styling Adjustments
The best way to do this is by reviewing the client dialog. Use CTRL+SHIFT+R first, otherwise the old colors will remain in your browser cache. So refresh your browser. Still seeing the "old" styling? Then read https://browsercache-legen.nl/ to see how to clear your browser's cache.

Testing User Permissions
Log in with the user whose user permissions you've adjusted and check whether you can actually do what you expect, or if you can't. If you're unsure how to test your changes, we can advise you.

Testing Workflows
Testing a workflow is one of the most important aspects. Therefore, we'll explain it in more detail. Testing a workflow is not only a lengthy process, but it's also not always easy because you have to include all statuses and automatic emails. You also want a workflow to be configured correctly the first time, as making changes to it later is often much more difficult.

Depending on whether you configured the workflow yourself or we did, you'll have a flowchart of it. For an example of a flowchart, see step 9. If you've worked on the workflow yourself, it's recommended that you create a flowchart. This won't help you with testing, but it's also useful for later system optimization. Ideally, you want to check all the lines in your flowchart and ensure they're configured correctly. You also want to verify that all situations that could occur in practice have been addressed in the workflow.

It helps to write down use cases. Then replay them in i-Reserve.

Example 1: A customer books themselves on the website and the payment fails.
Replay: Create a booking as a customer (i.e., on the front end) and don't pay for it. You can see what happens to the booking by looking it up on the admin side, checking its status, and which emails the customer receives.

Example 2: A customer calls to make a booking and should receive an email with an accept link. The customer accepts the booking.
Replay: Create a booking for a customer on the admin side. Check if an email is actually sent to the customer. In the email, click the accept link and accept the booking. In the admin side, you can see exactly what status the booking goes to after accepting and whether any further emails are sent.

Example 3: When a customer makes a reservation, it's not yet a confirmed reservation; it still needs to be accepted. If accepted, the customer receives an email, and 5 days before the reservation is due to take place, they receive a reminder email.

Rehearse: Create a booking for a customer on the front end. Then, find the reservation in the admin area and set it to accepted. Check if an email is sent. Then, wait until 5 days before the reservation to see if a reminder email is actually sent. If not, clearly indicate what the