Happy Thursday, folks! 👋 Over the past couple of weeks, the blog has been silent about updates, but behind the scenes the updates have been pouring out at our normal ridiculous rate. We've got 59 updates to discuss, so no time to waste!
New Features
For years, OwnerRez has had the industry's most powerful calendar import/export (iCal) engine. Thousands of homeowners and PMs use our iCal engine to connect with channels, VR apps, third party contacts and calendar systems. Our iCal engine is known for its robustness and ability to handle many different edge cases, correcting common channel problems. The rise of API integrations has made iCal less necessary, but there are still important business needs that iCal can take care of better than anything else.
Over the years, many OwnerRez users have asked us to change how our iCal works so that they can share different types of information. For instance, there is a common request to make the guest's phone number or email address be the first line of the description or summary on the iCal event, which is used by a third party app to send an SMS alert or change a door code. Or you might want the guest's contact info limited to certain fields depending on who you're giving the iCal link to. You might want your housekeeper to see the guest's phone number but not their email address in the housekeeper's calendar system.
In typical OwnerRez fashion, we wanted to support all these scenarios and any others you might dream up, so we overhauled our iCal exports completely. We are proud to announce that you can now completely customize the content of your iCal exports in OwnerRez. To see the new changes, drill into any property and click the Calendars tab on the sidebar, then click the Calendar Exports tab. Like before, you can create as many Custom iCal Links as you want so that you're able to control what information each third party gets individually. Either click into an existing Custom iCal Link or create a new one.
You'll notice that the options are now different. You can embed the property name and location in the iCal event directly, which will make it a clickable address in your calendar system. Below that, the Summary and Description now allows you to fine-tune what is displayed based on a new array of options including new options for notes and custom fields.
If you select the "I'll define using field codes" mode, the screen will show you a set of text boxes so that you can completely control the content.
To get started, click the "Prefill" button that appears at the top. This will automatically generate some text with field codes to show you how the summary and description might be laid out.
From there, you can add your own text, move stuff around or insert other field codes. You have complete control to do what you want.
Wondering how your changes will look? We've got you covered on that too. Click the "Preview" button at the top, and we'll show you how your iCal content will look using real bookings.
The Summary and Description fields are a standard part of iCal and what other calendar systems (like Google Calendar or Outlook) show in the title and body of their calendar events. What you customize here is what will show on that side.
Here's a quick example of a custom Summary with field codes and how it appears when I import it into Google Calendar:
Remember that iCal tends to be cached by third parties which means it's slow to update, so if you make changes to your content, make sure the other calendar system really updated before wondering what's wrong. In some calendars, like Google Calendar, it can take a long time (even days) before the iCal content is refreshed. It is often better to simply delete the old link and make a new one.
Another awesome thing we just released is our new Verified Email Domains feature.
Most OwnerRez homeowners and PMs already use a custom domain name for their email address. As an example, let's use a cabin owner named "Mike" who runs Mountain Cabins Inc. You probably already know that Mike should use an email address like "mike@mountaincabins.com" instead of something like "mikemtcabins@gmail.com". Not only does the former look more professional, but it also advertises Mike's website and helps Mike build his brand. The problem is that in order for OwnerRez to send email on behalf of Mike, the mountaincabins.com domain name has to officially tell the world "I give permission for OwnerRez to send email using me as the domain name". In modern times, email service providers (like Gmail or Yahoo) check DNS records on the domain name of the email address to see which domain names have allowed which apps to send on their behalf. This separates scammers from legit apps. So to make sure that our emails are delivered with a high rate of fidelity, and to maintain your sending reputation, we diligently require you to add those DNS records.
In the past, we manually did this for users by letting you add a single "Verified Sender Address" to your account after going through a manual mapping process with our email provider and your domain registrar. Many of you know what I mean because you already did this by going back and forth with our help desk. But doing things manually sucks and we wanted users to have more versatility, so we created a fully automated end-to-end process where you can verify as many domain names as you want (directly yourself) and send emails from any of them at any time.
To see the changes, go to Settings > Verified Email Domains and click in. If you already had a verified email address in the past, we've migrated that to the new system for you, and you'll see your domain name in the list.
Click into your existing domain name to drill in. You'll see a bunch of technical mumbo-jumbo.
This mumbo-jumbo is the aforementioned DNS records that have to be maintained on your domain name so that the world knows OwnerRez is a legit sender for you. If you remember back to when you did the manual mapping with our help desk, these were the DNS records we had you put in place. You'll also notice that there is a Status field with Verified or Not Verified showing. You want both Status fields to be green and Verified all the time. If they switch to red and Not Verified, OwnerRez will not longer send email using your domain name. We'll still send the same email out, but we'll swap in a different domain name as the FROM header on the message. OwnerRez automatically monitors your DNS records. If they stop working or are removed, we'll automatically switch the Verified Domain to Unverified and send you an email.
If you don't have an existing domain name already in there, no worries - you can add one now. Go back out to the Verified Email Domains list again and click the "Verify Domain" button. It will ask you to put in your domain name and then save.
After saving, you'll be presented with a screen of instructions that will tell you what you need to do. Notice the links in the instruction box. The Postmark help article will give you specific step-by-step help, so read that. If you are asking your domain provider or registrar for help, you can also use the second link to share the DNS records with them (red arrow below).
There's a convenient copy button there you can use to copy the URL and email it to your tech person or paste it into a chat window with your domain registrar. Make sure to tell them to click on the link and open it. This provides a public page where anyone can see what you need to verify, see the DNS records to put in place and click a button to verify the changes. The tech guy or domain registrar should easily be able to make the necessary changes by looking at the page we provide.
You can verify as many email domains as you want and OwnerRez will use all of them as long as they remain in Verified status. Wondering where to set the actual FROM email address on your account? Just set that on the theme or template like you normally would. If your themes or email templates have a FROM address that does not match the verified email domains on your account, OwnerRez will use a different FROM address when sending the message until your domain name is verified.
Please note that you must own and use a custom domain name for this to work. Using a Gmail or Yahoo email address will not work because you cannot control DNS records for those domain names. Likewise, the email address provided by someone else (eg. military email, Verizon, college email) won't work either for the same reason. You must be able to, personally, manage the domain name for this to work. If you need to buy a domain name, we recommend Namecheap as an inexpensive-yet-solid domain registrar and you can use our Namecheap partner link to do that at any time.
Moving on, let's talk about new PM stuff!
A couple weeks ago, we released a huge update for PM configuration and statements that caused some shock-waves throughout our PM community. The update included a number of "breaking changes" by its nature. When generating statements, many PMs used the old between-and selectors to cut off months in the past even thought those months had bookings and expenses waiting to remit. As we explained in the update, the between-and selector had to be removed because of the financial havoc and confusion it caused down-stream. But that led to new problems as hundreds of old bookings started re-appearing on statements with no way to remove them. Over the past couple of weeks, as we worked with our PM community and addressed their issues, we released a number of updates to streamline things so that the new update would work more effectively while also providing tools to cleanup historical errors.
The first major thing we did was deal directly with the issue of historical bookings re-appearing on new statements.There has always been the ability to select bookings on the owner statement and exclude them, but that exclusion was temporary. On the next statement, those same bookings would pop up all over again.
Ultimately, the correct method of dealing with old bookings re-appearing is to go to each of those bookings, individually, and figure out what kind of bookings they are why they are appearing. There are two reasons why old bookings are appearing when they shouldn't be, and each of those reasons has a different solution:
1) The booking is an historical booking that doesn't need to be part of the PM system and shouldn't be included on any statement ever.
If this is the case, you can fix this in two ways:
- Go to the property > PM Settings > Owner Configuration tab and change the owner to have the correct Effective Date for when bookings were supposed to start for that owner. After saving this, the system will show you bookings that don't match and you can select to remove those bookings from the owner. If you need to adjust the starting Effective Date of the current owner, first delete the owner from the property and then use the "Set Owner" button to put the owner back in place with the correct date.
- Use the new Batch Update screen under the PM menu > Settings section > Batch Update for Commission page and use the "set them to unmanaged" to find and remove old bookings that should not be showing up. You can target all bookings before a certain date and set them, en masse, to be "unmanaged" so that the PM system does not include them.
Again, this is only for bookings that were never remitted in the first place and should never have been picked up by the PM system. If a booking was part of a previous owner statement, and now has a different balance, that booking should continue to be marked as "managed" and not turned off. Turning it off will attempt to take back the money from the owner.
2) The booking was already remitted to the owner, on a previous statement, but now contains some change in the owner balance so the PM system is trying to remit the difference.
If this is the case, you need to look at the individual booking and determine what changed. Trying to make the booking go away, without fixing the underlying balance, is discouraged from an accounting standpoint. Often, the booking is easy to figure out such as a change in commission that was accidentally set after the fact or a host fee that is being newly expensed to the owner.
If you cannot fix the bookings to remove the owner balance, or there are simply too many to do and you just want them gone, we now have an option for that as well. You can now select and exclude specific bookings and expenses to be removed from statements, and you can also "exclude forever" which flags the booking or expense to never be picked up again. This can be done for both booking and expense line items when in preview mode. In the pic below, I have previewed a statement, selected some expenses and and clicked the "Exclude" button. I see the option to exclude temporarily or exclude forever.
Please note that:
- Using the exclude feature must be done in preview mode before the statement is created
- You cannot exclude voided expenses. If you tried to delete an expense, and it was voided as a result, you'll need to first go "unvoid" that expense before you can exclude it. Didn't know you could "unvoid" expenses? We just added that too - keep reading. 😉
In case you missed it above, excluding expenses is now possible in addition to bookings. You can now select and exclude both bookings and expenses.
Our new Owner Statement Bookings Remittance report now provides PMs with details about specific statement line items across wide date ranges. However, we noticed that it did not include a column that showed when the statement was generated. For instance, you might want to pivot or group line items by the statement they were part of or see when the remittance was generated so that you know why certain payments were included. We added a new Statement Created date column to the Owner Statement Bookings Remittance report to give you that information.
We also added a By Statement Date field to owner statements to clarify the real percentage of time being prorated. Previously we had an In Period percentage but that's misleading and ambiguous because the booking may not be in the statement period at all but need to be 100% remitted. For instance, the statement period could be all of January (1st - 31st) but the booking occurred at the end of December. In Period would be 0% but By Statement Date would be 100%, and so the entire booking should be remitted. You now have access to both fields for additional clarity, and both fields can be selected in custom statement views as well.
We also added an Owner filter to the main bookings list view so that you can find all bookings by owner only (ie. not by property). This matters because a property might now be owned by different owners based on the historical timeline, so filtering by property is not sufficient to return all of an owner's bookings. By adding a new Owner filter, you can now grab bookings by owner, bypassing the property.
We added field codes for Month, Day and Year of the statement as separate codes so that PMs can customize their owner statements better. There was already a field code for Statement Date but that would render out on the statement as the full date. Sometimes PMs want to show "Statement for January 2021" without the day and the new field codes allow you to do that.
Another common complaint we addressed is the issue of last minute payments not appearing on owner statements. Our statement generation checks what amount the guest paid and the date of when the payment came in to know if a booking is able to be included on a statement. You can read more about why that is necessary on our "why aren't bookings being included" support blurb. The problem is that sometimes payment do come in before the statement is generated even though the statement is dated a few days before that. For example, suppose we're running statements for end of January so the statement date is January 31. However, we're generating the statements a few days later on February 5th. In those 5 days, the payment for a January booking came in, so the payment is in hand. Previously, the system would not include that booking in the owner statement because the payment was after the January 31 statement date. To fix this, we updated our statement logic to check the generation date instead of the statement date to grab any last minute bookings that had payments come in after the end of the month. This allows you to include the full array of bookings, so that the owner doesn't wonder why stuff is missing. And if you want to exclude those bookings for some reason, you still can - use the exclude option mentioned above (but only the temporary option).
After doing all that stuff to owner statements, we turned our attention to PM statements. Owner statements have gotten numerous updates over the last few months, but PM statements have lagged behind. We caught up the PM statement side to have all the same criteria, features and options that owner statements have. Here's a quick list:
- The Included Bookings and Included Expenses options now match the ones in owner statements
- The prorate calculation for overlapping bookings now works for PM statements just like it does for owner statements
- The between-and selectors have been removed
- You can now exclude both bookings and expenses on PM statements
- The "exclude forever" option was added to PM statements
- The statement date on PM statements now smartly checks what the next month should from your previous statement
We also added a field to expenses that are linked to booking fees, showing the fee, so that you can quickly see and click across to the booking fee. This is similar to how expenses are linked to booking charges and show which charge the expense is linked to.
Last new feature in the PM is the ability to un-void expenses. We noticed that when users went to clean up their expenses, they were sometimes deleting expenses that were remitted on statements which in turn voided the expense. Expenses that are remitted on statements cannot be deleted, so we turn the delete into a void instead. However, if the user needed to reverse that, there was no way of doing it. Go to any voided expense, and you'll see a new Unvoid button showing at the top.
We also added a Voided field with a timestamp as well so that you can see when exactly it was voided. This should help you reverse anything you accidentally reversed previously! 🤔
As OwnerRez continues to grow - and we've been doing a lot of that lately! - we're working to add tools that help new users bring their data from other systems. Or you might want to work with your existing OwnerRez data but in a faster way. To that end, we've added new Excel imports for both Importing Properties and Owners. This is exactly what it sounds like and follows our normal spreadsheet model in the normal import/export area. These imports will allow you to quickly bring in new properties and owners into OwnerRez, or update existing ones, with a variety of fields. You won't be able to update all the listing data this way, but there are columns for most of the common fields we support. As usual, we supply a starting Excel template you can use to get started. From there, copy/paste your data over and then massage it to match our columns.
The last feature to mention is a new Government Identification section on the account profile. As we grow, OwnerRez continues adding users in many countries around the world. (In fact, did you know we have users in more than 150 countries now? Yep!) But some of those countries have special ID, VAT, NIF type fields that they require to be shown on invoices. We want our OwnerRez invoices (the ones you pay for using our service) to be official so we added a setting to the profile area so that you can set what your country's particular number is. And if it's set, we then show it on the invoice.
Enhancements and Tweaks
Let's start off the tweaks section by talking about Airbnb....
First, we switched our Airbnb IDs to use 64 bit numbers. That's tech mumbo-jumbo for saying that we upgrading our API connection to match some changes that Airbnb is making to their numbering system. If you're curious, a 64 bit number is really big - like big enough to hold 9,223,372,036,854,775,807 (billions x billions) as a maximum number. Apparently, Airbnb has grown a little in the waist and needs to let their belt out. We made sure OwnerRez is ready for the change.
Second, we added the "Lux" cancellation policies to our Airbnb settings. If you have a Lux property, you can now select the correct Lux cancellation policy to go with it.
Next, we removed absolute value (per-night) LOS discounts for Airbnb. To be clear, you can still set these in OwnerRez because we know that your vacation rental world doesn't just revolve around Airbnb, and we're cool like that. But for Airbnb, we no longer push absolute value (per-night) LOS discounts. If you have them, we'll skip over them when we push rates to Airbnb.
Then, we clarified that the "Laptop Friendly" amenity is a workspace. Some very clever (and very detailed? 🤨) user pointed out that saying "Laptop Friendly" on its own could imply that the guest can use a laptop at the property which... is pretty much every property with a Wifi connection, right? We added wording to make it Laptop Friendly Workspace instead.
Finally, we added support for Airbnb's new "default LOS discounts" feature by treating all LOS discounts without date criteria as default. Specifically, we examine all LOS discounts in your account and ignore any that are exactly 7 nights or 28 nights (which are handled by the weekly/monthly LOS settings already) and then set the others as defaults. If none are found, we pass an empty flag to Airbnb so that the defaults are cleared on their side.
Over on the HomeToGo channel, we noticed that the property mappings didn't link to the live listings which is something that HomeToGo does support, so we updated the page to support that. If you put in the HomeToGo identifier mapping on your properties, we'll show it on the dashboard and a link where you can quickly go to see your HomeToGo listing live.
Cancellation policies have gotten a few enhancements as well. First, we clarified the longer legal version to include the "(less $xxx cancellation fee)" blurb at the end, and then we also added a new clause that dynamically shows what is available to be refunded based on the dates of the quote or booking relative to now. For instance, if the booking has an arrival date of June 23rd and the cancellation policy is 50% refunded outside of 60 days, then the quote will show that the 50% refund happens before April 24th but nothing is refunded after April 24th. Like this:
Once April 25th rolls around, the same quote would show "No refunds". Like this:
The idea here is to give guests some specific language about the dates they need to watch out for and create an air-tight case that you disclosed the refund policy if a credit card chargeback occurs.
This new dynamic date-based language can also be used in renter agreements or messaging templates via a new field code called {BCANPOLDAT}. Drop that baby into any template and you'll get the same language that is shown in the pictures above.
Over in portal access land, we cleaned up a few things so that managing portal access is easier. We noticed that portal access users stuck around even when their access was removed with no way of hiding them. We now hide portal access users that have no access granted, so if you remove access you're no longer bothered by extra users hanging around. You still can't delete them, but at least they're hidden now. We also made sure to check if owners are linked to portal access before allowing you to delete them. We found a rare edge case where that was being allowed.
In our Communication History area (under Tools) you can see all outbound messaging history across email, SMS and Airbnb. And for SMS and Airbnb, you can see inbound as well. This is an extremely useful feature because it shows the actual messages being sent out to guests so you can see if something was missed or what it looked like on the way out the door. And for email, you can see if the recipient opened or read it sometimes too. One of the cool things we show is the template and trigger that were used if the message was sent with a template or trigger. We noticed though that SMS and Airbnb messages were not showing this information, so we updated SMS and Airbnb messages to show (and link) to the templates and triggers they are sent with.
A couple other little tweaks...
We added a "any stay during period" option to all line item reports, so now you can query records where the booking touches the date range you are filtering. Before you could only target bookings that arrived or departed in the date range, but now you can grab anything that touches the period.
We noticed that some of our more creative tech-savvy users were having problems using our rich-text editors when it came to certain markup and formatting. This was because our rich-text editor has certain restrictions in place to keep the formatting clean. But the restrictions were a little too restrictive, and we love the creativity of our users, so we expanded the rules to allow more rich-text. In tech-speak, you can now use any attribute parameter on <div> and <span> elements. Keep being creative! Keep pushing the boundaries!
Bug Fixes
My property, but not my booking! We recently updated our property/owner configuration stuff and, in the process, forgot that a property can now have different owners at different times. This means that each booking needs to be looked at, one by one, on the poral access side instead of the entire property. Otherwise, a current owner might see all the bookings of a previous owner. We fixed this to only show the applicable bookings.
Extra inquiries and quotes. The same owner configuration changes also made it so that some inquiries and quotes were duplicating on the inquiry and quote lists. There weren't extra inquiries or quotes being created. The same inquiries and quotes were being shown multiple times. This has been fixed.
No setting, no problem. You can add criteria on surcharges and triggers for many things like "number of nights > 7", but some users forget to add the actual value (eg. 7). We now ignore this instead of throwing an error. If the criteria is incomplete, we allow the surcharge to work, but that piece of criteria is simply ignored.
Selecting hidden seasons. Did you know you can change the Season Rates editor to only show certain properties and seasons when you're editing? Yep! Only we noticed a bug where selecting across seasons would also select the hidden seasons (ie. those filtered out), and then rates were being set across all of them. All fixed now!
Scheduled payment collected when? Typically, scheduled payments will show the approximation of when they will be collected. We changed this to show the actual date after the scheduled payment was processed.
Last statement deleting. Under the covers, our new PM/owner statement system now tracks the start/end period for each statement as well as the previous statement relative to any statement. Only we noticed that when a statement was deleted, the reference to the previous statement was not properly updating, so we fixed that.
Next statement date after deleting. Similar to the previous issue, after deleting an owner statement, the next statement you generate was showing a Statement Date that continued into the future
Theme Header/Footer clearing. Ever try to clear (ie. remove all the content from) a header of footer in the Themes area? It probably gave you an error. We fixed this to delete the section instead of throwing crashing.
Owner field codes on blocks. In a recent update, we moved a bunch of field codes around and in the process dropped owner field codes from blocked-off times. We added those back so you now set owner field codes in blocked-off times again.
Missing Instruction Manual text. We have a field code for the Instruction Manual field on properties so that you can include it in website pages, email templates and so on. However, our Instruction Manual field is rich text which doesn't work in plain text templates such as the ones used by Airbnb or SMS. When that happens, our field code system is supposed to automatically transform the rich-text field into plain text, stripping out the pretty formatting, but that wasn't happening for the Instruction Manual field. This has been fixed.
Mountain Lodging 2 .com's? Our Hosted Website feature has a several templates you can use to prefill your headers and menus. The Mountain Lodging template had a typo where there were two .com's on the "Admin Login" link, so we corrected that.
Incorrect In Period %. Up above, I mentioned that we added a new By Statement Date column to owner statements for clarity. After adding this, we noticed that our In Period column was displaying things a tad off, in terms of the number of days actually in the statement period, so we fixed that too.
What about old bookings? The recent PM overhaul made it so that you can configure different owners at different times and, when you change it, the system recommends changes that should be made to various bookings. However, we noticed that resetting the original owner (ie. deleting all owners on the timeline and setting a new one) did not recommend changes to historical bookings that may need to be un-managed before that, so we fixed it to look at those bookings too.
Disconnecting QuickBooks. There are multiple ways to disconnect our QuickBooks integration, and if you do it from the QuickBooks side (ie. go to QuickBooks first, find the Apps > OwnerRez connection and hit the kill switch) it's supposed to bring you back to OwnerRez. It was correctly coming back to OwnerRez, but not showing the right final confirmation message, so fixed it.
QuickBooks payments being deleted. Speaking of QuickBooks, we uncovered a bug where users with "don't push payments" turned on were still having payments deleted when our sync ran. We fixed this so that payments aren't deleted or set if don't push is turned on.
Channel Bridge 65-character addresses. Channel Bridge import was crashing when it tried to import addresses that were exactly 65 characters long for some reason, but all better now!
Quotes and Google Analytics tracking. We recently updated our Google Analytics integration to supposed the new GA4 standard. But we noticed it wasn't working on quote acceptance forms, so we updated that too!
Statement period showing. Every PM and owner statement has a "period" with a start and end date, but we don't show it to you in the app. It's recorded under the covers. Recently, we noticed that we were accidentally showing a Period field when generating multiple owner statements in batch. That has been hidden.
Unmanaging past bookings instead of future. When we added the ability to un-manage bookings in bulk, we accidentally left the date criteria aimed at future date ranges. The common process is to un-manage past/historical bookings, not future ones, so we flipped that around. If you go the other way, and set bookings as managed, the date range still aims at future bookings.
Switching words. Little cleanup/consistency in the PM configuration area - when future change are coming, we now call it "switch".
Bottom padding on hosted sites. We added a little padding to the bottom of the Logged In admin bar that shows on hosted websites because some browsers (mostly Safari) occasionally hide the bar or push it around depending on the page content. All good now.
Owner-only expenses. Most of the time, expenses are entered against a booking or property, but sometimes you need to expense something against the owner at large. This is perfectly possible in OwnerRez, but a couple of our PM reports weren't showing those types of expenses in certain situations. This has been fixed.
How many days in a season? We found and fixed an issue where "everything but" logic on seasons was calculating an extra day when selecting the seasons to exclude. This was affecting both Airbnb and Vrbo API integrations.
Auto-PM Lock and future payments. We noticed an issue where a booking was being fully remitted on statements and having PM Lock automatically turned on, but the booking still had future payments scheduled. There are some rare-but-possible scenarios where this can happen. We changed PM Lock to only turn on automatically if the booking is 100% remitted and no future payments are scheduled to be collected.
WordPress plugin sanitizing. We noticed some users that are using are WordPress plugin were sending string values instead of integers when generating quotes, so we updated our WordPress plugin to detect this and clean it up on the fly. Don't know what a "string value" is? I didn't think so, but hey something works now that didn't before. More tech mumbo-jumob! 😀
