Hi everyone! This week, we put out a large 50-update release with several new features (webhooks, enhanced DP, yay! 🎉) and a lot of tweaks and bug fixes. Our previous release was almost a month ago, so we had quite a few items roll up into this one. Let's get started!
New Features
Webhooks
Have you created an app for OwnerRez or used our API to automate your data? If so, you'll be excited to learn that we now send webhooks for apps!
To get started with webhooks, open your app in the Developer/API area and scroll to the bottom. There was already a Webhooks section there before, but it was only used for disconnection notices in the past.
Now, you'll see a new "Types" drop-down with Booking and Guest as options.
If you select those types, OwnerRez will begin pushing updates to your app automatically any time a booking or guest is created, changed, or deleted. It doesn't matter how the booking or guest is created in OwnerRez - from a channel, from a third-party app, direct booking, manually in the control panel - we'll notify you and provide you the details in real-time of all changes
For those of you with apps, this is really big news! It means that you no longer need to periodically check OwnerRez throughout the day for updates to your (or your customer's) bookings. We'll notify you instead. This cuts down on the amount of communication going on and gives you near real-time updates of all changes.
To see the data format and read the details about how webhooks are sent, and the format they are sent in, take a look at our new Webhooks Overview support article. Notice that we sent a small payload with just the entity type and ID of what was changed like this:
{
"id": 12345
"user_id": 12345,
"action": "entity_update",
"entity_type": "booking",
"entity_id": 12345
}If you're wondering why we don't send the entire booking or guest object, in its entirety in the payload, that's on purpose. We intentionally designed our payloads to be small to minimize security vulnerabilities and maximize performance. This means that you will need to make additional API calls to load all the details about an event. You should use the entity_type and entity_id to distinguish which API calls are needed.
You should create a table to store all webhooks that come to your app and then process them after the fact. Please read the Webhooks support article in its entirety to understand all aspects of the format as well as how to debug the process and other best practices.
Last thing I'll mention on Webhooks... We added a cool new "test" function so that you can make sure your webhook URL is working. Back in the app area, notice the Webhooks tab at the bottom of your app. There's now a new "Send Test Webhook" button.
Anytime you click that button, we'll send an immediate test to your webhook URL, and, just like the other type of webhooks, you'll see the test event show up on the list of webhook events. Click the Data button on the far right of the event, and a window open to show the details of what was sent.
The same window shows all webhook details, so this is a good place to hang out when you're testing your booking and guest webhooks.
Enhanced Damage Protection
For a while, we've been in talks with RentalGuardian, our primary insurance partner, about providing additional Damage Protection levels to our users. Not to put the cart before the horse, but eventually, it's our goal to offer guests their own protection options while booking (ie. where the guest can buy their own damage protection) but also add higher levels of protection for the current owner-covered policies that we provide now.
Two issues are commonly raised about the standard Damage Protection we've always offered - host liability and bedbugs. Neither of those is covered by the standard coverage, but both come up as common things that PMs want to be included. So we put our heads together with RentalGuardian and solved the problem. We're happy to announce that you can now turn on "Enhanced" levels of Damage Protection for your properties that include both host liability and bedbug protection.
The homeowner liability protection is $1,000,000 of coverage that protects the homeowner against bodily injury lawsuits for injuries that occur during the rental stay and damage to adjacent property and tenant property within adjacent units.
The bed bug protection covers losses relating to extermination, replacement of ruined soft furnishings, limited loss of income during remediation, and alternative accommodation expenses for relocating affected guests.
You can add Enhanced coverage or switch from Standard to Enhanced at any time directly in the app. Go to Settings > Damage Protection > click Change and select what you want for each property.
As with all insurance, there are limits and deductibles involved. Please read the following policy documents to get a sense of the details. For comparison's sake, I've posted both the Standard and Enhanced versions. The Enhanced version includes everything in the Standard version, so take a minute a brush up on all of it.
OwnerRez Standard Damage Protection.pdf
OwnerRez Enhanced Damage Protection.pdf
Now for the big question - what's the cost? The Enhanced version costs $10 more per booking for all 4 levels of coverage (500, 1500, 3000, 5000) than the Standard version. You can see a full breakdown of pricing on the Damage Protection Overview support article and on our Costs & Fees doc.
Suppressed (ie. Blocked) Email Addresses
Here at OwnerRez, our systems send millions of emails per month, and most of those messages are booking related. In other words, we send those messages on your behalf to your guests, owners, housekeepers, and other recipients that are part of your business operations.
Occasionally, email messages will "bounce" because the recipient's email address is not entered correctly (ie. there's a typo in the email address) or the email address was turned off. We carefully monitor all email messages to record any bounce notifications that occur. We show bounce feedback to the user in the Communication History (under the Tools menu) and we send an alert to the user every time a bounce occurs.
However, it's not enough to merely watch and record bounces. To maintain a high rate of deliverability and protect our users' reputation, it's important to proactively stop bounces from occurring by not repeating them to the same recipient over and over. Email providers like Gmail and Yahoo are careful to notice when senders generate a lot of consecutive bounces, so it hurts our sending reputation (which in turn hurts our users' reputations) if bounces aren't proactively stopped, where possible.
To manage this, we created a "Suppressed" Email Address feature so that our system is not generating many bounce notifications over and over again to the same recipient. "Suppressed" means blocked, so in layman's terms, we are blocking email addresses and creating a list of them to remember who bounced recently and block them from getting more email.
At the same time, we created a process so that you can see your list of Suppressed Email Addresses and also reactivate any email addresses that you want to send messages to. That second part is really important. Sometimes, email providers make mistakes or email addresses are only temporarily down. Just because an email address bounced today does not mean it will bounce tomorrow. Our system will show you the blocked addresses and let you quickly reactivate any that should be tried again.
To see it in action, go to Settings > Suppressed Email Addresses. You'll see any recently-bounced email addresses and the current status.
If the status is Suppressed you can click the Reactivate button to turn it back on. If reactivating the address fails, as is sometimes the case for spam complaints, you will need to contact support to get the address reactivated.
You'll also notice language about "Suppressed Email" showing up in other places throughout the app.
For instance, when an email message bounces, OwnerRez already sends you a system alert. But now, if the email address was suppressed, the system alert will include that information:
You can also see that the address was suppressed on the communication history:
If your own email address - the one you use to login to OwnerRez - bounces, it too will land on the Suppressed Email Address list. If that happens, we'll show an app-wide global alert that one of your own account emails is suppressed until you fix the problem. To fix it, you can either reactivate the email address or change the email address in your account (profile or theme pages) to something different. Third-Party Alerts are also considered account emails, so if any of those bounce, the global alert will show for those too. You'll need to find the property with the bouncing Third Party Alert and remove it.
For more info, check out our new Suppressed Email Address support article.
Enhancements & Tweaks
New design for Inquiry area
In keeping with our ongoing effort to clean up old pages and get everything moved to the newer mobile-friendly design, we did a bunch of work on the Inquiry pages. All inquiry-related pages have been moved to the new mobile-friendly design. As you click through the inquiry, verifying the message or sending a reply, you'll notice a fresher look and it will be easier to use from your phone or tablet.
Probably the best example of this is the Verify tab on the inquiry. The Verify area shows a split screen with the original email we got on the left and the parsed inquiry data on the right.
The design is similar to before but has a fresh look and collapses well on mobile and tablets. As you move through the Inquiry pages, you'll notice the same updated design and mobile ability.
Airbnb channel updates
Our commitment to being the best channel manager in the industry means our engineering team is constantly talking with the channels (Airbnb, Vrbo, Booking.com) and putting out updates and tweaks for the new stuff the channels put out. Nearly every release, there is something we're doing that is channel-related because the feature area is so large and involves so many moving parts. In this release, we tweaked two things for Airbnb.
First, we implemented a new "enhanced availability" response when communicating with the Airbnb systems. This basically means that instead of telling them "no" when their system asks us about available dates, we are now providing them a full availability response so that they also update their calendar and rules at the same time. This was a new option that Airbnb's API team released recently, and we jumped on it immediately. While this may not sound like much, it means that Airbnb will stop asking our system for requests when dates fail as often.
It was already very rare for our system to tell Airbnb "no" for dates because our system already pushes availability to them in near real-time. But sometimes when a booking or block occurs, their system hasn't quite updated fast enough or the various queues are still running. In those situations, the "no" responses that we send will not contain other information so that they don't continue to ask us for booking checks as the guest clicks the quote forms on Airbnb's side.
Second, we now set Airbnb taxable categories based on the surcharges we are syncing with Airbnb. Again, this might sound confusing or trivial, but it's an important little tweak for maintaining a high degree of accuracy with their systems.
No more triggers beyond 30 days
We recently reached out directly and emailed the users that were affected by this, so this is something you may already know about: Triggers will no longer fire messages for bookings after 30 days past the booking's departure date. In other words, if the guest departed 30 days ago or more, the booking triggers will no longer send messages for that booking. You can still send manual messages to the guest, of course, but the automated triggers won't fire for that booking.
For a long time, we've watched as users have created far-future triggers as a marketing tool to remind guests about past stays and push them to book again. That's a great idea and we commend the marketing acumen!
However, this is not what the trigger feature was designed for, and there are technical reasons we need to limit them. It also hurts your deliverability and brand over time to send unsolicited marketing emails without unsubscribe links included in the message.
We are planning to release some email blast tools in the future and create unsubscribe lists to better help you automate your marketing. However, those tools aren't out yet. In the meantime, you should use a third-party tool like MailChimp to import your contact list and send email blasts.
There is a report in OwnerRez called "Email List" that is designed to work with email apps like MailChimp. The report contains special columns for when the guest last booked or inquired so that you can write messages reminding them of that when you reach out. You can also query and export other lists such as the Booking list view or CRM > Contacts list.
We understand that this might be frustrating, but please know that the change had to be made for technical reasons because these far-future triggers are not sustainable by nature, and they have led to negative results with our messaging speed and deliverability.
More display settings for Statement Views
For our PM users, custom Statement Views have been a big hit. For those that don't know, Statement Views allow you to customize the booking and expense data you show to your owners on your monthly statements. As users have begun using them more and more, the requests for additional options have come pouring in. We took some time over the past couple of weeks to add some of those new options as part of a new Layout section on Statement views. Here's a quick image of the changes:
First, you can now turn off the Notes and Total sections entirely. Don't like how those look? Turn them off! Want them called something other than "Notes" and "Totals"? You can set that too.
Then, we moved the "Group By Property" option into the view so that you can store this with the view instead of configuring it on each owner. It's really more of a display setting, so the view should dictate that if you're using a view at all.
While we were at it, we also added a few more booking columns up above in the column selector.
You can now select:
- Guest First Name, Last Name, and Full Name (separately). Some PMs don't like showing the full name to the owner.
- Listing Site (ie. Channel). This will show the owner "Airbnb" versus "Vrbo" and so on which can help explain why some bookings have certain fees others don't.
- Guest Count. This can help explain why bookings were higher or lower for a certain date range.
Improvements to the Custom Fields Import via Excel
It had been a while since the Custom Field Import had gotten any attention, and it was getting a bit stale. We did some work to catch it up and add some additional settings.
First, we added the ability to import Owner and Contact type custom fields. Those custom fields types were added to the app a long time ago, but the Excel import never supported them. That is now updated.
Then, we updated the Custom Field Excel template spreadsheet to use a hard-coded drop-down list showing the types that can be selected in the RecordType column.
This makes it clearer what is supported and validates against bad data entry.
Finally, we added a new Custom Fields Export function, so that you can quickly dump out all your custom field data, make changes and then import it all back in. You can find the new Custom Fields Export page in the global Import/Export area (under Tools).
Select the type of custom fields you want to export, and mash the button. That's it!
New Contact Us page and ticket form
Have you sent us a ticket in the last few days? We get a lot of them, so you probably have!
We overhauled our Contact Us page and created a new ticket form to help you contact us faster. We also got rid of the corporate address and "office hours" nonsense and showed who we really are - a remote company spread out everywhere.
It was time for a nice overhaul, and it feels really good to get rid of that old page. "Office hours"... Why did we ever post that? We're not a dentist office. Hopefully, no one actually tried to drive to Seattle to knock on our door. 😀
To be clear, we do receive mail at the corporate Seattle address, but it's merely a mail receiving address and not where any of our team members actually work. No point in even showing it. If you do need to mail us something, feel free to send a ticket, and we'll point you in the right direction.
UI cleanup for Tabs, SMS Numbers, and Booking Alerts
Recently, we moved notes to the overview page on bookings and quotes, and the Notes tab no longer had a purpose. We left it there so that when clicked on, users would get a message telling them where it moved to. Likewise, the Info and Date tabs were also transitioned to other places, but the tabs were left behind with messages. Since it's been a few months, we felt it was time to remove the Notes, Info, and Dates tabs from bookings and quotes, so we have now done that.
In case you hadn't noticed, we like to send a lot of alerts around here. In fact, we tell you pretty much everything all the time. For instance, when channels or iCals report new bookings but run into conflicts, we fire off alerts that tell you about the conflicts. However, we noticed that some of those conflict alerts could be a little more helpful so we added more information. Specifically, we added the booking number and dates to the booking conflict alert so that you can instantly see what bookings or blocks were overlapping the one new one.
When you go to claim an SMS Number, the window just sits there for a second, communicating with our SMS carrier. You don't really know what's going on and might mash the button again. While noticing that, we also noticed some annoying Log buttons sitting on the SMS Numbers list that seemed kind of out of place. Then we noticed that our carrier was mentioned by name in the "edit" link on the SMS list. Then we noticed that the "Forwarding To" column was empty when no forwarding option was configured which is kind of confusing. Sigh... So many things. This past week, we took a few minutes and cleaned up the SMS settings area. It needed love, and now we can stop noticing things. Win, win!
SMS pricing change (again)
Last month, we announced that our SMS pricing was changing because of some analysis we did throughout the year. After doing more analysis, we decided that the pricing change (targeting segments instead of messages, but leaving it at 200 included with 3¢ (0.03) per segment) would be too costly for many users. Even normal senders typically use several segments per message. It is still necessary for us to target segments, because of the large differences in sending patterns between users, but we've changed the pricing. The new pricing will include 500 segments and be 1.5¢ (0.015) per extra segment. We feel that this is a reasonable price that will correctly handle both normal and large-sending patterns.
If you haven't seen it yet, take a look at the special SMS Segment Calculator that we mentioned in our last release. We tweaked a little bit more this time around and added a way you can link back to the SMS calculator after doing your analysis.
Bug Fixes
Stripe fees for security deposits. We have always detected and recorded a Host Fee on bookings for any payment processed via credit card for those users who use Stripe to do their credit card processing. Only we recently noticed that security deposits aren't doing that even those generate payment as well if they are "refundable" type security deposits. So we took care of that. Security deposits processed via Stripe will now record a Host Fee on the booking just like any normal payment.
Improve Cancel Booking screen. We recently released a giant overhaul of the Cancel Booking screen that shows you your cancellation policy, adjusts the booking charges, and sends a refund all in one go. As is our custom, we sometimes move quickly and break things! 🏋 We noticed a number of tweaks (okay "fixes") we needed to make to smoothen out the process, so we got to work and straightened that stuff out.
Gracefully tip-toe around Airbnb room issues. Airbnb doesn't support removing accessibility from a room. When you do that, it causes problems, so we made some adjustments on our end to gracefully handle the process. When you update a room, we re-sync everything. We also sync the photos again. And if we sync photos that are linked to a room that has a problem, we ignore it, assuming that the room hasn't been created yet.
Edit blog posts. Would you like to change your blog posts after writing them? We noticed that some of the buttons weren't working correctly on the blog editor, so we fixed them. If you don't know what I mean by blog, we recently released a really nice blog option for our hosted websites, so check that out.
Be helpful when importing Reviews! Need to import some reviews from Channel Bridge? Previously, if you didn't have your channel mappings configured, it would fail while saying "Couldn't find the property." We figured we could be smarter about this and offer you the chance to map those property IDs inline so you can proceed immediately, just like the other Channel Bridge import does. We also allow you to skip properties if the import contains extra reviews for listings that aren't in OwnerRez.
Prefer first payment override on Booking.com if there's only one payment. We noticed that if both the first and final payment overrides are set, in the Booking.com channel setting area, the final one is used because it's applied last. But that's confusing. So instead, we now only apply the first payment only if there's one payment.
Prefer active properties when merging. We noticed that, when merging channel bookings into OwnerRez, if there are multiple bookings matching by booking number, there is sometimes a strange scenario if you merge the booking in and associate with a disabled property. So instead, we now detect if there are multiple matching booking #'s and take the active property first (if any).
What other property URL is there? The Availability/Property Search widget has a "URL Generation" option with a drop-down and most of the time the top "Property URL" option is what users select. In fact, it's the only thing you can select if you aren't using our hosted website feature. This is confusing - why show the URL Generation drop-down if there aren't multiple options to select. We fixed this to hide the field if a hosted website isn't being used.
Reduce flat tax to the amount of Airbnb tax. It's possible for Airbnb to report less tax than they should when new Airbnb bookings come in. Before, we were just calculating a flat tax, but we decided that we needed to follow the Airbnb tax numbers even if they're wrong. Otherwise, it's confusing to both the user and our team members. We fixed this to reduce the total booking amount if we calculate more flat tax than what Airbnb actually reported as tax. And if the amount is a percent, we check to make sure that the "last tax" in the last doesn't run out when reducing it.
On statements that can't be deleted, still show the button. Across the app, our UI pattern when it comes to "things you can't do" is to show the button or function but make it disabled with a message when you hover the mouse over it. We do this so that it isn't confusing why a button or feature is gone when you get to a page, and so that you know instantly why it isn't possible. We noticed that this wasn't happening on statements, so we put the button back but disabled it and added a message.
Statements unpaid vs. partially paid. While we were fixing the statement button, we also noticed that the statements list sometimes showed a different status than the statement itself. Previously, the statement list showed either Paid or Unpaid, but it's possible for a statement to also be "Partially Paid". We updated the list to show Partially Paid and we added a filter for that as well.
Add phone number validation in the quote acceptance process. When guests are doing direct bookings on OwnerRez (eg. via widget, website, or quote) there are several places they can enter their phone number. When the process gets to the end, and the guest clicks the "Confirm Booking" button, our system validates that the phone number looks valid by checking that digits (0-9) were entered. However, we realized we could do this earlier in the process. Instead of forcing the guest to go back and correct a phone number, several steps back in the booking process, we now validate the phone numbers on the page at the time the guest types in the number.
Always show "Move" button even if the booking is channel-linked. Like the man said.
Allow HTML in notes again. While the "Notes" field on bookings and quotes only allows plain text, there's no reason to blow up and show nasty crash messages if rich text (ie. HTML) is entered, right? We fixed this to be like before. Rich text won't render in notes, but it won't crash if you enter it either.
Default to canceled by guest. When canceling a Vrbo booking, you are asked who canceled the booking - the PM (you) or the guest. Vrbo uses this information to determine if a PM is canceling bookings too often. Frequent cancellations by PMs isn't cool because it hurts Vrbo's reputation as a lodging marketplace. However, often the cancellation is initiated by the guest and we realized that there are times when the user might not realize what is being asked and cancel without making the appropriate selection. We now default the cancel option to "guest" and let the user change it back if desired.
Display CC errors when confirming. Previously, when the "confirm booking" screen would run a credit card, if it ran into errors, it would silently fizzle and move right on by. We now stop and show those errors to the user before continuing the confirmation.
Crash on API listing 'since' query. If you use our API, you might run queries where you're looking for property changes "since" a certain date. We found and fixed a bug where this would sometimes crash.
Percent of Rent on discounts and surcharges. A while back, we added the ability to target "Percent of Rent" for the amount on surcharges and discounts. However, the discount or surcharge must be applied "automatically" for the Percent of Rent option to be used. Using codes or optional ones won't work. This has always been the case, but we weren't clear about it and we still showed it in some confusing situations. We fixed this to completely disable the Percent of Rent option (with a message) if you configure a surcharge or discount in a way where the amount cannot be applied against the rent only.
"Consider canceling instead" link broken. Did you know you can delete bookings? Yep, that's right. As long as the booking is pretty empty and doesn't have a lot of payment or channel activity, you can completely delete the booking from our system. When doing that, we show a warning that you might want to consider canceling instead, only the link we provided was broken. What good is that? All good now.
Association button on new photos. Recently, we added the ability to associate photos with rooms and amenities. There's a little button on photos that allows this (ie. the one that looks like a price tag). We noticed that when uploading a fresh new photo, however, the association button wasn't working. All good now.
Trigger update when changing Airbnb guest vs adult rule. Just like it sounds. When changing adult and guest rules on a property, it can make a difference in your Airbnb fee settings because extra guest fees are linked to those rules. We weren't triggering an immediate rate update to Airbnb when some of these rules changed, but that's now fixed.
Default commission when adding charge. We tend to move fast and break stuff around here, and that happened with the charges grid. The charge grid was overhauled a few months back to have a newer design and be more mobile-friendly, but in the process, we didn't realize that charges weren't having the default PM's commission rate set correctly. So if the property was configured to have a 20% commission, that would work everywhere except if you entered a charge manually. Entering charge line items manually is pretty rare, but it does happen. This bug is now fixed.
Charge import should respect surcharge commission options. Speaking of charges and commission, here's another one... Our Excel Import for Charges was ignoring the commission settings on the surcharge when importing charge line items that matched to that surcharge. This has been fixed.
Double clicks identifier mappings. We noticed a situation where users might accidentally click twice on the save button after entering a bunch of Identifier Mappings for channels. When that happened, we were saving duplicate mappings which caused confusion downstream. We fixed this to lock the channel property/listing for updates while setting the mappings so that it could not be set twice at the same time.
"Cancel Booking" alerts defaults. In the previous release, we noticed a bunch of places where alert settings were not being honored by the app when you go to process something manually, and we fixed that. But recently, we noticed two issues on the Cancel Booking screen. The "open in editor" or "send immediately" wasn't following the pattern that we use elsewhere (of defaulting to "open in editor"), and the alert itself wasn't honoring the global preference. Both of those issues have now been fixed.
Booking.com virtual cards with no expiration date. Booking.com sometimes processes payments from guests using a "virtual card number" system where a temporary card number is created with a date and dollar amount that can only be used once. The guest's real card number is not known or passed to the PM or our system. We support these virtual cards when we detect them, but we recently noticed that they don't have expiration dates similar to real credit cards. Because of that, we had to fix the process to look for an "activation" date instead.
$0 bookings on statements causing problems. In the previous release, we started including $0 bookings on owner statements. We noticed that Direct Remittance and Guest Paid amounts could cause certain bookings to appear as $0 bookings incorrectly, so we made some corrections.
I live in Europe, what the heck is a "dollar"? The OwnerRez team is mostly American, so we sometimes forget that "money" is not defined as "dollars". Believe it or not, we actually have customers in more than 190 countries though 90% of them are in the US or Canada. We found a place where we were saying "dollars" in a blue call-out bar, so we removed it.
Use previous tax applicability for Vrbo taxes if it hasn't changed. We noticed a rare (but possible) scenario where we could send a later tax applicability date to Vrbo even if a previous date would have been applicable. Basically, if there are multiple applicable tax periods, we needed to join together ones with the same applicability so that we don't lose a date range when we trim the previous ranges. Sound confusing? 🤔 Yeah me too. But the engineers said that they fixed it and all is well, so whew -- I feel better!