Hi everyone! We've got a YUUUGE one this week. We released so much, it took two release days that cover a total of 39 updates, headlined by some major PM and owner updates. Let's get to it! 🚀
New Features
Over the past 6 months, we've frequently mentioned that our PM area is getting a lot of attention. While we continue to work on other things - messaging, channels, websites - the PM area has a number of fundamental changes coming that will increase your ability to manage bookings and manage owners while simplifying the statement generation and reporting process. Some of these changes will add new functionality, and others will simplify what was already there.
The first major thing we did was to fundamentally change how owners, and their commission settings, are configured against properties. Instead of setting a single owner and commission amount, you can now change owners and commission amounts over time while maintaining the historical timeline. For example, when a property is sold to a new owner, you can now set a new Effective Date for when the new owner takes over while leaving the current owner in place. When the effective date arrives, the new owner's settings will take over for bookings that are arrive from that moment forward. The same is true when changing the current owner's commission amount. If the current owner is staying the same but you're charging a higher commission (yay!) you can put in an Effective Date for when the new commission takes effect.
Owner configuration was moved to the property itself, so you'll notice a PM Settings tab on each property with the owner configuration inside it. Head over there to take a look. You'll see the owner along with their current settings. Click the Change button to make a change with an upcoming Effective Date.
Let's assume that today is January 1st. In the above example, we're saying that as of the upcoming date of March 1st, the owner is switching to "Cardigan Capital" and the commission to 20%. The current owner is not being changed and will remain in the system for all time relative to the time that owner owned the property. After saving, we see the current owner with how it will change in the near future.
As time moves along and the effective date passes, the same page will show the new owner as the current owner and the previous owner will show as in the past. Any series of changes will be shown in the Ownership Changes table below the current owner.
Spin through your properties and make sure the owners and commission amounts are correct for your properties going back in time. If you once removed an owner, because the property was sold to someone else, you can now safely put back that original owner and note when the new owner took ownership. Please note that ownership configuration changes have to be made in order, so if you're putting back a previous owner, you must first delete the current owner, correct the owner before that and then put back the new owner.
While we were changing this area, we added another super cool feature. When you change your owner configuration, OwnerRez will now instantly evaluate all your existing bookings and recommend immediate changes based on what you changed. If the owner is changing in a few months, shouldn't the bookings that arrive after that point also be changed so that they belong to the new owner? If you're increasing or decreasing commission, shouldn't bookings reflect that as well? Now we show those recommendations inline and give you buttons where you can immediately take action.
In the above example, we see a common scenario where the property has changed owners effective as of some date in the future. At the time the change is saved, OwnerRez instantly looked at all bookings within the affected date range and shows bookings that appear to be wrong. Since the owner is changing to Cardigan on February 1, these bookings (shown above) that still belong to the previous owner JSK Properties should probably change to Cardigan since these bookings arrive after February 1. OwnerRez won't change them without your confirmation, but you can now see the recommendations right away and change them in a single click. The same is true if you changed commission amounts or some other setting.
In case you were wondering, the Configuration page under the PM menu still exists, but we changed it to be informational only. You cannot change owners, or owners' settings, from this area, but you can see all the properties side by side and see their owners. You can also see future updates.
In the above example, we see that Bear Timbers is getting an owner (ie. going from un-managed to managed) on March 1, and Expedia Property is changing commission amounts. Clicking the green property link on the Configuration page will take you to the property's owner configuration area where you can see and make changes.
Now let's talk about statements! We spent many weeks debating internally how to stop a number of common statement generation problems. One of the big problems we faced was the issue of old/historical bookings coming up on new statements when you first go to generate owner statements. If you've spent any time generating statements with our PM module, you probably know what I mean. Another problem was the issue of overlapping bookings where the PM expects bookings that overlap two months to be picked up but pro-rated and then picked up again the next month.
In the past, to give PMs a quick way of cutting up months, we had a "between...and" selector that would let you select the start and end date of a month (or any other date range) which would then only include bookings in that range. Over time, we realized that the "between...and" selector was insidious and caused more problems than it fixed. Not only did this not address proration accurately, but it dropped bookings that should have been picked up in multiple statements. To create a path of success, we made the decision to remove the "between...and" selector from statement generation completely. In its place, we streamlined the other options, which highlight the real world scenarios PMs face, and we added a Batch Update tool that will allow PMs to bulk un-manage (ie. turn off) old bookings that keep appearing. We'll talk about the Batch Update tool in a minute, but first let's look at the new streamlined generation options.
When generating statements, you can now select one of four criteria options for including bookings shown below:
- Include bookings that arrive before the statement date and pro-rate amount if departure is after statement date
- Include bookings that arrive before the statement date and give full amount
- Include bookings that depart before the statement date
- Include all bookings, even if they're in the future
The first two options are similar in that they pick up any booking with an arrival that occurs prior to the statement date. The only difference is that if a booking overlaps and has a departure after the statement date, the first option will pro-rate the owner's amount while the second option will still remit the full owner amount.
The third option is similar but it looks strictly at the departure date only. So if a booking arrived prior to the statement date but departed after, that entire booking will be ignored until the following statement.
The last option will include all bookings regardless of date. If you're wondering why this is an option, there are some PMs and owners that have an arrangement to remit all booking money, even for future bookings a year out, because the owner does not want that money sitting with the PM for long periods of time. Perhaps, the owner has 10 or 15 properties under management and is worried about a large amount of money held in trust. If those future booking are cancelled, the cancelled one is taken back in future statements since the booking would have zero owner money but was already remitted. OwnerRez keeps track of how much was remitted to an owner versus what should be remitted and can correct both up and down.
The most common option is the first one, and if you're not sure what to use, we recommend that you use the first option. To be clear, only bookings with an owner balance are picked up by statements and only if the booking meets a number of other checks. If you're wondering why bookings aren't showing on a statement, take a look at our help article on why bookings aren't showing on a statement.
If you're wondering how to "cut off previous bookings" because old bookings are showing up on a new statement, that should be handled by setting those old bookings to "un-managed". Up above, I mentioned how setting the owner's effective date on each property will automatically show you old bookings to be turned off, but there is now a way you can batch update many bookings at once to be un-managed. To do that, take a look at the Batch Update Bookings for Commission area under the PM menu. This tool already existed, but we expanded it so that you could select what you want to do - manage, un-manage or recalculate - to the group of bookings you're targeting.
If old bookings shouldn't be included in owner statements, use this tool to select those properties, set a starting date in the "On or before" option and then run the update to un-manage those bookings. OwnerRez will find those bookings and turn them off. Then, go back and generate a new owner statement, and those bookings will no longer appear. Be careful when selecting dates and properties to target the correct bookings. If you make a mistake, no worries - you can use this same tool to find and "set managed" the bookings that were accidentally turned off.
While we were in here, we tweaked some other statement-related things.
As mentioned in our help article about why bookings aren't included in statements, we look at payment data on each booking to determine if a booking has been paid by the guest and, if so, how much. This is important because OwnerRez does not want to remit money to an owner if you (the PM) have not actually received the money from the guest. There are a number of situations where this can occur. So each booking is checked to make sure that payments have been entered, with past dates, for each booking that is picked up.
Over time, we noticed an interesting pattern... PMs often generate statements at the beginning of the month for the previous month. For example, the PM might be generating statements on February 4th for all of January so the statement date is January 31. As explained, the statement generation engine looks at payment dates to see what payment have come in by the statement date (which in this example is January 31) but often there are payments that came in for bookings at the beginning of the month. In this same example, let's suppose a booking arrived on January 28 but the payment was recorded on February 2. Since it's now February 4 the payment has actually come in and the PM has the money in hand. But the statement engine was only looking at the statement date of January 31 so the booking was excluded. This caused quite a bit of irritation. To help with this, we've tweaked the statement logic to check the generation date when looking at payments and include any bookings with payments that occurred before the generation date instead of the statement date.
Another highly requested feature we added is a new PM report called Owner Statement Bookings Remittance that shows the booking detail from your statements across any date range. This allows you to look at (or export to Excel) all the details of your owner statements across any property, owner or date range, and you can use our standard reporting tools to group by owner, property or date. Think of this like opening individual owner statements and exporting the guts to Excel, but instead of opening them one by one, you can now use a report interface to query it all in one go.
Here's an example of where we queried several owners across several months and exported it to Excel. The highlighted cells show the difference between the owners, properties and statement dates with all the booking data to the right of that. This is an extremely important report because it gives you (the PM) the ability to see individual or multiple owners and properties together with all the booking data next to it. You can use this to provide End of Year reports to your owners or do in-depth analysis.
We noticed, while designing out the PM roadmap, that owner records needed more tracking fields, and then we noticed the same with contacts (ie. guests). The ultimate goal is for all major business objects in the system (bookings, inquiries, guests, quotes, properties, and so on) to have the same type of tags, notes, attachments and custom fields available through a common menu element. While we work towards that goal, we decided to go ahead and add a bunch of these things to owners and guests.
We added tags, notes and custom fields to owners, and we redesigned the owner pages to have tabs so that they can be viewed and managed separately. Navigating to an owner, now shows an overview of the owner's contact info, preferences, tags, notes and custom fields.
Notice at the top we also show where this owner is used throughout the system and what other features this owner is associated with such as a portal access login. This is similar to what we started doing with email templates and it's a pattern we like and are expanding to other features.
Clicking the top Change button takes you to the tabbed view where you can make changes.
All three of these things - tags, notes and custom fields - work the same way for owners as they do for properties, quotes or bookings. You can see tags on the grid of owners and filter by tag. You can define custom fields at the owner level and then fill different field values for each other. For instance, you may want to denote which owners get statements on certain days of the month or which owners you send a Christmas card to. You can use tags to denote those things. Suppose you need to email the owners' statements to special email addresses different than the normal one on file, or to multiple email addresses. You can do that by setting up a custom field for owners called "Statement Email Addresses" and then set what it should be on each owner and then use that custom field in your statement email template as the TO field.
We then did the same for contacts (ie. guests). Contacts already had tags, but we went ahead and added notes and custom fields to contacts as well. Like owners, the Note field on contact can take up to 10,000 characters and is shown in the list if a note exists. You can also filter for notes as well - did I mention that? So if you forgot which owner or contact you wrote a note on, try filtering the list for only those owners or contacts with notes.
Custom field on contacts work the same as everywhere else, so we won't waste time digging through that. Click into any contact and you'll figure it out from there.
While we were doing all this work on custom fields for owners and contacts, we realized that a bunch of system field codes would be better organized by moving them to the owner and contact level. For instance, instead of specifying the "booking guest email" as a field code, you should specify the "guest email" itself since every booking is already associated with a guest. We made numerous changes to field codes moving all the booking guest field codes to guest and all the statement field codes to owners. Take a look at our master support article about Field Codes to see the latest list. You'll notice new field code sections for Owner field codes and Contact field codes. "Contact" is now what we call guests. The field codes in those Owner and Contact sections aren't new. Most of them used to be in other sections and were moved to their own section. For instance, {ONAME} became {ONAME} and {CFIRST} became {CFIRST} and so on.
A couple points of clarity...
If you're wondering where certain field codes went, when looking at the "Insert Field" window, check the other tabs along the top. For instance, if you don't know why the Bookings list of field codes no longer show guest related fields, look in the Contacts tab. The Owner tab likewise.
If you're worried about your existing templates, and the field codes that you used in the past, don't be. We swapped out all the field codes in your existing templates, so they should continue working without a hitch.
We also spent some time on our search results page. You can now search notes on guests as well as on bookings and quotes, and the search page will show the guest and its contact info and notes above any associated bookings, quotes or payments.
Nothing was removed from the search page, just a bunch of cool new stuff was added!
The last new feature to mention (whew! 🤕) is that you can remove or disable owners from the PM area. Make a mistake in your data entry or no longer need to manage an owner's property? You can turn the owner off for good. Simply navigate to the Owner grid and select the owner(s) to disable, or drill into the owner and use the "Disable" button there. The owner and their associated history will still remain in the system but you won't be bothered by that owner's name in drop-down lists, reports and so on.
Enhancements and Tweaks
While moving PM stuff around, we cleaned up the PM menu. All the reports that used to show in the PM menu are still there, same as ever, but they no longer clutter up the sidebar menu. You get one "Reports" tab and that takes you to the real Reports menu where the PM reports are located.
Tags have been well-received by users because of their power and versatility, but we noticed that they were a little confusing on triggers. What does "everything but" mean when selecting tags or "only" for that matter? Does the booking need to only have the selected tags and no others, or are the tags the only ones examined? We changed tags on triggers into two separate lists labeled "Has Tags" and "Doesn't Have Tags".
This makes it much clearer what will happen when the trigger runs, and this allows you to target bookings with good and bad tags at the same time. For instance, you might want to send a post-departure marketing email to all bookings that have the tag "large group" but not if they also have the "bad guest" tag. You can now do that!
Last week, we mentioned that Airbnb Infants are now shown on bookings, only they were showing a little too much. They were showing up on Party Size and other areas, causing confusion. Is an infant a "guest" in the sense that it's a human being like everyone else? Well... not really because the guest count doesn't include Infants in Airbnb land. To reduce confusion, we stopped showing the infant count in party size or guest labels and only show Airbnb Infants on the booking itself if it's an Airbnb booking.
From the beginning of time, we've never sent "new inquiry" alerts if the inquiry comes from Airbnb via an API connection. This is because Airbnb already alerts you when someone sends a message. However, some users have shown us scenarios where getting the OwnerRez alert will be beneficial, so we now have an option in the Airbnb API settings to turn on the "new inquiry" alert if you want to get it.
The inquiry/booking widget has gotten smarter too. We now block selection of unavailable dates on the inquiry/booking widget to make it harder for guests to screw up when putting in their arrival and departure dates. Before, the unavailable dates were colored as unavailable but still select-able. We also changed the date selectors to stop navigating to previous months.. When it comes to dates you can't book, don't look and don't touch!
Another great enhancement is the new rate setting that lets you specify, globally, if your night rules should be based on arrival day or all the days of the booking. To find this, go to Settings > Rates and click the top Settings button.
You'll see a new Evaluate Rules field with those options. This matters because users often want to align their rates and rules with what channels (eg. Vrbo) do. OwnerRez is inherently a lot more flexible and versatile than the channels - our rate and rules options are ten times more powerful than anything the channels support. This sometimes creates problems because what guests see in one place will be different than somewhere else. if you want OwnerRez to continue evaluating rules based on all nights of the booking when the guest books direct, leave the option as "All Nights Of Stay". If you'd rather simplify your rules so that guests have the same experience everywhere, go ahead and choose the "Arrival Night Only".
In recent times, we've added the ability to view and edit cards on file, and we've continued expanding that feature. We've just released some updates to work with non-verified cards so that pending bookings can "try again" using a failed or unverified card without bothering the guest or needing a brand new card entered. Failed or unverified cards are still stored and still usable. Likewise, the system will now allow you to schedule a future payment or security hold using a failed or unverified card so that it can try the card and, if it still fails, email the guest again. Bottom line - we no longer assume a failed or unverified card can't be used for future things.
Bug Fixes
I answered it! Our new "Create And Send Quote" button is a big hit, but it wasn't actually marking the original inquiry as answered, so we fixed that. Now the button will quickly take you through creating the quote, sending it and answering the inquiry all in one step!
Renter agreement signing. We found an issue where renter agreements were being signed by the guest, and on-signed triggers were firing, but the PDF wasn't fully archived yet. The guest would get the trigger email, but the PDF link didn't exist yet, so part of the email was empty. All fixed now!
Card on file with booking created triggers. We fixed a timing issue where bookings would store cards on file but the on-create triggers would not run correctly.
Deleted tagged entities. A lot of things can be tagged nowadays, but what happens when something is tagged and then that same thing is deleted? The Tag Usage grid was crashing because it was still trying to find the tagged item. This has been fixed. And hey, if you don't know what the Tag Usage grid is, check it out over here. It shows all the items in the system that are associated with any set of tags, no matter what type of item it is. Pretty sweet.
Card editing redirect. We fixed an issue where cards on file were redirecting improperly and showing the wrong validation after being edited.
Missing Stripe fee. As of right now, Stripe is the only gateway that returns fee data to OwnerRez automatically with every transaction, and our Stripe users really like that. A recent update introduced a bug where multiple failed Stripe transactions would create a scenario where the next successful transaction was not returning fee data. This has been fixed.
Long phone numbers and QuickBooks. We fixed a bug where really big phone numbers were crashing when the booking synced across to QuickBooks. Evidently, Intuit has a problem with phone numbers that are typed as "I'm at (912) 555-1212 and my hubbie is 202-444-526 but use ext. 47" 😂
Unicode names and QuickBooks. Apparently, this is the week that QuickBooks wanted to get finicky. It also choked on names that have tildes and other unicode characters outside of the basic alphabetical one the western world is used to. Fixed!
Numbers should be numbers in Excel. Excel will show values as numbers even when those values are not stored as numbers, but it gets irritated and tells you to change them and it won't allow you to do number stuff like sum, count or average. We fixed this so that our export is outputting real Excel-approved numbers.
Slow reviews and thumbnails? Never! In case you've been living under a rock, we here at OwnerRez care a lot of about speed. We measure everything and are constantly improving our features and pages to be fast and efficient. We recently got a whiff of some slow reviews and property thumbnails and did a bunch of work to make them fast again.
HomeToGo is a channel too. Our Channel Rate Tester tool lets you pick an API channel to test rates for, but HomeToGo wasn't an option in the list of channels. We fixed that.
Optional surcharge seasons. In recent weeks, we changed our season calculations on surcharges to more-accurately reflect what surcharges or discounts should apply to a booking where it overlapped multiple season. Our optional surcharges (ie. the add-ons selected by guests during quote acceptance) got no such love unfortunately. We fixed them so that they follow the same season calculations.
SMS forever. We fixed an issue where an SMS message was triggering to multiple phone numbers but, because one of the numbers was failing, the entire loop was running again.
PM Lock blocking security holds. We noticed that bookings with PM Lock turned on were not allowing security holds to be scheduled or reserved. All better now!
New Videos
This week, our latest videos are about payment processing. First, we released a high-level overview of what's available for payments in general, and then we added a video about credit card processing. We have upcoming videos, actively being worked on, that are about checks, PayPal, security holds and pending confirmation. When you get a second, take a look at the first two:
