We’ve been busy developing a major new update to our scheduling software, MIDAS.
This update packed full of new and improved features, many of which have originated from ideas and suggestions from our existing users.
An often requested feature is to have the ability to “route” booking requests to different users, depending upon the venue being requested.
Currently, all booking requests received by your MIDAS system go into a central “pool”. From this pool, any user with the “Can Process Web Requests” permission can view, approve, query, modify, reject, or lock the requests.
In MIDAS v4 however, Booking Requests can be routed to different users based upon the venue that’s been requested!
You can essentially configure which requests go to which administrators. In an educational setting this would, for example, allow sports staff to manage requests for your sporting facilities. At the same time, office staff could separately manage incoming requests for your meeting rooms.
How it works…
In MIDAS v4, you’ll find a new “Managers” tab on the “Manage Venues” screen.
From this tab, you can assign one or more existing users to “manage” booking requests for the selected venue:
Then, when a member of the public then makes a booking request for that venue, “managers” of that venue are sent an automated email notification by MIDAS. This informs them that a new pending booking request requires attention. These email notifications may be turned on/off at any time through the manager’s “Pending Booking Requests” screen.
The manager can then log in to MIDAS and go to their Pending Booking Requests screen. From here, they’ll see outstanding requests for all the venues they manage. Booking requests can be approved with a click of the mouse.
The Booking Request screen also offers additional functions. Requests can be modified – for instance, they can be moved to a different time, date, venue, etc. Requests can also be rejected, queried with the original requester, or locked. Locking a request prevents any other manager from processing the booking request whilst you’re dealing with it. For example, you may need to query something with the client before approving their request and don’t want another user approving their request in the interim.