Latest Activity...
Can you clarify/confirm that multiple locks attributed to a single property will all stay synced with the same code even if using the "Generate random code" option? There currently are conflicting comments by OR Team Members regarding this:
If you connect one lock and associate it with multiple properties, it should have the same code at all of those properties, even if the "generate random" is selected.
If you connect multiple locks and associate all of them with the same property, each lock will have a different code. Correction: all the locks will use the same code for the one property. So when a booking is created, and the booking shows multiple door locks on the overview page, all the codes should be the same random number.
Caveat to that.... If your door locks at the property have different maximum code lengths, OwnerRez will detect that and auto-trim the code to work in each door, so it may appear to be different codes, but this is just because a particular door lock had to be trimmed down.
This is the same behavior that has always existed with all of our lock integrations (ie. third-party lock partners). The "Code Generation" settings didn't change for Schlage. We did add some logic to detect what Schlage can handle (eg. length of code, etc) but the underlying logic that creates codes based on random or last-four-of-phone stayed the same.
While not a dealbreaker, it would be extremely helpful to manage additional non-guest codes through the integration: team members, cleaners, pest control, maintenance, etc. That is a feature that I will miss when I make the switch over from RemoteLock as it's easier to bulk add/edit access to numerous property locks in one place than doing it lock-by-lock in the Schlage app.
Great idea. We don't have a task for this, but it would be really simple now that we show the active codes (where you can lock and unlock it, and see the battery) so being able to set/remove codes from on high would be pretty simple.
Does the integration work with Parent/Child listings so I can assign one lock to multiple "properties"?
Yes.
All of our lock integrations, whether OR powered or third party, have a list of door locks, and each of those door locks can be assigned or associated with multiple "properties" in OwnerRez.
Once this is connected and mapped, you'll see the entire list of locks show up on every booking with their own codes, based on your code generation settings.
Hi Ocean Zen,
We don't like to openly debate users on our forums/blogs, so we typically let users talk amongst themselves without responding, but I feel like there are a couple of things you mentioned that should be corrected, or at least a broader perspective added.
1) We have a decent-sized developer and product team now - more than a dozen people in engineering/testing. At any given time, 3-4 "big projects" are going on with the same number (3-4) in testing. In and around that, many dozens of medium and smaller-sized features and enhancements are worked on, with dozens more bugs also being fixed. Our change log updates weekly, with most weeks showing 15-20 updates. (Again, that's per week). So my first point is simply to point out that the team isn't spending months "just working on Schlage lock while QB, Google VR, Inbox, etc are ignored". We are managing a large slate of coming projects, many of which are in development at the same time.
As an example of other big projects...
Google VR has been worked on, internally, for almost a year now and there are almost 1,000 listings from OwnerRez integrated through our Google VR integration. It has been a difficult integration, but we've been pushing forward and making huge strides. If you follow our Google VR feature request, you'll see some of that publicly noted.
QB has also already begun some significant changes. I know this is an area you're passionate about. We've heard you and, frankly, we knew we were behind on most of that feedback already. QB is a significant lift that involves a lot more review/testing work. We were in meetings with accountants, talking about strategy, several times over the past 18 months. But before that, we've had to change some of the fundamental connection/logging aspects of the integration, so we've been down in the weeds on that part first.
Before Inbox cleanup, we've had to clean up messaging features (like Autoresponder) and work our way through some of the side features so that we can get to the main stuff. That, too, has already been underway for a while.
Our PM system has a large V2 about to drop that we've been working on for 2 years which changes a number of significant things around commission, expenses, and statements.
I could hit half a dozen other major things, but hopefully you get the picture.
2) It sounds like you see Schalge as a minor thing that no one cares about. Direct lock integration (Schlage, Yale, Kwikset,etc) has, for a long time, been highly requested by OR users. Many PMs are paying hundreds or thousands per month to middle-ware platforms to the point where their middle-ware lock platform costs are higher than their entire OR bill, even though we do website, channel management, CRM, automated messaging, etc, etc far beyond simply setting locks. This was not some minor integration we decided to do on a whim. If you look at the Feature Request forum, you'll see that Schlage Encode has been one of the highest-voted requests for a long long time - far more than Inbox, QB and other items. At conferences, a lot of medium and large PMs go on and on about their lock difficulties and costs. Last year, when we increased our prices, we promised to look for ways to lower the overall bill of users in other ways - lock integration was part of that, given what we saw in the industry. The $4/month price we are charging is the lowest anywhere and often half of what PMs are paying. And we priced that to cover our API fees from Schlage plus development/support costs. If you're a PM with 50 locks, the extra $100-600 per month (difference between $4 and $6-10/lock) adds up.
I am going to mention here that pricing is really hard to get right. We aimed to cover our API/dev/support costs, and not make it a profit center, but also make sure we didn't regret going too low later. If you're a PM with a bunch of locks, we absolutely are open to discussing a lower cost as we move forward and gauge adoption. We wanted this to be fast, easy, and get it out there with room to change/negogiate later.
3) I'm curious about your claim that the integration is "much inferior" to other lock platforms. For those that are Schlage only, this first release has virtually everything you need to manage your locks from a business/automation standpoint. Our team has been noting down feedback (like the "use guest name instead of ORB number" comments) but the nuts and bolts are pretty solid and baked directly into the product. Have you used the new Schlage integration yourself and have specific examples of where it is significantly inferior? If so, let us know, as we've released private betas for Igloo, Hubitat and others coming, and it will help factor into those integrations as well.
There's no doubt that a standalone lock platform (such as our many middle-ware lock partners) will provide a lot more polish - things like notifications for when a guest uses the code - and that's where the value is for users to use those partners. We aren't trying to replace those partners, nor add a profit center for ourselves. We are delivering a constantly-requested feature in a bare-metal non-fuss way for PMs that want it baked in.
4) Not all development work is the same in terms of speed and available resources. It takes a very different design/tasking, dev, review, and testing roadmap for something like QB than it does for a standalone lock integration like Schlage. Schlage didn't take that much effort relative to other big feature requests. There is an API cost from Schlage, and some other administrative things we had to get in place, but the work itself rode on top of many other existing lock integrations (eg. how to generate codes, using last 4 digits of guest phone, grace periods, etc).
I hope this doesn't come off as argumentative - that's not my intention. I appreciate your continued feedback and passion. Your QB topic is a great example of what I mean.
I may not be able to attend this, so I may need to watch the replay.
So please include details on how to include where guests can initial next to specific provisions and how to provide for them to upload their IDs.
Opportunities are like sunrises. If you wait too long, you miss them.
Opportunities? 🤓 Yes, please! Don't miss out on this product update detailing our November 1st release with 17 updates. These nerdy nuggets include improvements to the Damage Protection program feature, Email List Report Tags Criteria added, Check-in Arrival Window Rule addition, and much more!
OwnerRez's built-in Damage Protection offering, paid for on a per-booking basis, protects against accidental damage a guest might cause while at your property. Powered by RentalGuardian®, Damage Protection allows you to have such coverage without having to involve the guest at all. While there has been no change to the cost and coverages, we've updated the Damage Protection feature in several ways.
Coverage Names were changed to match what RentalGuardian now refers to the coverage levels as (e.g. Gold Standard, Gold Enhanced).
OwnerRez has also updated the program's agreement terms (which hasn't been done since Aug 2022 when the in-app agreement was added) to include Payment Terms, several paragraphs just above where the user is asked to sign.
The other big change is to allow users the ability to add damage protection when converting a Blocked-Off Time event to a Booking. During the convert to booking step, you can checkmark whether to add the default level of damage protection from the property's DP settings to the booking. As long as the dates are in the future the system will present this as an option.
Similarly, in the rare event that a booking was canceled that never had damage protection coverage, but is now being reactivated (but you've since turned on damage protection), the re-enable screen now has the same Apply checkbox option.
There was a Damage Protection bug that we fixed as part of this work, which you can read about in the Bug Fixes section below.
Haven't turned on Damage Protection yet? You can opt into the feature by navigating to Settings > Financial > Damage Protection.
Watch the Damage Protection Insurance Video to learn more.
Sending marketing emails to previous guests can be an effective strategy for generating repeat bookings, and utilizing OwnerRez's Email List Report is a crucial component of that strategy.
We've improved the Email List Report by making some significant new changes.
Check out our Email Blasts support article to learn more.
While not usually a problem with smart locks, coordinating guest check-ins with keyed locks can be challenging if guests arrive after business hours to pick up their rental keys in person.
And OwnerRez users who are Airbnb API-connected may have noticed the relatively recent addition of a check-in window on Airbnb's platform. However, users could not set check-in arrival window rules in OwnerRez.
We've now added check-in window property rules that allow OwnerRez users to set a check-in window. Users can add their property check-in window by navigating to their specific Property > Rules > Defaults > Check-in.
Property Managers who juggle multiple properties can find attributing expenses and other transactions to specific property owners complicated. OwnerRez already has many import processes that expose Owner IDs (expenses, owner applicability, etc.), so we decided to add more visible Owner IDs in other areas as well.
OwnerRez has exposed Owner IDs in-app in the following sections.
OwnerRez used to require users to manually cancel future bookings before disabling a property, causing confusion and inconvenience.
We've updated this process to automatically cancel all future bookings as a property is disabled.
Previously, when a booking was fully remitted on an Owner Statement it was automatically PM locked, which locked the charges, etc. There are now two situations where even if a booking looks to be fully remitted on Owner Statements, it won't be automatically PM locked.
Learn more by reading the PM Lock support article.
When Vrbo Messaging was released in June, new Vrbo API connections did not automatically configure a request to complete a renter agreement channel template with an associated trigger creation.
When a new Vrbo API connection is activated by OwnerRez users, a renter agreement channel template with an associated trigger is automatically configured, just like when a new Airbnb API connection is activated. When the second listing channel is connected (Airbnb or Vrbo), it will be added to the first trigger using the same renter agreement channel template.
Learn more by reading our Channel Templates and Request for Contact Info (real email address) and Signing support articles.
Bypass Vrbo Channel Bridge Booking Header Single Item Endpoint. Vrbo removed an endpoint used by the OwnerRez Channel Bridge to download guest physical address booking information during the Channel Bridge export process. We resolved this glitch by creating a workaround solution to no longer populate the guest's physical address during the Vrbo CB export process. The guest's physical address can instead be populated during the renter agreement signing process. All other guest booking data will continue to be exported from Vrbo during the CB process as expected.
Don't Send User or Guest Payment Receipts for MoR Payments. OR users were being sent payment alerts for Booking.com (BDC) Merchant of Record (MoR) payments to OR users, which was superfluous as BDC manages the payments on their side. So OR will no longer send payment alerts for BDC Merchant of Record (MoR) payments. OR will also no longer send payment alerts or guest receipts for newly added MoR channels such as Hopper and Whimstay.
Don't Cancel DP When Canceled After Arrival vs Departure. Bookings with Damage Protection (DP) added that were canceled, either prior to or after arrival, had the DP incorrectly canceled as well. This issue has been resolved. Bookings canceled after arrival will still have Damage Protection.
Fix Timeout Issues With Vrbo Listing Import. OR users were experiencing intermittent timeout errors while attempting to add a property through the Vrbo Listing Import process. This glitch was fixed, allowing the Vrbo Listing Import process to run correctly.
Review Guest Form Design Tweaks. Following our October 9th Redesigned Guest Review Form release, we completed some clean-up tasks, including removing extra spaces, dashes, unnecessary parentheses, and padding.
Show Expense Category Columns Based on All Booking Expenses. Not Just Charge-linked. Bookings created by OR PM users encountered incorrect expense amounts displayed on statements due to a linking issue. The data was correct, but the statements listed incorrect expense amounts. This glitch has been corrected so that expense amounts will be correctly linked and displayed on statements.
Show Door Dodes If They Exist, Even if There is a Subsequent Error. On rare occasions, if a door code encountered an error, the error was displayed in OwnerRez, but the old door code was no longer visible. This could be problematic for guests as the OR user could no longer access the most recently generated and functional door code. This glitch has been corrected, and OR users will now be able to view the last door code generated even if there was a subsequent error.
Show Selected File on New Blog Header/category Teaser Images. When selecting image files for either Hosted Website blog headers or categories, users could not preview or view the selected images until they clicked the "save" button. However, after clicking "save," the page would close, and the user had to reopen it to verify that the selected image was actually saved. This bug has been fixed, and image files selected for either Hosted Website blog headers or categories will be visible correctly for preview before the users click on the "save" button.
When Syncing Airbnb Transactions, Look Farther Ahead for Upcoming Bookings. The Airbnb Transaction Sync process has been optimized to now check for any upcoming payments up to 7 days after the departure of a given booking.
Google Vacation Rentals: Taxes and Fees (Mostly Fees) Need to Calculate Applicable Date Ranges and Length of Stays. Private Beta Flat fees applied to the length of stay (e.g., deep cleaning fee for stays of 7+ nights) did not have a visible length of stay qualifier to configure. We have resolved this issue by ensuring that the Length of Stay qualifier fields are visible and configurable when adding Taxes and Fees.
Does the integration work with Parent/Child listings so I can assign one lock to multiple "properties"?
On Tuesday, 11/7, join Ryan Collins as he discusses everything you need to know about Rental Agreements.
We'll cover how to modify the default agreement, use custom fields, upload an existing agreement, have guests sign more than one agreement, and more!
The session starts at 2:00 pm Eastern, 11:00 am Pacific. It is free to join, but you need to use the sign-up for OwnerRez Focus Session - Rental Agreements link to register.
You can find all of our past and future webinars on our Webinars page.
Excellent, thank you!!
@Ownerrez and/or Schlage integration requestors:
What was the purpose of spending valuable programming resources on this integration.
I assume that that all the people requesting it was because they thought it would be FREE (ie included in the cost of PMS subscription). I would be curious if there is any other reason.
In my opinion, this integration ADDS ZERO value to OR customers. It is MUCH inferior to the many 3rd party solutions already in place. It costs almost as much $4 vs $5 for Jervis (the least costly) and provides a fraction of the capability.
Meanwhile we have CRITICAL NEEDS that can't easily by supplied by 3rd parties like:
- Integrated INBOX
- Accounting integration that actually works - not just 80%
- Google VR integration
- list can go on....
Can leadership at OR please explain how things are being managed and prioritized - I am sure if you disclosed that you were going to charge $4/mo that 90% of the requesters would have down voted the request in favor of other features. I read threads where people joined over 2 years ago having been promised an integrated Inbox and instead we are creating features where I can't see how they offer anything extra from what is offered from 3rd parties
Can leadership please explain?
First, thanks for working on this feature. I really do appreciate it and I'm posting this to improve the product. I hope it's taken that way.
I have two locks. One is pushing 4 digit codes and the other is pushing 8 digit codes. They are both set up the same and have always had 4 digit codes previously.
Several of us have asked when the codes will be deleted off the lock. Support keeps pointing back to the grace period. The grace period is a setting in the lock that tells it when the code should work. For example, 1 hour before check in and 1 hour after checking. That isn't the same as when the code will be deleted off the device.
Finally, the decision to use the Booking # vs the Guest Name is flawed. Here's a mock up. Find the Remote Lock guest (John Doe) and the OwnerRez guest (Jamie Smith).
TO OR TEAM MEMBER... I looked at the article sent, there is no option to set the last 4 digits... "The "Code length will be determined by the lock" is grayed out and there isnt a place anywhere to tell the system to generate the last 4 digits. I have a guest coming in tomorrow. And I just integrated with this service yesterday and have looked at all your resources and I cant find anywhere how to do this and make sure its the last 4. Please advise.
It set a 7 digit number automatically and have no way to change it to just the last 4 digits. All our scheduled messages with check in instructions/door code are all last 4 digits. If this isnt something that we are able to set, definitely need to cancel this service as it defeats the whole point of needing control and flexibility. Just also realized the name issue. Canceling. A promising feature with lots of potential but def lacks the most valuable things having door lock integration.
Thrilled to see this integration go live! Great work, OR team!
I echo the feedback about needing the guest name rather than the booking number to appear in the Schlage app. The current RemoteLock standard of using the guest name (even though it cuts off after the character limitation) is far easier and beneficial than a booking number that needs to be cross-referenced.
Can you clarify/confirm that multiple locks attributed to a single property will all stay synced with the same code even if using the "Generate random code" option? There currently are conflicting comments by OR Team Members regarding this:
While not a dealbreaker, it would be extremely helpful to manage additional non-guest codes through the integration: team members, cleaners, pest control, maintenance, etc. That is a feature that I will miss when I make the switch over from RemoteLock as it's easier to bulk add/edit access to numerous property locks in one place than doing it lock-by-lock in the Schlage app.
Great feedback all around. Keep it coming.
Your website exemple link doesn't work!
“There is a 12 character limit to access code names, so we couldn't fit the guest name in there as well and keep it unique so there are no naming conflicts.”
I think this was a bad decision. You should just have it setup by default to only send the code to the device a few days before booking, then deleted after booking. Using this setup it’s highly unlikely for there to ever be a conflict with the naming of each guest. You don’t need to fit the guest name within 12 characters btw, you simply take the first 12 characters of the guests first+last name.
The problem with the way you have it now is that it’s harder to make any edits or even view an entry in the Schlage app itself since then the user would need to correspond to OR first to get the booking number.
I think you guys have it setup this way because you’re catering to the idea of having the codes sent to the device immediately upon booking. But that shouldn’t even be an option anyway because it creates a higher likelihood of conflict with either the name or the door code
In one of the OR Facebook groups someone complained about how in the Schlage app you can’t see the guests names anymore. I agree that would be a reason to not switch over since I’d only save $1.40 a month.
I would also like to know this. Does it use the last 4 digits from the guests phone number?
Marlena, you can configure door codes to be the last four digits of the guest phone number while setting your Door Lock configuration and send to guests prior to check-in.
I don't see a way in OR and also I don't see any configuration about code length in the Schlage iOS app (where I can set 4 digit codes). when I try to set a 4 digit code in OR the set code popup errors with "Code must be 8 numeric digits"
We actually ran across this earlier this morning and are preparing a hotfix to correct it.
There was also a Schlage update to the API in the past few days that fixed a similar problem for integrated partners (like OwnerRez).
Very soon, this will be fixed so that you can set a code 4-8 digits in length.
Thank you Anne.
Is there any way to change the code length? I don't see a way in OR and also I don't see any configuration about code length in the Schlage iOS app (where I can set 4 digit codes). when I try to set a 4 digit code in OR the set code popup errors with "Code must be 8 numeric digits"
Alin, did you review the Schlage Limitations? That may be affecting your configuration. Feel free to reach out to our Helpdesk Team for further questions.
Thank you Anne.
Is there any way to change the code length? I don't see a way in OR and also I don't see any configuration about code length in the Schlage iOS app (where I can set 4 digit codes). when I try to set a 4 digit code in OR the set code popup errors with "Code must be 8 numeric digits"
I don't know what to make of this. My configuration is not the same as the sample configuration from Door Locks - Overview
My configuration is on the left, and the screenshot from the doc is on the right with those arrows showing the differences. To be clear, by differences, I mean configs that don't show up in my settings, not different choices of values.
What I'm honestly more "concerned" about is not having the ability to set the code length. As far as I can tell, right now, the system wants to generate a 6-digit code and I can't change that. In Schlage iOS app, my existing codes are all 4 digit codes
Have I done something wrong here?
Alin, the support doc screenshot has been updated but it is not a Schlage specific screenshot. See the Schlage support doc for more specific details.
I don't know what to make of this. My configuration is not the same as the sample configuration from Door Locks - Overview
My configuration is on the left, and the screenshot from the doc is on the right with those arrows showing the differences. To be clear, by differences, I mean configs that don't show up in my settings, not different choices of values.
What I'm honestly more "concerned" about is not having the ability to set the code length. As far as I can tell, right now, the system wants to generate a 8-digit code and I can't change that. In Schlage iOS app, my existing codes are all 4 digit codes
Have I done something wrong here?
Hey Paul. We use the Yale Assure locks models YRL 216/236 and YR C/D 226/246/256. Both are Wifi and we use the August app and remotelock to control today.
I have three units behind a gate and need for the guests per each unit to have the same lock code for the gate's Schlage lock as they have for their respective unit. Can this be configured?
If you map the single gate lock to each property in question, then use either the "Use Guest Phone Number" or "I will manually set the code" option, then each lock will get the same code as long as each lock is using the same code length.
If you use the "Generate Random Code" setting, I would not guarantee each lock would get the same random code, particularly if the code failed to set on one of the locks and the system has to retry setting the code it may regenerate a new random code.
So it sounds like from what I’ve been reading, there is no current “planned” support for our August integrated locks. I had switched to yale/august locks thinking they were a pretty common standard i
Curious. What August lock (model number) are you using? Is it Wifi or smart/z-wave?
So it sounds like from what I’ve been reading, there is no current “planned” support for our August integrated locks. I had switched to yale/august locks thinking they were a pretty common standard in STR but if we have to we will switch over to schlage as I prefer OR integration over 3rd party.
Is this compatible with the Yale/August setup? I am not familiar with Hubitat, but from my quick review it looks like they are not using the August platform. Looks like they use zigbee and zwave, rather than the yale august app. Any insight is appreciated. I
This release only includes the general availability of our Schlage integration, which supports the Schlage Encode / Encode Plus line of smart locks. Igloohome and Hubitat are in closed beta.
Hubitat is intended to be used as an alternative to always-online "cloud" home automation, thus its focus on the Zigbee and Z-Wave connectivity. It can support some Wi-Fi devices, if the devices can receive commands over the local network and not require a cloud integration. I've tested this with my Kasa smart switches, but am unaware of any Wi-Fi smart locks that are supported. Being a piece of physical security, I would guess most manufactures would worried about network security. The Z-Wave and Zigbee protocols are short-range, and require a secure handshake to pair with your controller hardware.
Hubitat requires more setup than other out-of-the-box solutions, so I would not say just anybody should run out and buy one in anticipation of the upcoming support. Definitely read up on it and decide if you'd prefer a more turn-key solution (lock pun!).
Does the Schlage Encode lock require the Wi-Fi to be working at the time the guest is checking in or will the lock save the data at the time the booking is created and schedule the code in advanced without the need for Wi-Fi at the time the guest checks in?
The codes are sent directly to the lock and saved locally. You will actually get an error message if the lock is offline or the code failed to generate for any reason (either in a popup or email, depending on how the booking was created in OwnerRez).
Joseph,
The codes are stored locally in the encode and will work even if wifi goes down. It may be advantageous to generate several back-up codes in the event of wifi failure and last minute bookings.
Trevor
Is there a buffer time so that the code can be active a few hours before official checkin time?
You configure this in OwnerRez. We will take the check-in / check-out time and subtract / add the grace periods your configure on the lock integration (right at the top "Arrival / Departure Grace Period"). The default is 1 hour.
