Latest Activity...
[Another topic was closed as a duplicate of this topic (Cancellation policy options)]
It would be great to have different cancellation policies for defined seasons. We don't want shortened timeframes for our main ski season but would like to offer a more flexible option for our off season rentals.
For guests that are staying longer than a certain number of days, my jurisdiction will count the guest as a "tenant" instead of a guest. That means I have to provide a lease agreement with additional pamphlets related to Tenant's Rights, Lead-Based Paint, and other topics ATTACHED to the lease agreement. Obviously I can't do this now in OwnerRez. Instead, there is the text scroll box that has a Renter Agreement. It would be good to have the option to use a PDF-form signing service that will return the status of the form as SIGNED back to the OwnerRez reservation form.
I know OwnerRez is more-so geared towards short-term guests. However, a feature like a PDF-form signing service (such as HelloSign and Docusign) would be a great tool to meet the growing demand of local mandates. I still want to use OwnerRez for when I have short-term guests in a property in the next town over.
There's now a free OR-integrated waitlist tool that does this.
https://www.ownerrez.com/support/articles/redcarpet-host
I can't share a narrow timeline (as that will backfire on us :-)), but I can safely say this year. We're working on it every week and will share a more definitive release timeframe as soon as possible.
We would like a trigger to fire based on a 1 to 3 start review received from the guests. This will alert us that there is a issue with the condo and may be resolved before a 1-3 start review is received again.
Users are unable to automate or schedule any type of reservation-level report. This means the process of seeing recent bookings created is completely manual, necessitating a human to manually set filters, run daily reports, export the csv, and clean the data as needed. It's very time consuming and inefficient.
Other PM systems can automate the daily sending of a reservation email to the user. This would be great to have here.
I agree, Neil. The drag-and-drop is slow and glitchy, and not an efficient way to manage the ordering of this many photos!
Thank you!
That will make it so much easier!
Here's how to duplicate a property:
https://www.ownerrez.com/support/articles/add-new-property#duplicate
BLESS YOU! This is SO SO SO needed! Now of course I have to ask....is the window now days, weeks or months?
Hello!
Where is the duplicate feature? I would love to try it!
Thank you,
There is a discrepancy between the total amounts shown in the Booking Summary and Booking Detail reports when selecting "any stay during period". I emailed OR support and rather than this be flagged as a concern or a bug, I was told to start a Feature Request for the fix.
I'll walk y'all through where the error lies, and I'd recommend you run similar Booking Summary and Booking Detailed reports for one particular month on your own properties so you can see the problem in action.
As an example, I ran a Booking Summary for April with the following criteria:
The total shown for April is 44,619.17. Screenshot to demonstrate:
Then I ran a Booking Details report for April with the same criteria:
The total column for April shows 46,676.27. None of the figures in this report come to the same total of 44,619.17 from the Booking Summary report. Screenshot to demonstrate:
The "Any stay during period" option for the Booking Summary report includes the phrase "pro-rate", however that same option on the Booking Detailed report does not. That's the reason for the discrepancy. On the Booking Detailed report, even if you select "any stay during period" it is showing full booking totals not the pro-rated amounts for those dates only.
So there is currently no way to run a Detailed, pro-rated report for a month to see the breakdown of the Total figure obtained with a Booking Summary report.
To me, this is something that should be corrected -- not a feature to be requested. Alas, here I am per OR's instruction. Hopefully others will have discovered this discrepancy and think to come here to see if a solution has been requested so they can add their vote.
Hi,Can I make a suggestion that you allow photo ordering not just by drag and drop but also allowing us to put a number on a photo and that it moves it to that location. for example i have like 100 photos and dragging and dropping is a pain. if i could say make photo #58 to #33 that would be great.
I recently dropped RemoteLock for the direct Schlage integration. It all works seamlessly and as expected... except for this one thing. When inserting the door code in message templates (using any of the field codes OR has available for this), it now includes the internal name of the property door/lock AND doubles it up when there is more than one lock at a rental. For example:
This is clunky and adds unnecessary confusion for guests.
As a comparison, this is how the exact same message appeared with the RemoteLock integration (same property, different guest) -- which not only looks better but is a much simpler and clear read for the guests:
My request is two-fold:
1. Remove the internal property/door lock name when displaying the code number for guests -- or at least make it optional in case some hosts do prefer it this way.
2. When there are multiple doors at a property that all share the same code, only display it once. (Again, this could easily be optional in case anyone does prefer it the way you display it now.)
@Joel - Yes, however on Mobile it's become a multi-step process.
On a desktop, clicking the search icon places focus into the search box immediately so no second click is necessary. Simply start typing.
I agree with this 100%!
Love it, thank you for the sneak peak!
One thing I request you change back is the SEARCH button. Please make it ready to accept information like before.
Now, entering anything is a two-click process. It sounds like a small thing, but it isn't.
The open and ready search box was a beautiful thing.
Hey everyone! We recently moved this feature to In Development, which is exciting! If you joined the Under the Hood webinar back in April, you also got to see a sneak peek of an earlier version of the inbox's design. However, I wanted to share with you the latest Inbox design (not necessarily final, but very close).
Upon release, the v1 Inbox will handle Channel and SMS messaging (if you have it enabled). Email in the Inbox (incoming and outgoing) will come as a follow-up version, but this gives you an idea of the look and feel of what the Inbox will eventually bring together. The info pane on the right-hand side will be especially useful to give users context of who they are messaging with and what property it is regarding.
We are working hard to release the new inbox as soon as it's ready! Thanks for your input and patience on this exciting development.
We have rates for periods of time like "spring break" or "fall break" that occur every year but don't necessarily start on the same date. We currently use spot rates for those but I'd rather be able to use recurring seasons and set the start and end time to relative dates like "second Saturday of the March"
Devin
No, that's a misunderstanding - Glamping Hub does not have an internal channel messaging system like Airbnb and Vrbo do. OwnerRez communicates with Glamping guests in the same way as it does with direct-book guests - email and (perhaps) SMS texting.
Quick question on Glamping Hub: I just added my cabins to Glamping Hub. I assume that I need to set up my templates and triggers for "channel" communication as opposed to "email" communication, similar to Airbnb. Is that correct? Thanks!
I have a reminder to check every 2 months. Been checking for a year so far :)
Adding our support for this feature - PriceLabs has the ability to push this but OR has to be able to accept it. Sounds like it might be complicated but would love if this were available!
I would prefer to see the first feature introduced as soon as possible
Realistically, that won't happen, because that alone is not in demand by enough people, nor is it likely to be. By combining what you define as the first two features (which I still view programmatically as being simply different aspects of the same feature, much more efficiently coded together), the feature request becomes more popular and therefore more likely to get on the schedule. Even as it is, I don't anticipate that happening in the near term.
In my personal opinion, this functionality overall is a valuable and useful idea, so I'd like to see it available sooner than later. It's just in competition with a great many other feature requests, internally and externally, that are also valuable and in-demand.
Sorry Ken, but I disagree with your contention about photos being swapped in and out of the active set being inherent to which ones get sent to a channel. In a global perspective it may be, and I understand why you say this, but that isn't the point.
1st Feature: Store and swap photos in and out of the active set, which appears on own site and gets sent to all channels.
2nd Feature: Have photos added to and removed from active set on a schedule.
3rd Feature: Have photos tagged by channel to control which 'set' or subset of the main currently active set gets sent to a particular channel.
The first is inherent within the second, and the third feature would inherently cover the first. BUT... combining them together, makes them (I suspect) a bigger project, and more difficult to do. And this being the case, the likelihood of the first feature NOT being introduced (being delayed or simply taking longer) because its been linked to also only being able to provide the 2nd or 3rd feature, becomes much more likely.
Personally, and I suspect for many other users as well, I would prefer to see the first feature introduced as soon as possible, without the second feature (and/or the third) holding it up because doing so has made it a much larger developmental chore. (This also means combining features which I also suspect are of less value to most users.)
I also think that as far as the forum and feature votes go, most users would't be looking to control which photos get sent to each channel (and thus wouldn't search for that) nearly as much as would simply want to be able to store and swap photos in and out of the main set. That being the case, you'll likely find yourself with additional feature request threads being started all over again.
The other requests are not all duplicates of this one... Baby steps.
"The more they over-tink the plumbing, the easier it is to stop up the drain." Scotty, Star Trek III
the ability to swap photos in and out of the active set is ALSO a different feature than being able to have it done automatically on a schedule.
Well, yes, those are indeed two separate features.
The ability to swap photos in and out of the active set, for each channel as well as for the website, is inherently part of this feature request, as I mentioned.
To have that done automatically on a schedule, is NOT part of this specific feature request - it's the other one I linked to.
I realize we're on the wrong thread for this part of the discussion, but the ability to swap photos in and out of the active set is ALSO a different feature than being able to have it done automatically on a schedule.
Swapping stored photos in and out of the active set (which I would only need to do manually) is one feature.
Having it done automatically according to a preset schedule is an additional feature that only becomes relevant once the swap feature is available.
I wouldn't want the scheduling facility to hold up introducing the ability to simply just swap photos in and out of the active set, hence my mentioning the distinction.
