Feature Requests

Sort by

• Newest Reply
• Newest Topic

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.

1. Summary

Recent updates to the OwnerRez guest communication interface removed the ability to (1) access SMS templates when initiating an SMS from the guest screen and (2) toggle between Email and SMS when composing a message. These changes disrupt established workflows and reduce communication efficiency.

2. Problem Statement

The guest communication panel now treats Email and SMS as isolated actions. As a result:

• Selecting SMS from the guest screen opens a basic message window with no SMS template access.
• Selecting Email provides no option to switch to SMS, despite this capability existing in previous versions and still appearing in some areas of the system.
• The consolidated guest screen makes it difficult to reach any interface that supports both SMS sending and SMS template selection.

This creates unnecessary friction and prevents users from leveraging standardized, template‑based communication.

3. Requested Modifications

3.1 Enable SMS Templates When Initiating SMS

When the user clicks SMS from the guest screen, the system should provide access to SMS templates, consistent with how email templates are handled.

3.2 Add Email ↔ SMS Toggle

When composing a message from the guest screen, the interface should allow switching between Email and SMS without leaving the screen. Message content should persist when switching channels.

3.3 Unified Communication Behavior

The guest communication panel should function as a unified messaging interface where both Email and SMS are always available communication modes.

4. Closing

Restoring SMS template access and reintroducing the Email/SMS toggle will streamline communication workflows, reduce manual effort, and align the interface with prior functionality and user expectations.

Thank you for your consideration.

Summary:
OwnerRez currently allows tags to be used as conditions, but there is no event‑based trigger for when a tag is added or removed from a booking. This removes the ability to use a tag as a simple binary switch to kick off a ton of downstream work.

Request:
Please add trigger events for:

• Booking is tagged
• Booking is untagged

Operational Need / Real Example:
Some booking channels do not provide guest email addresses at the time of reservation. Because of this, several automated messages fail to send at booking creation due to the missing email.

My intended workflow is:

1. When I later obtain and enter the correct email address, I add a tag such as Email Added.
2. Adding this tag should fire a trigger that sends the messages that were previously blocked due to the missing email.

Right now, because OwnerRez does not support “tag added” or “tag removed” as trigger events, there is no way to automate this recovery process. The system cannot detect the moment the tag changes, so the automation cannot run.

Why this matters:

• Many channels do not supply guest emails
• Messages that fail to send at booking time need a clean, automated recovery path
• A tag can be used as a simple switch (binary) to process a ton of work that depends on that state change
• Without tag‑change triggers, the workflow becomes fully manual
• Custom fields do not solve the issue because they also cannot fire triggers on change

Benefits to all users:

• Reliable automation for channels that do not supply guest emails
• Automatic recovery of failed or blocked messages
• More powerful and intuitive use of tags as operational state indicators
• Reduced manual work and fewer missed communications
• Aligns with how many PMS systems handle state‑based automation

Interim solution

For those interested in this concept, I'm using the following as an interim solution:

Since tag‑change events cannot currently fire triggers, I am using a custom field as a temporary state‑change mechanism.

Closing:
Adding “Booking is tagged” and “Booking is untagged” as trigger events would immediately solve these operational gaps and enable a powerful, flexible automation pattern for hosts.

Thank you for considering this enhancement.

[This topic has been merged with another topic (Order/hide or filter columns - LIST VIEW). All unique votes have also been merged.]

[Another topic was closed as a duplicate of this topic (Bookings>List view - Need the ability to resize, Filter, or a better scroll)]

Would be awesome if we could get an option to include a YTD Summary for owner statements to keep each owner in the know for their yearly progress! :) 

I'd like to request the ability to make pending bookings automatically confirm instead of automatically canceling.

Or perhaps this would be easier to do as a completely different feature instead. Here's my use-case/thought process: We have a LOT of guests cancel within just a day or two of their reservation (our assumption is that they're booking multiple properties to make sure they're held, then talking to friends/family to finalize details, then canceling all but one). When they use Airbnb, Airbnb covers all the credit card fees, so it's no problem. But if they book direct, that means we either have to charge them a cancelation fee or eat thousands a year in card fees. We're afraid that if we don't offer any window for free cancelations, lots of guests just won't risk it and won't book with us at all.

So the functionality I'm envisioning is this: Guest books on our platform. As part of checkout process they input their card info and the processor immediately verifies it. Guest immediately receive an email confirming their booking and saying they have 24 hours to cancel before there's a cancelation fee. BUT, their card isn't actually charged until that 24 hours expires, thus we have no fees to eat if they want to cancel.

Currently we can sort-of-kind-of do this with the Request-to-Book feature. However, guests will be reluctant to book with us if they can't be assured immediately that they're locked in. Furthermore, this would also require us to manually review every single booking (a ton of extra work for us). Almost certainly we'd miss one here and there and guests would be very upset that their booking got canceled for no good reason.

I offer a small optional discount if the guest pays by check or Zelle. Security deposit is cc hold. Sometimes guests pay 1st payment by Zelle, then try to pay 2nd one by credit card (which they should not because they chose the optional discount, but they try). To prevent that, I can set a booking rule to only accept "custom payments" after the 1st payment. However, it also makes sec dep to be by custom payment (Zelle), which I do not want. Conversely, if I have "all available payment methods" on the booking rule, it will show all payment methods on the sec dep for the booking that was paid by Zelle or check - would rather not confuse the guest and have sec dep hold by cc only . 

Ability to differentiate the payment method applicable to the booking itself vs sec deps would be great. 

Hey Alece,

We hear you on the templates front. There's work happening in this area and it's something we're actively thinking through. We want to get it right rather than rush something out that doesn't fully deliver.

In the meantime, field codes are supported there, so you can at least build out your message with dynamic values and copy/paste from an external doc as a workaround.