No Show rates for the hospitality industry are typically between 8% and 15% for hotels, therefore it's obvious that No Shows can significantely impact a property manager's profit margins and productivity.

In the event of a No Show, the hotel or apartment probably already has No Show policies in place, however preventing a problem is always better than curing (or mitigating) the pain afterwards, so what can you do?

 

Up until recently, I haven't seen much point in implementing No Show handling in Jomres because of where Jomres sits in it's market place. It's priced and geared towards single property sites, or small groups of properties. Sure, it can (and does) handle thousands but in general most of our client's sites have properties in the tens, rather than the hundreds or thousands. As a result a property is only really likely to see a guest once or twice, therefore the manager was unlikely to be able to tell if the guest was a No Show risk until the damage was done.

If you have been keeping up to date with Jomres News you will have seen that I have started implementing the Jomres Syndicate Network (JSN). This is just the beginning of a plan where individual Jomres based sites can work together to harness their collective power and make decisions based on information shared across all sites. Going through a few older feature requests I came across a request for No Show handling and realised that the JSN was the perfect way of enabling Jomres sites to work together when assessing No Show risks.

In 9.21.0 I will be introducing a new feature where property managers can see No Show risks for a guest in the Reservation Details page.

Guest No Show data plus guest profile tab

In this screenshot you can see a new panel called the "JSN Statistics for this user", plus the Guest's profile section that is new in the Guest tab  of the reservation details.

These statistics are generated at booking time (in this screenshot No Shows outnumber Bookings due to testing new functionality). When a booking is made the guest's email address is sent to the JSN, where that address is one-way encrypted (it's not actually stored on the server, just used to create the record, so no GDPR Personally Identifyable Information is saved) and the booking count increased. If the booking is later marked as No Show then the number of No Shows will be incremented on the JSN and other Jomres users will see that updated information any time somebody makes a booking on their sites with that email address. I did toy with the idea of storing more information such as numbers of cancellations versus bookings completed (checked out) but in my experience a lot of my Jomres user's don't even use the book-in book-out functionality so those numbers wouldn't be very representative.

This means that a property manager/host can view the reservation and make a judgement call on whether or not they think that the guest is likely to be a risk and enact any policies, such as over-booking, to minimise the risk. The system itself doesn't attempt to advise of what steps to make, every property is different and I'll leave it up to you  to decide what you should do, but the numbers will help you in your decision making process.

Unlike much of the JSN functionality, which is free, this particular feature requires that the Jomres installation requesting the Booking and No Show numbers be a licensed installation. This is because there's the risk that Bad People could try to use the REST API as a way to validate email addresses as current, so pulling booking/no show numbers from the JSN has to be limited to licensed sites, however any Jomres site can increment those numbers and internally mark a booking as No Show.

Here's the link to the manual page. If you'd like to get involved with testing this new functionality, it's already available on the Nightly branch so you can go ahead and test to your heart's content. Use the fictional email address This email address is being protected from spambots. You need JavaScript enabled to view it. for a guest if you want to see already existing information.