Hi everyone,
With the new My Stay form in place, and that being the first step in the direction of a fully formed guest portal, I'm going to mark this request as released.
There's a lot of great discussion in this thread about what a more full-featured portal could look like. Those are all valuable ideas, but they're distinct enough in scope and design that we want to track demand for each one individually rather than lumping them all under one general "portal" request. That helps us see where the real demand is concentrated so we can weigh that next to what we already have on the roadmap and prioritize what to build next.
So if you're looking for one of those specific concepts, take a look through the Feature Requests forum for an existing thread on it and add your vote - or if one doesn't exist yet, feel free to start one. That's the best way to make sure it gets on our radar and gets weighed against everything else in the queue.
Thanks for all the input here! This thread genuinely helped shape where we're headed with My Stay and the portal experience.
I don't want guests to have a login per say... I think we live in a world with username + password overload. I would like a place where a guest can lookup their booking via booking ID and last name. Similar to an airline reservation. If I was to give guests the ability to create a username and password for my personal website, there would additionally need to be options like "login with my google account" etc etc. Which is a much heavier lift security + API wise. Let's keep it simple.
I don't want guests to have a login per say... I think we live in a world with username + password overload. I would like a place where a guest can lookup their booking via booking ID and last name. Similar to an airline reservation. If I was to give guests the ability to create a username and password for my personal website, there would additionally need to be options like "login with my google account" etc etc. Which is a much heavier lift security + API wise. Let's keep it simple.
Yes! That’s a much better idea. There could simply be a button on our hosted website or personal website where guests could search by their ORB number for their booking details. I continue to have guests asking for total cost, check-in and check-out times, etc.
I don't want guests to have a login per say... I think we live in a world with username + password overload. I would like a place where a guest can lookup their booking via booking ID and last name. Similar to an airline reservation. If I was to give guests the ability to create a username and password for my personal website, there would additionally need to be options like "login with my google account" etc etc. Which is a much heavier lift security + API wise. Let's keep it simple.
With respect, I don't agree with this sentiment. Or the idea of a guest being able to see a portal simply with a booking number.
A guest's travel plans are a private thing, and for security's sake should not be publicly available without a secure login. Although I understand and agree with the sentiment of there being too many requests/demands for logins online generally speaking, I genuinely believe this is not one of those times – the situation actually does call for a secure login. With browsers ability to hide and store logins, it hardly presents an inconvenience at this time.
I also don't see the need for 'login with my XXX account' functionality, which personally, I never use. I don't want any of those mass data aggregators collecting any more info on me than possible. Give me my own login and password any day please.
When the guest logs in to the guest portal, they won't be logging into my website, they will be logging into OwnerRez, with their own sub-account, in a manner similar to how my PM or cleaner may do so now. A portal won't require any more work or maintenance on the owner/host side of things except for setup. And that's from fifteen years of experience with a great guest portal in my old PMS.
I very much hope that OR will spend some serious time asking their customer/users what they want to see and have in this important component of the software, and testing it for features and usability. Sadly it seems that a number of OR features or updates have been released lately that are 'half-baked' with obvious design/UI flaws that simply should never happen. (And which haven't been corrected quickly either!)
Additional Feature Ideas:
1) In conjunction with the custom data and input requests being discussed in this forum (yes/no restrictions, radio buttons, drop down menus, text formats; date only, etc.) it would be REALLY great (and should be a prerequisite for its design) that the Guest Portal be something that the USER can 'control' in terms of its content and appearance beyond the basics. The OR user should be able to add specific PAGES to the portal, which they can name and would appear in a menu across the top, and then include whatever information they wish to, using a simple html editor, including links, images, and all of the OR Field Codes and Custom Fields (with the aforementioned Custom Input Controls).
2) If would be freaking AWESOME if after the design of the guest portal, which could be viewed on OR's servers, OR users could also then incorporate the entire portal into their own website using a Widget, just like we do with quote and inquiry forms today. It should still require input of a username and password prior to becoming visible, but if it could be incorporated into the host's own website this would go a long way to helping hosts build their individual businesses, while OR helps them with the management of it.
If there is a list being kept somewhere, I absolutely volunteer to assist in the design/testing/creation of this feature. Please give us what we need and want, not what you think we should have.
Logins... what a conundrum... how are they created, where are they stored, how are passwords reset, two factor authentication, etc. etc. etc...
I believe with enough pieces of information similar to what airline and cruise companies do with booking information... that not having an additional login is a good thing. If I can use my ORB number and a last name, that would seem adequate in locating and confirming who I am. The odds of someone knowing my ORB# and the booking last name are pretty slim. Passwords, just like installed apps are a reason to keep guests from actually using what you are trying to provide to them. Another option might be a link that is sent to the booking guest via SMS, email, OTA messaging... that has the URL with a "hash" of some kind at the end that gets them to their specific booking portal page. (ie something like: portal.orez.com/?token=3444fcf6a9fd574283e7897b1fb737e539be212acb7873126c1c267d3766aebf)
I for one do not want to have to manage thousands and thousands of "logins" a year for guest bookings.
Regarding what should be there...booking information is important...arrival date, checkin time, departure date, checkout time, number of adults, children and pets, door lock code(s), etc... and it is often a component that is missing or sparsely populated from the 3rd party apps today... upsells... OR puts these on the website as optional surcharges... but not all guests go through the website so allow them to purchase them here... (this captures the OTA guests) and if there is not enough customer information to process the card you also get an opportunity to capture their name, address, email, phone, etc... to add to the booking/guest information. 3rd party apps are plenty to look at things that are needed in a guest portal...we like not only property specific "guidebook" type items... how to use the tv, internet information, house rules, checkout instructions, etc... but that initial impressions survey... is important... we capture the first time their code is used in the lock and can trigger based on that information a welcome message... do the same in the portal...as soon as they checkin have the main portal screen have the initial impression survey popup... get ahead of the 5 star review. Area information with user defined categories... Things to Do, Hikes, Day Trips, Coffee Shops, Taverns/Bars, Restaurants, Local Insider Info, etc etc etc... and as stated above we should be able to use Rich HTML, ... The portal should know where they are in their stay and change the home page accordingly... pre arrival might be trip planning information and include things like what the weather is like when they are scheduled to be here... a day or two before driving directions become important and door access codes, pictures or the house or parking situation, etc... Checkin would be the survey, house information, etc... and as you get to the end of the stay the home screen is checkout related.. with checkout times, reminders to gather up their stuff, checkout instruction, maybe a checkout button to notify you they are gone (turno does this... we do it with our locks but a way to get the housekeeping started as early as possible) post stay the portal drops the booking information and becomes a rebooking tool... plan next visit... links to the website for booking, discount codes or whatever... post stay survey... The point is it should be dynamic and know where they are in their stay and serve up relevant information on the main screen but have all of the information available via navigation.
Logins... what a conundrum... how are they created, where are they stored, how are passwords reset, two factor authentication, etc. etc. etc...
I believe with enough pieces of information similar to what airline and cruise companies do with booking information... that not having an additional login is a good thing. If I can use my ORB number and a last name, that would seem adequate in locating and confirming who I am. The odds of someone knowing my ORB# and the booking last name are pretty slim.
by PacViewLodging – Jun 9, 2026 11:16 PM (UTC)
I don't understand your comment regarding airlines and cruise companies. My airline certainly uses a password and login, and they also insist on 2-Factor Authentication (sending an email with a secondary access code) to login, every single time.
Generally speaking, I agree with you, however I also have no problem with logins or passwords. I use a secure password manager, and the vast majority of my logins are stored within my browser and I never need to look them up, they are automatically entered when I go to a page, as long as I am on one of my trusted devices, so it really is no inconvenience at all.
Passwords, just like installed apps are a reason to keep guests from actually using what you are trying to provide to them.
One can theorize about this all one wants, but in actual practice, with 15 years of live actual experience, having a user name (the guest's email) and a password in order to access our guest portal was never a problem. We never had a single guest complain or express that it was an inconvenience, difficult to use, or anything else negative about it.
Another option might be a link that is sent to the booking guest via SMS, email, OTA messaging... that has the URL with a "hash" of some kind at the end that gets them to their specific booking portal page. (ie something like: portal.orez.com/?token=3444fcf6a9fd574283e7897b1fb737e539be212acb7873126c1c267d3766aebf)
That's fine, but it only works for the time when the email is sent and the guest logs in. It won't help them when they go back to portal page and try to log in, or share it with another member of their party, etc.
I for one do not want to have to manage thousands and thousands of "logins" a year for guest bookings.
You're either not paying attention, or misunderstanding. You as a user of OwnerRez would not have to manage anything. The passwords and logins would be issued to the guest by OwnerRez, with included automatic links included if they are having trouble logging in, need to reset their password, etc.
The guests are not logging into your site, and you don't have to manage anything. They would be logging into a server belonging to OwnerRez. There is nothing for you to manage. Again, this is 15 years of experience talking. I think in that whole entire time, we had a request from a guest who was having an issue with a login twice... in fifteen years(!), and our response was simply to forward it to our PMS provider, who simply sent the same form email for dealing with login issues to the guest, and that was the end of it.
In actual practice this was never a problem.
Another additional Feature Idea:
Have a second set of login credentials that the lead guest can share with other members of their party, so they can decide who and if they want to share it with other people in their group.
The second login would give access to all of the information except for financial, and not allow changes to be made to the booking, only display information, so details can be shared, but the responsible booking party remains in control of the reservation.
100% agree with no password needed. Just booking ID and last name.
As I said, I have no real problem with just a name and a booking number, I'm just not sure it's the correct way to go. Even the example shown, of Delta, which I have used many times, has a login (it's in the upper right of the page) requiring a user ID (SkyMiles Number) and a password. I can do a lot more on the Delta site when logged in than I can from just a booking/reservation number, including make new bookings.
In my previous PMS, the Guest Portal had a page called 'My Trips' or 'My Stays', which presented a list of all bookings the guest had made, past present and future, and you could click on a booking and the details of each trip would be displayed. I had more than a few guests comment that they liked looking through the history of their stays with us. I would think that would require something more than just a single Booking ID which only identifies the booking.
I suspect the airlines allow getting to a reservation with a name and booking ID to keep it simple for when people are travelling. Who knows? It may be that access will only be granted on that basis if there is a pre-existing cookie on the device, assuring the airline that you are who you claim to be. (If the cookie isn't present, it would ask for a full login before granting you access to the reservation. In most cases, the guest would get access to the booking from just their name and booking number (they originally booked it after all) and never see or be aware of this.)
I'm not against basing portal access on a name and booking ID number only, but I'm also not against having a user ID and password.
Given the nature of data security and increasing requirements for privacy and protection of data, for many sites and situations, even a user name and password are not enough – 2-Factor Authentication is required. (Even OwnerRez requires this of us when logging in on a new device or from a different ID.)
Do any of us want to take on the legal liability of implementing a guest portal without the utmost in online security for it? Is it reasonable for us to expect OwnerRez to provide a Guest Portal without doing so? Personally, I wouldn't.
If the guest finds it a hassle and chooses not to use a portal because of a login requirement, so be it. It's not like we're providing this for them now anyway.
If the user name is the guest email address, it does not become another piece of information to store and manage anyway.
Some may prefer to not have 'another' user name and password. I have no problem with it.
Yes, yes! Agreed 100% with the Delta idea. Can't wait to see it. I frequently get asked questions like: "What do I owe yet?" "How much did I put down?" Etc. Etc.
Another additional Feature Idea:
If we do end up having a Guest Portal, and it includes a secure login as part of its operation, and it provides access to the guest's history with us...
It would be really great and cool if there were GUEST LOYALTY FEATURES built into it!
For example, if we could have some system for awarding guests points for stays, and other activity, like leaving reviews or making referrals. And have a system for administering and providing rewards for guests; swag, discounts, free nights, optional extras like pool heating, etc.
And the guests could LOGIN and see their point total and see what rewards are available to them, and use them (if appropriate) when booking!
Robert the issue is use... My goal for the portal is to get every guest using it... It means less that we have to respond to via the phone, sms, email, etc... If they have all of the information at their fingertips... and we all know that we now carry these phones everywhere we go... why not make it easy for them?
We use guidebooks/portals today... we have for years... the ones that required a log in or a download of an app to their phone just didnt get used as much. We may not have it in OwnerRez but there are currently a dozen or more "portals" on the integration page - https://www.ownerrez.com/support/articles/integrations-guest-communication-overview. Is there an advantage to getting one into OwnerRez... if for no other reason than self service reservation activity... changing dates, adding dates, cancellations, upsells.
I am sure OwnerRez dev will look at the options that provide the best that they can offer as it relates to their platform, security, speed, etc... and just like with all of the dozens of other integrations you will be able to choose whether you want to use it or not. Login or no login... would be something I would certainly have to look at long and hard to decide if I wanted to implement that guest "solution". That's the complexity of this industry... we all do it our own way... and OwnerRez gets to try to figure out what the majority would like and see if they can make that work...
Another additional Feature Idea:
If we do end up having a Guest Portal, and it includes a secure login as part of its operation, and it provides access to the guest's history with us...
It would be really great and cool if there were GUEST LOYALTY FEATURES built into it!
For example, if we could have some system for awarding guests points for stays, and other activity, like leaving reviews or making referrals. And have a system for administering and providing rewards for guests; swag, discounts, free nights, optional extras like pool heating, etc.
And the guests could LOGIN and see their point total and see what rewards are available to them, and use them (if appropriate) when booking!
Love this idea!!!
We recently rolled out the first step of our new My Stay experience - giving guests one place to confirm their contact info, sign the Rental Agreement, authorize Security Deposits, and add Travel Insurance if they want it. Here's the overview!
But this is really just the foundation. We're building My Stay into a true one-stop hub for the guest journey. Here's a look at what's on the roadmap right now:
We don't have firm timelines or final designs yet, and some of these ideas may evolve as we build them out. But we wanted you to know where we're headed and that the current form is just step one. We'll keep sharing updates here as things progress. Let us know in the comments what you're most excited about!
Hi everyone,
With the new My Stay form in place, and that being the first step in the direction of a fully formed guest portal, I'm going to mark this request as released.
There's a lot of great discussion in this thread about what a more full-featured portal could look like. Those are all valuable ideas, but they're distinct enough in scope and design that we want to track demand for each one individually rather than lumping them all under one general "portal" request. That helps us see where the real demand is concentrated so we can weigh that next to what we already have on the roadmap and prioritize what to build next.
So if you're looking for one of those specific concepts, take a look through the Feature Requests forum for an existing thread on it and add your vote - or if one doesn't exist yet, feel free to start one. That's the best way to make sure it gets on our radar and gets weighed against everything else in the queue.
Thanks for all the input here! This thread genuinely helped shape where we're headed with My Stay and the portal experience.
