Posts Tagged: public booking requests

More control over “Public” venues

Did you know that MIDAS includes some powerful features which you can enable for the benefit of “non-users”?

Non-users are visitors to your website – individuals who won’t have a dedicated user account within your MIDAS booking system. You may wish to allow visitors to be able to check room availability and make booking “requests” or actual bookings online.

The “Public” features of MIDAS allow this.

The Public features of MIDAS comprise of two similar but distinctly different functions..

Public Web Bookings

The Public Web Bookings feature allows an individual to check room availability, book, and securely pay for their booking online.

Public Booking Requests

The Public Booking Requests feature allows an individual to check room availability and submit a booking “request” online. Once a booking request has been submitted, a “Manager” for that space can quickly approve or reject that request. Requests which are approved become confirmed bookings.

Setting venues to be “Public”

Now, you may not want all the spaces/rooms within your MIDAS booking system to be available for public booking/requesting.

That’s why on the Manage Venues screen, when an administrator selects a venue, there was a tick-box to make the venue “public”.

Until now, marking a venue as “Public” would apply to both Public Web Bookings and Public Booking Requests – if both features were enabled.

For MIDAS v4.41, we’ve made an improvement. You can now make each venue available for just public “Booking”, just public “Requesting”, both, or neither!

Improved Public Venue Control in MIDAS v4.41
Improved Public Venue Control in MIDAS v4.41

This small but significant improvement will allow now you to have some spaces directly bookable by the public. At the same time, you can have other spaces which must instead be “requested” and approved by an administrator.


Better support for “shared” email addresses

One of the features of our software is that it can allow visitors to your website to check room availability. They can then make an online booking (or booking request) for use of your facilities.

As this can be done without requiring a login or a user account. When making a “public” booking/request, the person simply needs to enter their details. This will typically include their name and contact email address.

When a public web booking/request is made, MIDAS checks the email address that’s been entered against its existing client database.

If a single matching client with the same email address already exists in the client database, MIDAS will associate the booking/request with that existing client.

This negates the need for a person to have to re-enter all their information (i.e. address, phone number, etc) each time they make a web booking or request.

MIDAS can also be configured to allow individuals to update their information each time they make a web booking or request.

Multiple clients with the same email address

Shared Email Address

But what if there is more than one existing client with the same email address as the person making the web booking / request?

In these instances, MIDAS will not only compare the email address given, but also the client and organization names provided.

If there is a single exact match based on this additional information, MIDAS will associated the booking/request with the one matching client.

Again, MIDAS can be configured to update the existing client record at time of web booking / request with new details supplied by the individual.

The problem

There is however an “edge case” where the above options don’t quite go far enough.

Take for example an individual who uses their personal email address to make web bookings or requests for multiple different organizations they’re associated with.

That’s no problem if there are existing client records for the client for each of their organizations. But it becomes an issue if this is a brand new client. It’s also an issue if this is a person with just a single existing client record under one of their organizations.

Here’s an example to illustrate:

Let’s say Jeff is associated with two organizations – let’s call them “A” and “B”.

Let’s also assume that Jeff is a brand new client. There is therefore currently no client record with the same email address existing in your MIDAS system.

Jeff makes a booking request using his personal email address on behalf of organization “A”. A new client record is created for Jeff using this information.

A short while later, Jeff makes another booking request. He uses his personal email address again, but this time he’d like to make a request for organization “B”.

When Jeff makes his second request, MIDAS will see that there is already a single client in its database matching Jeff’s email address. One of two things will then happen, depending whether the “Allow client record updates” setting has been enabled in MIDAS.

If the “Allow client record updates” option is disabled, MIDAS will reuse Jeff’s original details (i.e. organization “A”). This will result in both his booking requests being for organization A.

If the “Allow client record updates” option is enabled, MIDAS will update Jeff’s original details (i.e. to become organization “B”). This will result in both his booking requests being for organization B.

