Latest Activity...
We really need this! Team Access permissions would let us provide granular access where needed (e.g. Messaging is important in my case) rather than full admin access to everything, or ReadOnly access to everything. This would be very helpful.
Read-Only is an available option for Team Access: Staff users.
We do have a Daily Checkin Report:
https://app.ownerrez.com/reports/bookingstayday
That shows arrivals and departures.
As far as outstanding payments and unsigned RAs, we do not have a specific report for that, but, you can certainly get a list of them. Go to the main Bookings display, List view, and use Filters accordingly - you can specifically filter based on RA being signed or unsigned, payment status being paid in full, partially paid, etc., and many other similarly relevant booking parameters.
I could really use a dashboard that shows upcoming arrivals, departures, Renter's Agreements that weren't signed yet, outstanding payment requests, etc. Reports are a bit cumbersome for at-a-glance. And I haven't found a report that will show me outstanding payment requests and Renter Agreement's not signed.
This brings up a good point. It would be ideal if calendar notations could be marked so that they are public (anyone can see them) or private (only we do).
We also need to attach a pdf. We have guests who do not have the internet and cannot open the link.
A notation showing the "2024 Men's Final Four Basketball tournament" could help explain to travelers who are asking why rates seem high for this particular weekend, if the event shows on the calendar it would help close the sale, no?
Just as a follow-up to anyone reading this... We integrate with a number of third party device platforms that DO already support Yale Wifi and other Yale locks . RemoteLock and Jervis for instance. Just wanted to mention this in case others came by and though there was no support for Yale. There is support for them, just not with the OR direct-powered locks feature.
It would be nice to be able to enter custom text for blocked-off dates that would display on the calendar widget, so instead of visitors to the website seeing these dates as "Booked" or "Unavailable," we could enter unique custom text for each Blocked-Off calendar entry, such as, "Please call for availability," "Available for extended stay - call for details," or other things to that effect.
We often block off dates on our calendar to keep units available during our slow season for potential long-term stays. Currently, these blocked off dates appear on the calendar widget labeled as "Booked," just like our unavailable, booked cottages.
There may be other solutions, such as changing the minimum stay in various seasons, but I think this approach would be more flexible, and would prevent missed opportunities by communicating important information to potential guests simply and directly on the availability calendar.
Well... I gave it a good shot. At least I have a workable solution for my situation going forward. I wish you lots of luck with yours and hopefully a new feature will come out to provide what you need.
You've got my vote! :)
Sadly that wouldn't work as the booking field criteria is for the NEW booking. It's not referencing any previous departure associated with the guest, but the departure date of the new booking itself.
Could you not add to the trigger the requirement that the guest's departure date is more than two weeks previous? Only a previously stayed guest would have a departure date like that. A new one, or future booking, would not. (Their departure date would be later.) So create your template, assign the departure date criteria to it, and it will only go out to those guests who stayed with you before. New guests wouldn't get that email.
It would take a bit of testing to ensure it operates as desired, but you can create a very narrow departure date window so that the email would only go out for one particular booking, one that you have setup for the purpose, or your own booking, just to use as a test case. Once it is working as desired, remove the second date requirement, and the email should go out to just previous guests.
Let me know if you try this and how it goes.
Robert
That would work for the follow-up messages, yes. However the guest would have already received the primary initial correspondence (booking confirmation) same as they did on their first booking. And it necessitates that for each booking that comes in across all our properties, we have to manually check if they're a repeat guest and add the tag. not really plausible for us (maybe for others that would work). Again, looking for an in-system option to do this more fluidly. Appreciate the creative thoughts though!
So then when a guest books as a repeat, add a tag for that to their record. And have all of your templates duplicated as necessary to send out the 'repeat guest' version of your emails when the tag is present. And send out the 'normal' one when it is not.
You only have to tag the repeat guests when they book, as a repeat guest. That should be easily doable, no?
Or is the issue that you can send out the repeat guest version using a tag as I suggest, but that wouldn't stop the regular one from going out as well?
Let me think on this and try a couple of experiments, as I need to solve the same issue for my own situation. I'll get back to you...
I'm not trying to send out an email blast to previous guests. My goal is then when someone books another stay with us after having already been a guest, that our template messages sound more personable and warm and acknowledge the fact that they're returning guests. As it is now, they receive all the same standard messages as when they initially booked their first stay because there is no way to target them with a modified message via available filter criteria.
There was also a feature request about having tags automatically assigned when a booking is created, so this could solve the issue you are raising.
But you did bring it up, which leaves me confused. If you would have to tag every guest then why bother? Every guest is every guest, and they can be emailed without a tag.
Perhaps what you're really thinking of is those guests that have stayed with you a second time, making THEM a repeat guest. If that's the case, then would it really be that much work to tag those particular guests after their second stay? In my case it would only represent perhaps 5 - 10% of my guests. And those guests that have stayed more than once are certainly worth the effort.
I hope that makes sense... unless I'm missing something?
Robert -- Having to tag every guest after their stay is certainly an option, but it's a tedious step we would rather avoid!
Hi Alece,
Could you just not setup a tag for prior guests and assign it to every guest after their departure (after all, once a guest has stayed with you, any contact they have with you makes them a repeat guest) and then use the tag in your triggers to have a different version of your template sent out? You could have an 'original' version and a 'repeat guest' version of your templates, and which one gets sent by a trigger is determined by what tag has been applied to the guest? A new guest would not have the tag applied, and get the original email, the repeater would have the tag applied and get the repeat guest version.
I REALLY need this feature, or a different take on it.
It would be really great if our rate seasons could show on the calendar.
For example, I need to see when Easter is each year on the Calendar, along with my Easter season. In my old software I used to be able to just create a booking with a Pending status that didn't block the dates at all, and it would show up as a strip on the dates in a Ribbon calendar so I could easily see when each important Season started and stopped, and could mark specific local event days in the Calendar in the same way as well.
I would prefer to see the means to integrate separate form software into OwnerRez, such as things like Survey Monkey, or a terrific Survey Plugin I use on my WP site. It would be really neat to have the info from the form automatically populate on OR, so that triggers and other CRM matters could be taken into account.
Our guest exit surveys are far more detailed than any conventional review form. Our guests provide lots of information when we ask the right questions, and it’s information we want to know.
No review form I've ever seen asks the questions we seek answers to. It would be great if OR allowed much more flexibility and or integration in this area.
Google Vacation Rental users must use an OwnerRez hosted site for their "landing page" with Google.
*If you use an OwnerRez hosted site for your website, that happens automatically.
*If you use a custom site, you can still join the Beta (assuming the account setup passes our internal review), though you would need to pay to activate OwnerRez hosted sites to have that landing page. A subdomain of your custom site is created for a Google landing page. Once the OwnerRez global landing page is released, you will no longer need to use that hosted site feature.
Non-GVR guests will continue to use your existing website without changes.
Thanks for update on Google. I have my own website with widgets being used and have no plans to go to OR Hosted.
Am I understanding this correctly:
1. If I pay for hosted site, I can be part of the Beta.
2. I pay for it but I do not have to set up anything or use a OR hosted site....or are you saying I have to have a separate website (OR hosted) just for reservations?
Thanks
Shasta Lakeshore Retreat
Just voted myself, I'm glad its in the planning phase. Any updates on where this stands now, last OR member to respond to this feature request was Jul 11, 2023. Soft ETA would be much appreciated :D :D Happy New Year Everyone!
**Beta Test Status Update**
We are nearly done reviewing all accounts on the GVR API Beta Test waitlist. Accounts with concerning complexities have been escalated for a deeper dig into the discounts/surcharges/seasons to be sure pricing accuracy is not negatively impacted.
We are happy to welcome more users to the Beta test. If you've not yet signed up for the Beta waitlist, feel free to write in to Help@OwnerRez.com and include "Google Vacation Rental Beta" in your subject line.
Note that you will be required to subscribe to the OwnerRez Hosted Website premium feature, if you aren't already using that. We are continuing to work on improvements to the GVR integration to remove this requirement in the future. If you already have your own website that isn't an OwnerRez Hosted Website, you are not required to replace or disable it in any way - you just have to have an OwnerRez Hosted Website in addition, for the use of GVR.
Just voted for this today and I also see this article was updated 2 days ago.
https://www.ownerrez.com/support/articles/mid-long-term-stays
Hi Scott, Available and Unavailable in relation to Travel Insurance means that either the guests are still able to purchase travel insurance vs. Unavailable whereas the guest's booking no longer qualifies. There are specific eligibility rules on when travel insurance can be purchased (available) and when it would no longer be available for purchase (unavailable). We do have a great support document that you may find helpful: https://www.ownerrez.com/support/articles/offer-travel-insurance-email
Signal and Telegram too. I'm traveling in Mexico now and everyone uses WhatsApp. Having an SMS integration would be next to useless here. Increasingly I am also using WhatsApp for messaging people with Android phones (I have an iPhone), because otherwise there is no way to message them on my computer, I have to pull out my phone. I don't know if the world is standardizing on WhatsApp, but it's a much better candidate, and works better, than SMS.
YES!! Love that recommendation, Robert!
Thank you, Steven!!
Hi Ed,
I've struggled with this too. But now that I'm much more clear with my guests that they can purchase travel insurance in the event that they need to cancel, they know that the ball is in their court. I find that kind but firm communication is what wins the game. Guests who don't like my policies can book somewhere else. I don't need the headaches.
Perhaps the issue is that one should have the feature of being able to assign properties to groups, and custom fields can be set for groups, which when a new one is entered for a group, automatically overrides all of the custom field entries for each property in that group. In this way, custom fields can be assigned in bulk, and properties can be assigned to as many different groups as necessary, providing all of the flexibility one might need to do what you are requesting.
