Airbnb’s Grace Period Security Issues

There were 2 features which managed to stir up resentment amongst Airbnb hosts over the past year. The first of these was the split payment policy which Airbnb made a big fuss over when they introduced. It was short-lived however with the policy going into the toilet and being terminated mid September. I wrote a separate article about this which you can read here.

The second introduction which also went down like a lead balloon was the mandatory introduction of a 48 hour grace period for guests to cancel bookings on the platform. This went down so well that there were thousands of comments on Airbnb’s forums with furious hosts quitting / threatening to quit the platform. The initial rollout of the feature was also delayed by months. Now however it has been live for a few months, I thought I’d go into details of our experiences of being forced to use it.

For a bit of background, I run Roomfilla, we manage bookings for a plethora of clients and have hosted over 20,000 guests through the Airbnb platform. We run all of our properties on the Strict cancelation policy on Airbnb. Since the introduction of the grace period, our cancelations on Airbnb have risen to approximately 20% of total bookings.

The Issues with the Grace Period

You are probably guessing that I will touch on security due to the piece title and that is correct. There are two main issues with security which result from this cancelation policy and I will outline these below. The other issue is the added inconvenience that belies to hosts who deal with multiple properties. New processes have to be set up to ensure that these confirmed bookings which are later canceled are logged correctly in systems so that availability remains true amongst all the platforms that property managers operate.

Location & Contact Details Revealed

After someone has booked your property, they get the details of the location and your contact details. If they then cancel within the grace period, they have lost no money and get these details for free. This is a serious flaw and a great way for a company looking to sell you something to get your data for free. There is no obvious way for a host to stop this happening and it does happen.

On the location page hidden at the bottom is this to tick. If you tick this then it does shield your personal data. The issue is Airbnb does not provide an option to turn this on account wide. If you have an account with multiple listings, there is no way to shield yourself unless you go through each individual listing, tick the box and then hit save. This is not good enough and Airbnb should protect their user’s data a lot better. It is sheer bad design / purposeful for them to not enable such an option.

You can see that these are the only bulk edit options regarding the location settings. There is no real reason for Airbnb to not make this a bulk edit option and I would ask that they seriously consider doing it. Every host that I speak to who uses the strict policy which is most, is unhappy with these settings. Adding a work category and a family category which forces hosts to put a less secure cancelation policy if they want to be part of these categories, simply papers over the cracks and is another area which Airbnb shows complete disregard to their host community.

Automated Messages Send on Confirmation

With all the PMS systems that now exist and the vast amount of tools which cater towards hosts, a lot of the messaging is set up to be automated. This might be a newsflash to some but anybody who is making serious money in the sharing economy is using such systems to automate their workload. The outward marketing of companies such as Airbnb shows a different picture of course, a perfect ideal of an individual host who will meet you, take you to the pub and share their city with you. This does happen of course but is less common than they’d like you to think.

Setting up automated messages for your Airbnb property is not difficult. There are some inexpensive options and it is even possible to set such up without a PMS entirely. These rules tend to follow certain patterns. Common patterns is to have an answering message within an hour of a guest inquiry. This helps to keep your response rate high. A message on a confirmation is also common as is a message a week before the check in date to send the final check in instructions.

The grace period creates a security risk to the message sent on confirmation. Most hosts will often provide some details here and if someone is simply fishing for information, they can get this free of charge by simply booking and then canceling 2 minutes later. A host may have a deal with a transfer service offering discount codes, private information and more. With the grace period now being a mainstay and despite 71 pages of messages on the initial announcement – https://community.withairbnb.com/t5/Airbnb-Updates/New-strict-cancellation-policy-update/td-p/652735/page/71 it would appear Airbnb won’t be changing their minds.

It simply creates a worse environment for everyone. Hosts will be hesitant to provide information to guests once they book until 48 hours later and guests will be wondering why the host isn’t sending them any information. What Natasha has said above is true and it does create the argument for fixing all these automations to not trigger until 48 hours after a confirmation.

Why such an unpopular policy has been forced upon the host community is unclear but it just pushes more property owners and managers to consider other platforms and take them more seriously. The host community are important to Airbnb. It is a shame they seem to think that this is not the case on some of their latest policy changes and why ultimately, I can see another platform taking considerable market share from them / a new platform rising up in the future.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>