…but that’s not what we want! We want his first request to be for organization A, and his second for organization B.

The solution

Instances of someone making web bookings / requests on behalf of multiple organizations using the same email address are uncommon. But we still wanted to better accommodate this scenario.

So for MIDAS v4.37 we’ve introduced a new “Account for multiple clients/organizations sharing the same email address” setting.

Account for multiple clients/organizations sharing the same email address
NEW: “Account for multiple clients/organizations sharing the same email address” setting

Enabling this setting will automatically create additional client records for each client/organization variant using the same email address.

The result – in our illustrative example above – would be that Jeff can make booking requests for either organization A or B (or even a future organization C) using his personal email address without issue.


Selectively process multiple booking requests

One of the helpful features of MIDAS is the ability to allow visitors to your website to check availability of your facilities and submit booking “requests” online. They can do this without logging in or requiring an account.

Once a booking request is submitted, the manager(s) of the request facility are notified. A manager can then then quickly approve or reject the booking request in MIDAS with just a few clicks.

In MIDAS v4.14 in December 2016 we introduced the option to allow a manager to “bulk” approve or reject all outstanding requests with just a single click.

Bulk processing of all booking requests was first introduced in MIDAS v4.14
Bulk processing of all booking requests was first introduced in MIDAS v4.14

This saved time in instances where there were numerous booking requests which all required approval or rejection.

To be able to bulk approve a number of booking requests, a setting was made available. This instructed MIDAS as to the order in which it should approve requests when approving them in bulk.

The “Bulk Approval Order” setting has the following options:

  • Earliest Requested First – Booking requests will be approved in the order in which they were received. The earliest request received will be approved first.
  • Latest Requested First – Booking requests will be approved in the reverse order in which they were received. The most recently received request will be approved first.
  • Earliest Commencing First – Booking requests will be approved in the order in which the requested booking would start. Requests for the soonest start times will be approved first.
  • Latest Commencing First – Booking requests will be approved in the reverse order in which the requested booking would start. Requests for the furthest away start times will be approved first.

For MIDAS v4.37 we’re giving managers even greater control when it comes to processing multiple booking requests.

In addition to be able to approve or reject one booking request at a time, or “bulk” approve/reject ALL requests at the same time, you can now also selectively approve/reject multiple requests.

On the Pending Booking Requests screen there’s now a checkbox alongside each request that’s awaiting processing.

Selectively process multiple booking requests in MIDAS v4.37
Selectively process multiple booking requests in MIDAS v4.37+

A manager can use these tick boxes to select multiple requests and then click the “Approve Selected” or “Reject Selected” buttons at the bottom of the screen to process the selected requests accordingly.

If no requests are selected, the “Approve Selected” and “Reject Selected” buttons change. They then become the familiar “Approve All” and “Reject All” options which if used process all requests in the queue.


Auto-Approve Booking Requests Based Upon Their Type

The “Booking Request” features of MIDAS, allow people to check venue availability and submit booking “request” for your rooms.

By default, all booking “requests” must then be approved by a venue’s administrator (manager) before becoming a “confirmed” booking.

Back in MIDAS v4.27, we introduced an option to allow booking requests received from certain email addresses/domains to be “Auto-Approved“.

“Auto-Approved” booking requests do not require a manager’s authorization. As soon as the request is received, it’s automatically approved by MIDAS – just as if the user had made a regular “confirmed” booking.

For v4.30 we’ve extended the “Auto-Approve” options for booking requests. You can now alternatively have requests automatically approved based upon the “type” of booking request that has been made.

Auto-Approve Booking Requests Based Upon Their Type
Auto-Approve Booking Requests Based Upon Their Type

With this option enabled, booking requests that have had a matching booking type selected at time of requesting will be automatically approved.

All other booking requests will still require a venue manager’s approved as before.

So for example, you could configure this option so that all “internal” booking requests are automatically approved, where as all others require approval.