Feature Requests

Sort by

• Newest Reply
• Newest Topic

I agree and would also state that this should probably be a priority because Hosts could conceivably have somebody book at 11PM and all the hassle that might come from that. I forgot to set that setting for AirBNB one time and had a guest book and check in right around midnight. Thankfully my automations worked and they managed to get their access, but that was not a good scenario for me. I'd rather be woken up or maybe even miss the booking than open myself up to being accused of not adequately providing entry.

Hey Alece,

We really appreciate the thoughtful feedback here, but I do want to be transparent about our reasoning for the 1,000-character limit, because you're right that it isn't purely about SMS.

The Broadcast tool is intentionally designed as a short-form messaging tool for getting a quick, focused point across to guests — not as a long-form communication channel. Even when sending via Airbnb or Vrbo (where the platforms themselves don't impose a similar cap), sending very lengthy broadcast messages can actually work against you. Platforms like those monitor for bulk messaging behavior, and unusually long messages sent to multiple guests at once can raise flags and potentially put your account at risk. As an integrator, that's something we also have to be mindful of on your behalf.

For situations like severe weather alerts, we'd actually recommend keeping the broadcast message short and action-focused — the key safety instruction or two — and then linking out to a fuller page (your website, a Google Doc, etc.) if guests need more detailed guidance. Something like: "Tornado warning in effect. Please shelter in the interior bathroom on the ground floor immediately. More details: [link]" gets the urgent point across well within 1,000 characters.

I just wanted to let y'all know I have created this tool and will be making it available soon. You can check it out on my website. Galvestonrents.com

For the current reports the only option is either to go into the pivot line item report in which you can select rent only which eliminates the service fee or booking summary which includes the service fee. The problem with the line item report is that you cannot prorate rent (so if you have a 3month booking there is no way to just get the revenue for that month). 

There has to be some way to be able to create an accurate report to see what revenue is, without Airbnb fees in it. 

Yes I believe you are correct. It’s why rental owners are going to Guesty. I like OR but I need 3 manual payment option without all the manual work around! 

Steve, thank you for these directions. I will try to set up this template.

Steve, Can you explain where this workaround of emailing a booking template is located in the new layout? 

In the meantime, I’d still recommend trying the workaround of emailing yourself a booking template and printing from your email. It accomplishes two helpful things. First, it gives you a clean, single-page printout without excess white space. Second, it creates a digital backup outside of OwnerRez, which can be useful if you ever need to reference it offline. For someone in your situation, where internet access is not always available, that can be a strong short-term solution while we continue evaluating layout refinements.

The one page printable overview was so easy and quick. Wish that was still an option or could be added "print overview". Not sure why that went away. The new layout is cumbersome with information spread all over the place.

Camelie, I was directed by the helpdesk to this page to make the same request. The previous one page overview was VERY quick and helpful having it all on one page. The new layout is too long and cumbersome! 

I agree!! Love the old format 

7 years on and it is still a manual process to split from 2 payments to three, am i right on this? 

Camelie, I was directed by the helpdesk to this page to make the same request. The previous one page overview was VERY quick and helpful having it all on one page. The new layout is too long and cumbersome! 

Hi Camelle,

Bri here from the Product team! Thanks so much for taking the time to submit this.

I do want to be upfront — reverting to the old overview page isn't something we're able to do, so we'll be declining this request as written. That said, we absolutely don't want you stuck with something that isn't working well for you!

There's already some community conversation happening around the new overview page here, as Robert pointed out: https://www.ownerrez.com/forums/general-help/the-new-booking-overview-page 

If there are specific things about the new view you'd like to see changed or improved, we'd love to hear them. A new Feature Request outlining those details would be the best path forward — that way it gets the proper visibility with our internal teams.

Thanks again!

Hey Alece,

We have a bug card open to address the fact that the second notification is no longer being sent for Airbnb bookings. I see you were also having some trouble with Vrbo a while back, but that was the result of something on their end that wasn't providing us with the details we needed in order to let that notification fly.

This sounds like a bug report rather than a feature request, but I'll mark the status Planned for now and check back in with you once the fix is out to make sure we've addressed the issue.

I'd like to request that the nightly rate exporting functionality be significantly upgraded.

Currently we can select properties, but not dates. This means a ton of extra work deleting 99% of the exported rows because in a typical case I have no need for all my historical rates in the export, nor all of those 2 years out.

Also, it's a royal pain that it uses OR's internal property ID number instead of the property name. I have to open up a new tab to my properties page so I can make any sense of the data I'm looking at.

This seems like it could potentially be accomplished if we were able to download our communication history. A full spreadsheet export would allow users to run a variety of reports or filter the data to meet their needs. 

https://www.ownerrez.com/forums/requests/downloading-communication-history 

Also, clearly Direct Booking Tools saw there was a value in this feature even though it "didn't get votes". 

We've received your feature request—thank you! If you think others would love this too, spread the word and invite them to upvote. Community feedback really helps us prioritize what to build next.

Can we please add back in the YOY with the red and green arrows to the owner portal.  I have had three owners complain that they can no longer easily see how they are doing.  They like the 24 month view, but it was great for visualization purposes to see the YOY view.    Thank you! 

Hello ~ I'd like a way to run a report showing specific information about responses. I see this as a training tool for my co-hosts and KPI tool for my company. 
I would like to be able to sort: 
1. Who Responded (host, specifically which co-host, or automated)
2. Day and time of response (working hours vs after hours/weekends)
3. % of responses/communications during business hours vs after business hours, per person or automation
4. Timeliness of response
5. any other items that you feel would be useful to help break down KPI's 
6. Historical data view over days, weeks, months, and years. (especially over a monthly timeline).
7. Retroactive to show the past few years from the inception of this report.

Per OwnerRez support, the expected flow for review notifications is:

• Initial notification when a guest submits their review

• A second/final notification when the review is published/live

This previously worked as expected, but stopped in late 2025. 

Current behavior:

• We do receive the initial notification when the guest submits their review (before it’s published, while our host review is still pending)

• We do not receive the second/final notification after we submit our host review and the guest review is published

Why this matters:

We rely on that final notification as our trigger to write a public response. Without it — and without the ability to filter reviews by “response not written” — it becomes much more cumbersome and time-consuming to track which reviews are actually live and ready for response.

Request:

Please restore the final “review published” notification behavior, or provide a configurable notification for when a review becomes publicly visible.

With Vrbo rolling out their new same-day booking feature, it appears that bookings may be allowed throughout the entire day of arrival. Based on what I’ve been told by support, Vrbo does not currently provide a way to set a cutoff time for same-day bookings the way Airbnb does.

For example, on Airbnb we can set a same-day booking cutoff (e.g., 6:00 PM). This is important because many hosts need time to prepare for last-minute guests, communicate check-in instructions, and coordinate things like security registration or access codes. In our case, we also stop monitoring messages after 10 PM, so very late same-day bookings would be difficult to accommodate.

Right now, it seems Vrbo could allow bookings until late in the evening (potentially even close to midnight) if the property is still showing as available. It would be very helpful if OwnerRez could provide a way to prevent same-day bookings after a certain time when Vrbo performs its last-minute availability check.

Possible solutions could include:
• A configurable same-day booking cutoff time for Vrbo (similar to Airbnb’s setting).
• Automatically marking the property unavailable after a specified hour on the day of arrival.
• A setting that disables same-day Vrbo bookings after a host-defined time.

This would help hosts who need a reasonable buffer to prepare for guests and avoid late-night bookings that cannot be properly supported.

If this is something other OwnerRez users would find helpful, please consider upvoting this request.

Thanks!

Great to hear, Bri!! And you know I'm always game for a beta-test!! 

Thanks for the clear explanation of the underlying logic, Steve — that helps clarify how the system is interpreting those values. Based on that explanation, I’ve added help text to the Status column title in my owner statements to provide some context for my owners.

For some additional context on why we need to use the Status column:

When a booking is canceled, the full number of nights from the original reservation still appears in the statement. The only way to indicate that the stay did not actually occur is through the Status column showing that the booking was canceled. That distinction is important for owners reviewing their statements. For example, an owner might see a booking that appears to span five nights, but only shows a small amount of revenue. Without the Status column indicating that it was canceled, it can look like the booking somehow generated unusually low income.

It’s already confusing that canceled bookings still (incorrectly) contribute to the occupied night totals on both the Owner Statements and the tax reports, so having the Status column helps provide at least some context for owners when reviewing those numbers.

At the moment, there isn’t another way on the Owner Statement to clearly signal that a booking was canceled. If there were a separate method to indicate a canceled booking, that would remove our need to rely on Status for that clarification.

While attempting to use the Broadcast feature last night during a tornado warning, I ran into another limitation that made it difficult to quickly send an important message to current guests.

I maintain a number of pre-written message templates for situations like severe weather, freezing conditions, and other safety alerts. Since Broadcast currently does not allow selecting templates directly (I posted a separate feature request about that here), I opened my saved template and copied the message body to paste into the Broadcast editor.

However, after pasting the message, the system displayed a warning that the message exceeded the 1000 character limit, which prevented the message from being sent.

The issue is that Airbnb and Vrbo messages themselves do not have a 1000-character limit, so this restriction prevents us from sending the same templated messages we normally use with guests. The majority of our templated messages exceed 1000 characters and send without any problems. (In this case, I went back to my manual method of sending the templated email and channel message to each current guest and all messages sent just fine.)

Please remove the 1000-character limit on Broadcast messages, or increase it significantly so it better aligns with the messaging limits of Airbnb and Vrbo.

(If the limit exists because of SMS compatibility, the limit should only apply when “Send additional copy via SMS” is enabled, not when sending via channel or email.)

I recently discovered that when using the Create Quote process, selecting a source (such as Airbnb or Vrbo) does not include the channel rate adjustment markup in the generated quote.

I often create quotes when a guest asks about extending their stay so I can quickly see the nightly rate. I had always assumed that selecting Airbnb or Vrbo as the source would apply the corresponding channel rate adjustment to the quote. However, after noticing a discrepancy and contacting support, I was told:

“The Quote creation process will not include any channel markups, as Airbnb and Vrbo follow their own quote processes.”

This was surprising, because the ability to select a source during quote creation strongly implies that the quote would reflect the pricing structure for that channel.

Please allow quotes to automatically include any applicable channel rate adjustments when a source (e.g., Airbnb or Vrbo) is selected. This would allow hosts to generate accurate channel-specific quotes and quickly evaluate pricing scenarios such as reservation extensions.

I agree completely. I looked at the Direct Booking Tools and it was very expensive (IMO) -- this seems like straightforward functionality OR could add to their widget!

I don't see the need to wait to leave a review on ownerrez until the platform authorizes it to. I currently want to review a guest for checking out leaving a filthy apartment and for some reason I can't record the review until airbnb authorizes us to. When guests are rude, or refuse to pay their check-in fee it's the same thing. We should be able to pre-review them so we don't forget. I manage too many properties to be remembering what each guest did when I could be marking them down right away.

We should be able to pre-store them on OwnerRez and then whenever the platform allows, for the review to be sent.

Would like to request that the last minute and early bird discounts be added to the channel specific discounts section for VRBO to avoid stacking with the mobile promotion and one key promotion. Literature I have read says it does not stack however I am not finding that to be correct. Given how important offering these discount are to your listing visibility it would be great if this could be implemented.

1. Summary of Concern

When a property is configured as entire home / whole‑house use, the bathroom privacy selector still displays the options “Private” and “Shared.” In this context, the terminology is misleading because “Shared” appears to mean shared within the rental (e.g., not ensuite), rather than shared with another unit or booking. This misinterpretation can cause hosts to incorrectly classify bathrooms.

This defect has real guest‑facing consequences. After marking a hallway half‑bath as “Shared,” I began receiving multiple guest inquiries expressing concern that the bathroom was public or shared with strangers. Because the configuration had been set years earlier, I did not immediately understand why this concern was suddenly appearing. After the third inquiry in four months, I investigated and discovered that the terminology in the interface was driving the confusion.

2. Steps to Reproduce

1. Configure a property as entire home / whole property use.
2. Navigate to Property → Rooms → Bathrooms.
3. Edit or add a bathroom.
4. Observe the Private / Shared privacy selector.
5. Note that the system provides no contextual clarification that “Shared” refers to sharing with another unit or booking, not sharing among guests within the same rental.

3. Actual Behavior

• The system displays Private and Shared options even when the property is already defined as a whole‑house rental.
• Users reasonably interpret “Shared” to mean “not ensuite” or “shared among guests staying in the home.”
• This leads to incorrect configuration and guest confusion.
• The UI contradicts the property‑level setting of “whole‑house use.”

4. Expected Behavior

One of the following should occur:

Option A: Context‑Aware UI Suppression

If the property is configured as entire home, the Private/Shared field should be hidden because “Shared” with another booking is not possible.

Option B: Clarifying UI Guidance

If the field must remain visible, a tooltip or inline note should clearly define:

• Private = exclusive to this rental unit
• Shared = shared with another rental unit or booking, not shared among guests within the same party

5. Impact

• The misleading terminology may cause hosts to incorrectly classify bathrooms as “shared” when the property is configured for whole‑house use.
• This results in guest confusion, including concerns that a bathroom is public or shared with strangers.
• In my case, marking a hallway half‑bath as “shared” triggered multiple guest inquiries over several months, all asking whether the bathroom was communal.
• The issue required investigation to identify the UI terminology as the root cause.
• The defect is a legacy carryover from earlier interface versions and persists after the redesign.

6. Conclusion

This is a terminology/UX defect: the bathroom privacy field presents misleading options when whole‑house use is already defined. The system should either suppress the field or provide clear contextual guidance to prevent incorrect configuration and guest confusion.

Thank you for reviewing this issue.

This one is not a feature request, it is an existing error.

1. Summary of Error

The Room Description field displays a 60‑character limit, and the interface actively counts characters up to 60. However, the system rejects input longer than 40 characters, indicating that the actual enforced limit is 40, not 60. This discrepancy causes user confusion and prevents accurate data entry.

2. Steps to Reproduce

1. Navigate to Property → Rooms → Edit Room (example: Bathroom).
2. Locate the Room Description field.
3. Observe the on‑screen note indicating a 60‑character limit.
4. Enter text between 41 and 60 characters.
5. Attempt to save.

3. Actual Behavior

• The system blocks saving when the description exceeds 40 characters.
• The user receives no clear indication that the true limit is 40.
• The character counter and instructional text continue to show 60 characters, creating a mismatch between UI guidance and system validation.

4. Expected Behavior

One of the following should be true:

• Option A: The Room Description field should accept up to 60 characters, consistent with the UI message and character counter.
  OR
• Option B: The UI should be corrected to display a 40‑character limit if that is the intended system constraint.

5. Impact

• Users waste time troubleshooting why valid text is being rejected.
• Users incorrectly assume the issue is caused by special characters, spacing, or formatting.
• The mismatch creates unnecessary friction and undermines confidence in the interface.
• The limitation is especially confusing because the Room Description field does not appear to sync to external platforms, making the strict limit unnecessary.

6. Conclusion

This is a UI/validation defect: the displayed character limit (60) does not match the enforced character limit (40). The system should either update the UI to reflect the correct limit or update the validation logic to match the stated 60‑character capacity.

Thank you for reviewing this issue.

Summary

The current guest information interface uses inconsistent iconography and placement for editing guest details. Specifically, the pencil icon in the Overview section appears to be the logical entry point for editing guest information, but it is non‑functional. Instead, users must locate the hidden “…” menu under Contact Info to access the actual edit controls. This creates confusion and reduces usability.

Problem Statement

When attempting to edit guest information:

• The pencil icon in the Overview section appears to be the correct control but does not open guest information editing.
• The actual edit function is hidden behind a three‑dot (…) menu under Contact Info, which is not intuitive.
• This inconsistency forces users to search for the correct entry point and increases the likelihood of user error.
• The iconography does not match established UI patterns elsewhere in OwnerRez, where a pencil icon reliably indicates an editable field.

This results in unnecessary friction and slows down routine guest‑data updates.

Requested Modifications

    Standardize Edit Icon Behavior

Ensure that the pencil icon in the Overview section either:

• Opens the guest information editing panel, or
• Is replaced with a more accurate icon if it is not intended to be an edit control.

   Improve Discoverability of Guest Editing Controls

Replace or supplement the hidden “…” menu with:

• A visible pencil icon, consistent with other editable fields, and
• A secondary gear/settings icon for less common or advanced actions.

   Align Iconography Across the Interface

Use consistent visual patterns for:

• Editing guest information
• Accessing advanced or secondary options
• Distinguishing between primary and secondary actions

This will reduce confusion and improve user efficiency.

Closing

Standardizing the edit icon behavior and improving the discoverability of guest‑editing controls will streamline user workflows, reduce confusion, and align the interface with established OwnerRez UI conventions.

Thank you for your consideration.