I can have specific legal agreements sent to guests based on what property or listing site they booked on. But I need to do so based on at least one other condition as well.
This is whether they are a repeat guest, which I have such guests tagged as. In that case, I would hve them sent an agreement to sign that does not require them to upload their ID.
This is already planned for the future, but no ETA. Upcoming work on the guest portal will be the foundation for adding this capability.
What is the status of this now, after a year and a half?
I'd love a rental agreement condition based on length of stay so that longer term stays (30+ nights) automatically receive the longer stay rental agreement to sign!
This promised feature is so basic and essential, I’m not understanding why no action is being taken on it nor why no reply is provided to request for its status.
Hi Scott and Alece,
Thanks for raising this again, and I’m sorry this thread didn’t get a more direct status update sooner. I understand why this feels like a basic, must-have workflow, especially when you’re trying to apply different agreements based on guest type or stay length.
At the moment, OwnerRez can only assign different legal agreements based on property and listing site. We don’t yet have a built-in way to automatically choose an agreement based on additional conditions like repeat guest or length of stay (30+ nights).
That said, I will be bringing this back up with our Product team for review and prioritization.
One relevant piece of context is that we’re currently in the middle of developing a Guest Portal, which will allow guests to access a link where they can make changes to their reservation, and eventually even communicate for direct bookings similar to channel bookings. Once that foundation is in place, it opens the door for cleaner, more integrated workflows like conditional agreements.
I don’t have a specific ETA I can share today, but I did want to confirm you’ve been heard.
Workaround available today (conditional agreements via Tags + Triggers)
In the meantime, there is a way to send different agreement links today using a combination of:
Tags (ex: “Returning Guest”, “30+ Night Stay”)
Different Templates that reference different agreements using the BULEASE field code
Triggers that send the appropriate template based on the tag/condition
I recorded a quick walkthrough here that shows the setup:
Enhancing Rental Agreements for Different Stay Lengths - Watch Video
Important note on the Photo ID requirement (separate limitation)
Scott, in your original example you mentioned wanting repeat guests to skip the Photo ID upload, while new guests still must upload it.
That specific part is slightly different than choosing between agreements, because the Photo ID requirement is controlled by a Custom Field. Right now, Custom Fields cannot be applied conditionally, so if the field is required, it will be required for all bookings using that agreement.
I see you already commented on a separate thread about this. That is the right place for that request (and I’d encourage an upvote if you haven’t already):
https://www.ownerrez.com/forums/requests/option-to-remove-collect-photo-id-in-rental-agreement#80418
Thanks again for the persistence here. I know it’s important, and I’ll make sure it gets visibility internally especially to consider as additional features as they work on the new Guest Portal
-Steve
Thank you, Steve. I appreciate hearing your input on this -- including the current workarounds available.
Thanks, Steven.
The big thing for me is having different custom fields for my repeat guests when they book so that they don't have to submit their IDs every time. I don't see this being addressed as a fundamental need.
Hi Scott,
Totally fair point, and I hear you.
There are definitely a lot of moving parts on our side, and at some point Product has to prioritize based on demand and impact. You have been here long enough to remember when we didn't even have a Guest ID Upload function!
For some visibility, the Photo ID conditional/custom field request is currently sitting at 3 votes, and this agreement-conditions thread is at 7. I know votes aren’t the only factor, but they do influence what rises to the top.
In a perfect world, we’d ship everyone’s “this would make my life easier” feature immediately… but then none of us would ever sleep again. 🙂
That said, I’m always about finding a practical path forward.
Just playing devil’s advocate for a second (because it helps sanity check the workflow): As the host, is there a reason you wouldn’t want an updated ID from a repeat guest occasionally? IDs expire, addresses change, and if you’re using this as a protection layer for yourself, having the most recent one isn’t the worst thing in the world.
Also, “repeat guest” in our systems is basically “same email address”. Guests are not logging in to authenticate that it is indeed the same guest. So if someone uses a shared email, a spouse books, or a friend books on their behalf, it might look like the “same guest,” even though it’s not. The ID requirement is really there to protect you, not just to annoy the guest (even though I know it feels that way).
Now, that doesn’t change your point: it is friction, and friction costs bookings.
A workable workaround (until we can do this properly)
I took a look at your current ID Upload Custom Field description:
“As described in the listing, please upload a copy of your government-issued photo ID (e.g., drivers license, passport).”
You could tweak that to give repeat guests an easy out without breaking the workflow, add something like:
If you’re one of our awesome repeat guests, welcome back!
Our system still requires a photo upload to continue, but you can upload any image (a screenshot, a selfie, or your favorite pet photo works great).
That way:
New guests still upload their ID like normal
Repeat guests don’t have to dig out their wallet and re-take the same picture
You still satisfy the “required field” so they can proceed
And if anyone messages you with “don’t you already have this?”, you can always respond with:
“Yep, you’re not wrong. The system is being a little dramatic, just upload a pic of your favorite cat and you’re good to go.” 😄
Not perfect, but it removes the biggest pain point while we push for a real conditional-field solution.
I sincerely help this gives you some ideas on how you can work around this limitation until we can better implement a solution.
Thanks for your reply and ideas, Steven.
I run a really small one-man operation, and I have a personal connection with my repeat guests. So I have no worry that someone would be impersonating them.
A common instance is when guests extend their stays and they sign a new agreement to reflect that.
I do tell them they can upload any pic, but I'd be hesitant to write that in the instructions so that new guests booking for the first time upload something other than their IDs, which I've had happen, anyway.
