Posts Tagged: public booking requests

Showing availability and taking bookings from your own website

One question we’re often asked is some variation of “how can people see our availability, or book with us, directly from our own website?” It’s a great question, and MIDAS gives you a few different ways to do exactly that. In this post we’ll walk through the options and help you pick the right one.

There are three features to know about. Two of them, Public Booking Requests and Public Web Bookings, are included as standard in every MIDAS system. The third, Web Calendars, is an optional add-on. They solve different problems, and they also work nicely together.

At a glance

FeatureWhat it doesIncluded or add-on?Best for
Web CalendarsEmbeds a calendar of your bookings into your own website, so visitors can see what’s on.Optional add-onDisplaying your schedule or availability on your site.
Public Booking RequestsLets visitors check availability and submit a booking request, which you approve before it becomes confirmed.Included as standardTaking enquiries you want to review before confirming.
Public Web BookingsLets visitors make and pay for a confirmed booking directly, with no approval step.Included as standardInstant, self-service bookings with online payment.

If you just want people to see what’s on

Sometimes you don’t need visitors to book anything online at all. You simply want to show them what’s already happening, or whether a particular space is free, right there on your own website. That’s what the Web Calendars add-on is for.

Web Calendars generates a tidy daily or monthly calendar of your bookings that you can embed directly into a page on your website using an IFRAME, or simply link to. You control exactly which venues and booking types appear, and how much detail is shown. With a little custom styling, you can even reduce a calendar down to a simple “available or booked” display for a particular room.

Web Calendars is our most popular add-on, but it is an optional paid extra rather than a standard feature. You can add it to your system at any time via mid.as/upgrade, or include it from the outset when you first purchase.

If you want people to request a booking

If you’d like visitors to be able to ask to book a space, but you want the final say before anything is confirmed, use Public Booking Requests. This feature lets non-users check your availability and submit a booking request, which lands in your system awaiting approval. A request only becomes a confirmed booking once a venue manager approves it.

This is ideal when you need to vet bookings, for example to check details, confirm payment separately, or simply make sure the request is appropriate before it goes in the diary. You can also restrict requests to particular email domains, and even set certain request types to be approved automatically.

If you want people to book and pay instantly

If you’d rather let visitors book a space there and then, with no approval step, use Public Web Bookings. This works much like Public Booking Requests, but instead of creating a request, it creates a confirmed booking straight away, including an online payment step so the visitor pays at the point of booking.

To accept payments for Public Web Bookings, you’ll first need to enable Stripe or PayPal in your system.

Both Public Booking Requests and Public Web Bookings are disabled by default, and need to be switched on by an administrator via MIDAS Admin Options → Public before they can be used.

The best of both: display and book together

Here’s where it all comes together. Web Calendars isn’t only for display. You can configure a calendar so that when a visitor clicks a date, they’re taken straight to your Public Booking Request or Public Web Booking screen, with that date already selected for them.

That means you can show an attractive calendar of what’s on directly on your own website, and let visitors click through to request or book an available slot in a couple of taps. It’s a great way to combine a polished public-facing display with the booking features already built into your MIDAS system.

Which should you choose?

  • Want to show your schedule or availability on your website? Use Web Calendars.
  • Want visitors to request a booking that you approve? Use Public Booking Requests.
  • Want visitors to book and pay instantly? Use Public Web Bookings.
  • Want to display and let them book in one journey? Use Web Calendars linked to either of the public booking features.

Whichever route suits you, you can find full setup details in our help documentation for Public Booking Requests, Public Web Bookings, and the Web Calendars add-on. If you’re not sure which is the best fit for your organization, just get in touch and we’ll be happy to point you in the right direction.


More control over “Public” venues

MIDAS allows organisations to control how members of the public can view room availability, submit booking requests, or make direct bookings for specific venue.

They can do this without signing in or requiring a user account. These are known as the “Public” features of MIDAS.

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.

Greater control over public venue access

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-facing Web Bookings and public-facing Booking Requests – if both features were enabled.

For MIDAS v4.41, we’ve made an improvement. You can now make each venue available for…

  • Public “Booking”
  • Public “Requesting”
  • Both Public Booking and Public Requesting
  • No Public Booking or Public Requesting
Improved Public Venue Control in MIDAS v4.41
Improved Public Venue Control in MIDAS v4.41

This small but significant improvement will now allow 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.

This added flexibility makes it easier to balance accessibility with control – especially for venues that require approval before confirming bookings.


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.