Strap in, folks! We've got a lot to talk about this week! We put out several large updates over the past few weeks (first a set of 28 and then another 37). The big highlights are some long-awaited updates to door locks and the ability to show cleaning fees and other fee categories as columns on owner statements, but it goes way beyond that. We're going to cover it all in one giant write-up here, so - like I warned - strap in! ðŸ¤
New Features
The first thing we'll talk about is door locks! OwnerRez integrates with a variety of door locks and generates door codes automatically for bookings. However, we've been tracking some much-needed updates for awhile and we tackled a bunch of those updates over the past several weeks.
You can now define how a code is generated, when it should be generated and how it should be displayed to the guest. Along with this, you can now use the guest's phone number as the door code. Let's take a look at each of these things.
When you open your door lock settings in OwnerRez, you'll notice a new section called Code Generation with several options.
The top setting, in this new section, is called "Generate How" and it lets you pick four different options:
- Generated By Lock - this options means the lock maker (eg. Remote Lock or Igloo) will determine what the code is. In some cases this is required because the lock is algorithmic and codes are based on time. In other cases, the lock maker might have a formula you prefer to use on the door lock side.
- Guest's Phone Number - the door code will be set to the last few digits of the guest's phone number, and you can select how many digits you want to use from 4 to 10 digits. Some lock makers don't support this.
- Random Number - a random number will be generated by OwnerRez, from 4 to 10 digits, at the time the code is generated. You can also select to not repeat any digits if your lock hardware doesn't support using the same digit twice.
- Don't Generate - this is handy for users that want to set each code manually. No code is generated by OwnerRez at any time. It is up to you (the OwnerRez user) to enter a code on the booking.
The next setting is called "Generate When" and there are three options you can choose:
- At Time of Booking - the code will be assigned to the booking as soon as the booking is created. This is the default way OwnerRez works and the only option that used to exist before this update.
- Number of Days Before Arrival - exactly what it sounds like, OwnerRez will wait until a few days or weeks before the arrival date and then generate and set the code on the booking. This is helpful if your lock maker (eg. RemoteLock) limits the number of active codes you can create at any given time.
- Don't Generate - this is similar to the option above where you (the OwnerRez user) are expected to manually set a code.
In the bottom Options sections, there is a new setting called "Segment Length". This gives you the ability to display long door codes in human-readable chunks so that it is easier for guests (or housekeepers) to see the number when reading an email or SMS message. You can use a 3, 4 or 5 digit segment length. On the booking and in emails, OwnerRez will display the code in segments according to that length with hyphens between each segment.
If the code creates uneven segments, the last segment will be smaller to hold any dangling digits that didn't fit in the previous segment.
While working on these new door code options, we added a number of other door-code related feature requests.
For instance, we added an option to send the guest contact info (email, phone) to the door lock maker's website.
This means that when your door lock maker (eg. Remote Lock) shows the guest's name, stay dates and door code in their control panel, it will also show the guest's phone number and email address if you want to include that. We never sent that in the past for privacy and security reasons - we guard guest and user data as much as possible - but some users pointed out that they could do more with their door lock maker's reports and other features if we sent that contact info over. So there's now an option where you can do that. By default, the guest's contact info is not sent to the door lock maker, so you need to go turn that on if you want it included.
Need to use our Batch Update page to generate codes in bulk, but want to keep existing codes as they are? You can now do that. Our Batch Update screen for door locks now has an option to synchronize door codes with the lock maker but keep existing codes if the booking already has one. If the booking doesn't have one, a new code will be generated.
Why is this important? Say you already have a door lock in place with active bookings, but then your lock breaks or you want a different door lock. You buy the new lock and install it but the new lock has no codes programmed for all the upcoming future bookings. OwnerRez has codes for those bookings, but the new door lock (and lock maker's website) doesn't have those codes entered. Even worse, the guests were already emailed their codes, so you don't want to notify them all with a new code. This new option will allow you to retain the existing codes while updating the door lock (and lock maker's website) with the existing code.
Do you use Kaba as your door lock but have trouble with long stays (30+ nights)? We now support door codes for long stays with Kaba door locks. If you're curious, Kaba locks require that long-stay door codes start and end on specific alternating Mondays (yes, you read that right 😕) which took some mental maneuvering on our part, but it's all good now. There's nothing you need to do or change on your end. Long stays will now work cleanly where they didn't before.
If you've mapped multiple properties to the same door lock integration, you might have seen the property mapping list get rather dense. We've thinned it out by combining the door code properties into a short "X properties" link that you can hover over to see the full list. This is similar to what our grids and list show when an entity is mapped to several properties.
Okay, moving on from door locks! Let's talk PM and owner statements...
A few weeks ago, we added fee categories to surcharges so that you could exactly-categorize your cleaning, pet, resort, firewood, etc fee types beyond the general description. We have a lot of plans for fee categories, but one of those is the ability to bring that information into owner statements for our PMs. And we've just done that. You can now configure custom columns on owner statements that will show exact surcharge and tax amounts for that booking. And for tax amounts, you can select each type of tax. Like all custom columns, you can choose your own name and description to show to the owner.
Let's use Cleaning Fee as an example. In your custom view, add a column and scroll down the list to the bottom. You'll see a new set of columns called "Specific Surcharge" where you can select any of your surcharges.
These surcharges are exactly the same as the surcharges you've configured in your rates settings but only those surcharges with a mapped fee category are shown. And the fee category itself is shown, not the surcharge description. So if your surcharge is called "Housekeeping" but it's mapped to a Cleaning Fee category, this list of columns will show "Cleaning Fee". Same with pet, additional guests, and all the other types of fee categories.
Right under that, you'll notice a list of the taxes from your account. You can select taxes as custom columns as well, so that you owners can see a break-down of each type of tax in addition to the totals.
Once you've added a few surcharge and tax columns, go preview a quick owner statement and notice how it looks.
Those columns will show the exact amounts for your surcharge and taxes based on whatever the booking charges were at the time the statement was generated.
And speaking of that, what were the charges at the time the statement was generated? This is a constant question that leaves PMs puzzled (and our support engineers when asked) that requires a lot of digging around. You no longer need to guess! We now store a snapshot of the booking charges when owner statements are generated and you can pull them up, on each booking line item, on the statement. Open any owner statement, and look at the far right side of each booking. There is an Action button with a "View Charges Snapshot" option.
Click that option, and OwnerRez will open a window showing you a list of the charges, along with the commission and expense amounts, as of the time the statement was generated.
No matter how or when the booking changes, over time, this snapshot of charges will stay the same for each statement. If the booking is remitted on multiple statements, each statement will have its own snapshot of charges for that booking. This should help you more easily investigate why commission and earning numbers are the way they are on various statements even when the current charges look different.
Another exciting new feature we're happy to talk about is auto-created listing sites. For years, we've encouraged (harangued?) users to create custom listing sites and make sure quotes and bookings are tracked so that you know where each guest came from and see that in your reports. We do this automatically for big channel integrations like Vrbo and Airbnb, but it's important that your regional, local and direct bookings are tracked as well. If you have your own website, you should have a custom listing site configured in OwnerRez to track bookings from your website. The same is true from other sources. It recently occurred to us that we could do this automatically. When you use an OwnerRez widget (or website) to create quotes or bookings, our system can typically see things about the request that show what website the guest was on before they came to the OwnerRez quote. Because of that, we are able to automatically create a listing site for whatever website the guest was on and then use that new listing site on the quote or booking. If you already have that domain name in your listing sites, then we'll find and use that one instead. Otherwise, we'll create a new one. This might lead to you seeing a bunch of new listing sites popping up in your account, and we plan to add some merge and clean-up tools so that you can organize these listing sites better. But for now, enjoy the more-complete tracking of auto-created listing sites!
The last new feature I'll mention is the new field codes we added for contact and social media links. To help users create better cleaner email signatures (and other themes) we noticed that our field codes needed to be smarter about what they displayed when it comes to social media links and contact/profile information. You might have a Facebook link but no YouTube page, so showing a Facebook and YouTube icon won't work. You need field codes that display the ones you actually have and leave off the ones you don't, and they need to work for single and multi-line layouts.
These are the new field codes that were just added:
- {MYSOCS} - a single line version of all your social media links with a pipe ("|") between each social media link
- {MYSOCM} - the multi line version of all your social media links with a line break between each one
- {MYCONS} - your email and phone in the single line version using a pipe
- {MYCONM} - your email and phone in the multi line version using a line break
Again, these field codes only show the social media links, email address or phone number fields that actually have a value. So if you only have an email address, the phone number won't show. If you only have a Twitter link, the Facebook, YouTube and other links won't show. This allows for email signatures (and other theme areas like RA and guest form footers) to look like this:
And those email, phone, social media links in the email signature will stay up to date with whatever is in your OwnerRez account settings as they change over time. Remember that you can create multiple themes, mapped to different properties as well, and each theme will follow the same field code logic.
For more info on how field codes work in general, visit our support article about field codes or watch the field codes video.
Enhancements and Tweaks
Let's start off the enhancements section by talking channel integrations...
For Airbnb, we added new Wifi Network and Password fields so that you can neatly fill in the exact Wifi information and have that transmitted to Airbnb where the guest can find it in their Airbnb booking information and in the Airbnb app. You can find the new Wifi fields under the property Guest Instructions tab right above the Internet Info area.
Users used to use the Internet Info field to write out an explanation about the Wifi - and you can still do that - but the Wifi Network and Passwords fields now let you directly state what the network name and password. Again, if you have the Airbnb channel integration connected, via API, these Wifi fields will flow directly into Airbnb.
And what good would these fields be if you couldn't insert them into email templates? We took care of that too. There are now new field codes (called PWIFINAME and PWIFIPASS) that will insert the Wifi fields into your templates.
We made another update for Airbnb over in the guest conversation thread. When a "reservation request" occurs, we now show separate Accept and Deny buttons, mirroring Airbnb's language, so that it's clear what action you are intending to take. Instead of "Answer", you can now directly accept or deny the request. This is different, think "pre-approving" an inquiry or answering a message. The Accept and Deny buttons will only show if it's a special "reservation request". If you use Instant Book as your Airbnb booking mode, you may not see the Accept or Deny buttons at all.
Along with the new Accept/Deny buttons, we added a new system alert for Airbnb reservation requests so that you can see when there's an Airbnb quote that was created. Along time ago, we used to send a system alert for every new quote, but it was irritating and not very helpful, so we removed it. This change puts that alert back in place but only for Airbnb quotes and updates the format to our modern alert style.
We recently announced support for showing non-Vrbo reviews on Vrbo listings. After working with Vrbo directly over the past several weeks, we're happy to report that Vrbo has finished certifying OwnerRez to deliver third party reviews and has begun showing them live. However, we made some changes to our reviews feed (ie. the reviews we share with Vrbo) so that only guest-entered reviews will show up on Vrbo. This is in keeping with Vrbo's review policy. So to be clear, if you go record a manual review in OwnerRez, that review will not show up on the Vrbo side. If a guest uses the OwnerRez review form to submit a review, that review will show in Vrbo.
We also tightened up some restrictions on reviews so that guest-entered reviews cannot be edited after they are submitted by the guest, specifically the star rating, title or body of the review. You can edit other aspects of the review, and of course add an owner response, but the guest's original star rating, title and body are no longer editable by you (the OwnerRez user) after the fact.
Also for Vrbo, we tweaked the Vrbo Channel Tester to only allow future dates. The point of the Channel Tester tool is to simulate rates and rules for future dates and show you where your rates or rules are off. We noticed that when running on historical dates (ie. dates in the past) the results were a bit wonky and ambiguous. There is no reason to use any of the Channel Tester tools on historical dates, so we clarified and restricted the tool to require future dates only. Specifically, Vrbo requires the start date to be tomorrow or in the future. Other channels require today to be the start date.
We noticed that a lot of new users asked about the "global" rules that properties show in the Channel Rules tab. "Global" as in.... where? Over on the channel's control panel? To stop confusing everyone, we renamed "Global" to "Channel API" on the property channel rules. If you're wondering what Channel API means, go to the top Settings menu and look at the API Integrations.
Finally, we are now displaying the Account # on the channel integrations list for more channel types. FindRentals is an example of a channel that was not showing the Account # but now is.
That's it for channel updates. Moving on to some other great enhancements!
When recording a manual payment in OwnerRez, you can now select "Other" as the type of payment. These days, there are many ways to accept payment, and our list of payment types doesn't cover them all. "Other" will help you with those other types. At the same time, we added "Chargeback" as a type of refund. While credit card disputes are never pleasant to deal with, they do happen from time to time, and we wanted a way for users to be able to classify them and search for them later in reports.
Another little tweak we made to payments was with credit card numbers. We noticed that a lot of people like to copy/paste card numbers from emails or other screens. When copying, spaces or hyphens are often pasted in with the credit card number which in turn fouls up the credit card validation logic. The credit card form would tell the guest or user that the card number is wrong because of the extra spaces or hyphens. We updated our credit card validation to allow hyphens and spaces without erroring.
The "Info" tab on bookings has been there for a long time and we've wanted to update it for a long time. Recently, we realized that instead of updating it, we should just remove it. After all, the booking "info" is kind of the same as the property, dates and so on. If you're changing the guest party size or booking title, you might want to change the dates at the same time. Changing and moving the booking are basically the same thing, so we removed the Info tab and changed the "move" page to include more things. Move is now "Change / Move" and the page includes group/party size, title, booked on, cleaning date, currency, listing site and more.
Like before, the screen will detect if you change the property, dates or check-in/out times and present you with some email options. The email options are the same as before only they now have blue call-out formatting so that they are a bit more obvious.
Also like before, if the charges need to update as a result of your changes, a window will appear showing you the old and new charges and ask you to confirm if you want the old or new charges.
Please note that this is a transitional update. In the near future, the "Info" tab will disappear from the booking entirely (right now, it still shows but with a message pointing out where you should go) and the "Change / Move" buttons will simply become "Change". Baby steps!
From the beginning of time, our PNAME field code was designed to change dynamically and show the public property name, instead of the internal property name, so that the guest always saw the public version. However, there are numerous scenarios where you might need to use the actual property name in your messaging, not the public name. It created a problem because there are cases where you want the regular name and other times where the public name is better. Now, you can decide. We added a new field code called {PDISPNAME} that is the "display name" of the property. This new field code will work like the old PNAME one did, dynamically changing to show the public property name if one exists or falling back to the regular property name. The original PNAME field code will revert to only showing the property name. And if you want to always show the public name, whether it exists or not, we have a field code called PPUBNAME for that too. All existing message templates have been upgraded to use the name PDISPNAME. If you want to always use the regular internal name, switch those back to PNAME.
Back in February, our yuuuuge PM overhaul included the ability to have multiple owners for properties where you can establish a timeline for when a property changed hands or the commission settings changed. Since then, we've noticed a lot of confusion with the way users change, remove or set owners. Many users set a new owner on the property when they really just want to change the existing one or fix a mistake from before. However, we wanted to make sure that fixing a current owner configuration doesn't remove an old owner when the property is old. Switching owners should keep the old owner in place and start a new one relative to a starting date. So we went back to the drawing board and came up with a new user experience for switching owners while also creating the ability to fix old mistakes. When you go to change the owner configuration for a property, you now get a set of questions asking what you actually want to do. You can now configure that the property was sold (ie. switched owners), is changing commission with the same owner or that you messed up and need to fix the current owner. You have to select an option; there is no default one selected.
After selecting the option that you want, the edit screen will show you options specific to that option. For instance, if you are switching owners because the property sold, the edit screen will show you the current owner and ask what owner you want to switch the property to and on what date. You obviously cannot select the same owner, so the current owner isn't in the list of "new owners". The effective date has to be some time after the current owner started.
The other options work similarly and show their own edit screens. This should reduce a lot of confusion in changing owners while also leading users down a path of success.
The last big enhancement is kind of a nerdy one and might fall under the "dev ops" stuff we don't talk about publicly. However, we decided to mention it here because it might lead to some changes you see in the user interface. We've been cleaning up our dates and time zone logic to correctly respect the time zone of your user account and property (depending on the date in question and if the property has a different time zone than your account) in many places throughout the system. This is part of a culture and localization effort we are making to normalize and upgrade our language, date, currency and culture settings throughout the system. It's a long-term effort, but one step at a time. In this update, we changed our booking dates to store all dates in UTC (universal time zone) time and then display channel values in user time correctly. If you notice places where time is now showing correctly in your time zone, whatever time zone your account is set to, please let us know and we'll take a look.
And finally, the little tweaks...
Do you have multiple custom calendar exports (iCals) you share with other people or programs? Ever get confused about which one is which? You can now provide a name on each custom calendar export to help identify them to your team (or yourself).
Have you noticed our icons are a bit newer? We upgraded our FontAwesome support to 4.7. That's not the latest version, but hey - we're getting closer!
Ascent got a new logo and link, so as always we made sure OwnerRez was updated to show the latest greatest thing! Cleanliness is next to godliness.
Have you built an OAuth app for OwnerRez using our API? If so, you can now receive webhook notifications when a customer disconnects your OAuth app. This will allow you to clean up your user database and know when a mutual OwnerRez customer has stopped using your app from our side.
When a security deposit re-authorization fails, we say that on the booking Transactions tab. However, what we don't mention is that the security deposit will try to re-auth again, typically the next day, but it will only try again up to a certain point. We've updated our Transactions page to show that the security deposit will try to re-auth the next day, if it will, so that the message paints a complete picture.
Bug Fixes
Reduce errors from PointCentral door codes. We noticed some areas where we could reduce the error messages being returned by our PointCentral door lock integration, so we upgraded our code in a couple places and starting using their new API as well.
Don't auto-release security deposits on cancellation. Just like it sounds. In the past, we were automatically releasing the security deposit when the booking is cancelled, but there are situations where the booking is currently active (ie. the guest is there) when the cancellation occurs, so the security deposit might still need to be used. We stopped auto-releasing the security deposit so the booking will notify you of the security deposit after departure just like regular bookings.
Validation errors not being shown on New Card guest form. When we did the Stripe 3D Secure and Stripe Connect updates this past fall, we unified a bunch of code including our guest forms. The Request New Card guest form is different than the other guest forms because there's no separate confirm page, so the spinner fires inline. Now the Request New Card guest form will show validation again - both for raw cards and Stripe Connect ones.
CRM menu showing unread messages when there aren't any. This is now fixed. The CRM menu will only show an unread message counter if there really are unread messages.
Recommend the "ORUxxxx" address. We've been working for awhile to get rid of the per-property @inquriyspot.com email addresses, and our instructions now correctly point to the account-level email address only. This means the "ORPxxxx" email address per property is no longer recommended (or shown) in inquiry email instructions.
Allow disabling owners of disabled properties. We noticed a situation where owner records could not be disabled because they were associated with properties that were disabled. We don't allow owners to be disabled if they are associated with properties (you have to remove or change the owner configuration on that property first) but this caused a problem when properties were disabled because there was no way to clean up the owner configuration. We now allow you to disable owners of disabled properties.
BULEASESIGNF is sometimes blank. We found and fixed an issue where the BULEASESIGNF field code was not displaying correctly in some renter agreement signed trigger events.
Long numbers in property names. We attempt to sort property names logically, that is based on alphanumeric characters, but also include a check for numbers. Some users have long numbers in their property name, and that was causing our sorting to blow up on some screens. We fixed this.
Filtering bookings timing out. We found and fixed an issue where searching for bookings based on "sent [x] email template" was taking a long time and timing out.
SMS templates and images. We noticed an issue where sending images wouldn't work if you selected an SMS template on the guest conversation thread. The SMS body (ie. text) would go out but the image would be dropped. This is now fixed.
Door codes based on phone numbers when there is no phone number. Right after we released our new door codes features (see above) where you can generate codes based on the guest's phone number, we noticed that this would create error alerts on bookings where there wasn't a phone number. Nothing bad happened - there was no code generated - but it was pesky to get an alert when it's obvious that a door code can't be generated. We stopped sending the "could not generate code" alert email when there is no phone number.
Segmented door codes with irregular segments. Right after we released our new door code features (see above) where you can split up a door code based on a certain number of digits, we noticed that the last segment (ie. chunk) of digits would often not be the same number as the previous segments. We didn't want the last segment to be small and create dangling digits, but after conferring with users, we realized this was better than having a fat segment at the end, so we updated our code to create a final segment even if it leaves danglers at the end. In other words, if you have a segment size of 3 digits and a 10-digit door code, you would have seen "123-456-7890" before. Now, it will display as "123-456-789-0". The dangling 0 at the end is better than having a fat final segment with extra digits.
Listing site might exist by name. Right after we released our new auto-create listing site feature (see above) we noticed that some users have listing sites where the name is a domain name. Then the auto-create would kick in, because of a widget firing off a quote or booking, and the system would get a "name is already in use" because the domain name already exists. We now updated the existing listing site instead of erroring when quoting through a widget if domain name is missing.
Links in hosted website properties overlapping other page parts. We found and fixed an issue where links in the property description on property pages on our hosted websites would overlap with other links around them. The overlap area was invisible, so no text or images were being blocked, but when you went to click on the link in the property description, it could not be clicked. All good now!
Clarify the First Payment option for Booking.com. Previously, "First Payment" was a checkbox field on the Booking.com channel integration settings. That was a bit confusing, so we converted that to a set of options called "use the first penalty date from the cancellation policy" and "collect first payment upon booking".
Over-syncing QuickBooks payments and invoices. This is a long-standing issue that some QuickBooks users will recognize. When the financial info on a booking is changed - any financial info including charges, payments, refunds, fees, expenses - we nudge the booking to be synced with QuickBooks again. However, we were "over-syncing" the information when the invoice and payment data often wasn't different. Our QuickBooks syncing engine would attempt to delete or re-update the same invoice and payments again even when the invoice or old payments were changed. Because of this, the QuickBooks sync engines would frequently return errors from QuickBooks that the invoice or payment could not be changed or other errors about payments already being deposited. We updated our QuickBooks syncing engine to check the invoice and old payments, to see if anything is actually different, before attempting to remove or re-update those entities.
SDRELAMT is an amount, not a date. The SDRELAMT field code is supposed to render out the "security deposit release amount" which is just what it sounds - a currency amount. We were using a date format instead, so it would sometimes show "MMM d, yyyy" instead of the currency amount. This is now fixed.
More accurately match listing sites on widget inquiries and quotes. We've cleaned up our matching logic for inquiries and quotes coming from widgets. If the referring site matches more than one of your Listing Sites, we will now use the most specific match. This was recently affecting inquiries that were from .com.au domains but not matching correctly to listing sites.
Allow adding a booking on the last day of the month on ribbon calendar. If a booking departs on the last day of the month, you should be able to select that day to add a new booking... You can now. Fixed Ribbon view quick create link on last day of month
Why the red menu? The "Mountain Lodging" website template had some default style formatting in place that automatically made the last menu red. No matter what the last menu was, the font would be red. This was based on something we copied when creating the Mountain Lodging template originally, but it really doesn't make sense and caused a lot of questions. We updated the template so that the last menu font is no longer red.
Spacing in property type descriptions. Is your "Suitein a bungalowon the first floor"? That really should read "Suite in a bungalow on the first floor." Now it does.
"Botique" is not Boutique. How long was this misspelled? Nobody knows. On the property Amenities page, this type of Hotel is now spelled correctly.
Support BDOORCODELIST in Airbnb and SMS templates. Though they work the same way, Airbnb and SMS templates are different than email templates. Airbnb and SMS templates are plain text only, but they do support field codes. The problem is that some fields codes render rich text by their nature. For instance, they might render a table of charges or a bullet list of activity. Rich text isn't possible in plain-text templates (like Airbnb and SMS) so what does one do? In some cases, we simply don't support that particular field code. If you use it, a blank spot will appear in the Airbnb or SMS template where the field code was. However, we noticed that BDOORCODELIST rendered a simple list of codes, so we updated our field codes so that this one can be used in Airbnb and SMS templates. To show it as as set of bullets, we use an asterisk (*) and a new line for each door code that is displayed.
But don't support BDOORCODETABLE. At the same time, we realized that the table version of the door codes list was not possible to render in plain-text templates, so we updated the field code editor to no longer allow it to be selected when editing Airbnb and SMS templates.
Copy forward the criteria too. We recently added the ability to "Copy Forward" seasons so that you can move the current range of seasons to next year (or the year after) and move the associated surcharges and rates along with them. Only we forgot to move all the criteria, so we just fixed that.
General expenses may not be hidden from the owner. This was more of a mis-feature than a bug. Basically, it was possible to have prededucted expenses that weren't associated to any booking, so they were never actually prededucted and the owner was never charged for them. We allowed this for some time, but it caused more problems than it solved, so we've gone ahead and removed the ability to prededuct (ie. select "Do not show on owner statements") for property or owner expenses. The option is still there for booking-related expenses.
Better instructions for FloridaRentals inquiry emails. We recently changed some of our channel integrations to parse inquiry email in a cleaner better way. In tandem with this, we made it so that inquiry emails for an account only need to be sent to the one account-level "ORUxxx" formatted email address and not the property-level "ORPxxx" email address. This has been the case for several months, but we just noticed that our instructions for FloridaRentals still referenced the old format. We have corrected this.
Switching guests on Airbnb bookings. We turned off the ability to change contacts (ie. do the "Associate To New Guest" button) on bookings if the booking is an Airbnb API booking. While technically possible, switching guests on an API booking is problematic when it comes to down-stream functionality, so it is no longer possible.
Don't send reminders for pending bookings or if payment/secdep is scheduled. We noticed two scenarios where payment and security deposit reminders were going out when they shouldn't: pending bookings and bookings where a scheduled payment or security deposit failed. In the second case, the user would get both the fail email and the reminder if both fall on the reminder day. We now filter out pending bookings and send reminder emails before processing scheduled payments and security deposits so that the schedules ones will stop the reminder from going out. The failure notice will still be sent if the payment or security deposit fails to process.
Stop Air triggers on non-Air bookings. OwnerRez tracks guests across multiple bookings and sometimes there are guests that are "Airbnb guests" (ie. tied to an Airbnb thread via API) but also have non-Airbnb/direct bookings. When this happens, we noticed that OwnerRez was allowing Airbnb channel triggers to be sent even when you're communicating with the guest about a non-Airbnb/direct booking. This means that the new message would go back to the guest via an old Airbnb conversation, which is... weird. We now block Airbnb channel triggers from being used for non-Airbnb bookings even if the guest has an Airbnb message thread or previous Airbnb booking.
Handle negative charges after cancel. We noticed a scenario where Airbnb bookings were being cancelled and, because of a resolution adjustment, were creating an overall negative balance. Now, before saving, we check to see if the total charges will be negative. If they are, we wiped out all charges, not just the channel managed ones.
Track owner correctly on property-level expenses. Previously, property expenses (ie. expenses linked to a property and not a specific booking) only cared about the current owner of the property, not the historical owner of the property at the time the expense occurred. This meant that an expense could be recorded, the property sold (ie. switched to a different owner) and then the new owner would be charged for the expense depending on the date of the expense and when the new owner took over. We fixed this so that property-level expenses now track the correct owner relative to the date of when each owner owned the property.
New Videos
This week, we have a couple of new videos about payment processing. If you recall, our last videos were about the payment process overall and taking credit cards, so we decided to follow those up with some additional payment videos. This week, we added videos about getting paid by PayPal and checks. Take a look:
