One of the great 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 a person to update their information each time they make a web booking or request, if you so desire.
Multiple clients with the same email address
But what if there is more than one existing client in the database 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, or a client 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. At this point one of two things will happen, based on 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 different organizations but 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.
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 request for either organization A or B (or even a future organization C) using his personal email address without issue.