New Wyndham Website (2020)

[bnoble]

Did this function exist on Voyager?

I believe so. As with @paxsarah i remember being able to select either from the current or the next UY as long as I was within tem months of the latter.

 

[bnoble]

This is now fixed and working foe me. I was able to deposit points to 2021. previously I was getting the same "Not enough points" error

I was trying to deposit to RCI, not internally to a future UY.

 

[comicbookman]

I was trying to deposit to RCI, not internally to a future UY.

Both were broken for me initially. The RCI deposit let me get to the last step (where I then aborted)

 

[Richelle]

Yes, and yes. Cache and history completely cleared on Safari, and as soon as I click on the Deposit Points button in the RCI panel. I have a chrome installation I rarely if ever use. I will check that too. (Edited to add: same result)

Does this happen on other devices? Do you have contracts with different use years?

 

[Richelle]

Both were broken for me initially. The RCI deposit let me get to the last step (where I then aborted)

Same here. Both Points deposit feature and deposit RCI gave me that message. They both work for me now. I did two test deposits into next year and verified they went through and that the points total updated on both years. I did one test deposit into RCI successfully.

 

[Sandi Bo]

It's a 15 minute timeout - the same timeout you see whenever clicking "book" that appears on the screen as a countdown indicator.

Is there any option to cancel an inprogress booking? Or once started we cannot cancel and start a new booking? Has anybody figured anything out on that (I think it's on the regression list, wondering if anyone figured anything out in this area that would be helpful or if our accounts are essentially in a 15 minute lock)?

 

[r4rab]

Ok; I got it to work using Chrome. Seems like Safari is an issue for this update.



You can find the availability calendar for a resort by going to the resort page; there should be a button where it used to ask you to enter dates to check for availability.

Thanks! Yesterday I was not seeing the button but this morning I am. In the same location I had a notification box that I was ineligible to book the selected resort (even though I had previously stayed there).

 

[HitchHiker71]

Is there any option to cancel an inprogress booking? Or once started we cannot cancel and start a new booking? Has anybody figured anything out on that (I think it's on the regression list, wondering if anyone figured anything out in this area that would be helpful or if our accounts are essentially in a 15 minute lock)?

You're correct it is on our regression list as item #4, fix estimated for June release. I know Wyndham has been working on this item back a browser "back button" approach - but I would prefer a "Cancel" button that appears somewhere as opposed to using the back button. The back button on my iPhone does now appear to work - whereas before it did not. I will keep this on our list and hold out for an actual "cancel" button.

 

[HitchHiker71]

I believe so. As with @paxsarah i remember being able to select either from the current or the next UY as long as I was within tem months of the latter.

In either case if this is allowable via the program rules then we can input an enhancement specifically for RCI deposits. I will add this to our list.

 

[Manzana]

Is there any option to cancel an inprogress booking? Or once started we cannot cancel and start a new booking? Has anybody figured anything out on that (I think it's on the regression list, wondering if anyone figured anything out in this area that would be helpful or if our accounts are essentially in a 15 minute lock)?

I was able to back out and make another reservation instantly. I believe this has been fixed

 

[vv813]

Appreciate you doing the work with Wyndham. Do you know if in the works where you could go in and have all reservations, dates, type of unit and whose name is on reservation.
This was available under the old system and it was nice to be able to see at a glance. Also I used it as a recap page at the end of the year of what travels we did or who we may have been with.
I have put this in their feedback page and I am not very technical so I don't know if I am expressing myself correctly but I am sure that others may feel the same way and could share their input

 

[Sandi Bo]

Appreciate you doing the work with Wyndham. Do you know if in the works where you could go in and have all reservations, dates, type of unit and whose name is on reservation.
This was available under the old system and it was nice to be able to see at a glance. Also I used it as a recap page at the end of the year of what travels we did or who we may have been with.
I have put this in their feedback page and I am not very technical so I don't know if I am expressing myself correctly but I am sure that others may feel the same way and could share their input

It would also be nice to know what owner booked the reservation (in addition to the items noted above). Not just nice to know, pretty important when you are using the same account and have multiple owners booking reservations.

 

[Sandi Bo]

You're correct it is on our regression list as item #4, fix estimated for June release. I know Wyndham has been working on this item back a browser "back button" approach - but I would prefer a "Cancel" button that appears somewhere as opposed to using the back button. The back button on my iPhone does now appear to work - whereas before it did not. I will keep this on our list and hold out for an actual "cancel" button.

Agree 100%. Glad to hear the back button is working now. And would love to see a cancel button in the future. Thanks for all your work on this.

 

[HitchHiker71]

Appreciate you doing the work with Wyndham. Do you know if in the works where you could go in and have all reservations, dates, type of unit and whose name is on reservation.
This was available under the old system and it was nice to be able to see at a glance. Also I used it as a recap page at the end of the year of what travels we did or who we may have been with.
I have put this in their feedback page and I am not very technical so I don't know if I am expressing myself correctly but I am sure that others may feel the same way and could share their input

This is partially addressed in regression item #21, however I've since had another idea on how to approach this in a way that would allow owners to customize the Transaction History view specific to their needs. I'm adding an item to the enhancement list today to capture my idea. Essentially - the transaction history section is table data - that lists specific field data. Beyond the default fields displayed today - offer an owner configurable column manager. So each owner can configure the columns they would like to have appear in this view. You can them move the columns around - and sort by each column by simply clicking on the column itself (which would switch between ascending, descending, and none). This way each owner can customize the Transaction History view as they see fit - and change it at any time as needed - adding or removing columnar data that is or is not important to them. I've added this as enhancement #24 on our list.

 

[chapjim]

This is partially addressed in regression item #21, however I've since had another idea on how to approach this in a way that would allow owners to customize the Transaction History view specific to their needs. I'm adding an item to the enhancement list today to capture my idea. Essentially - the transaction history section is table data - that lists specific field data. Beyond the default fields displayed today - offer an owner configurable column manager. So each owner can configure the columns they would like to have appear in this view. You can them move the columns around - and sort by each column by simply clicking on the column itself (which would switch between ascending, descending, and none). This way each owner can customize the Transaction History view as they see fit - and change it at any time as needed - adding or removing columnar data that is or is not important to them. I've added this as enhancement #24 on our list.

That would be awesome! Even awesom-er would be the ability to save one's custom report.

 

[Sandi Bo]

You're correct it is on our regression list as item #4, fix estimated for June release. I know Wyndham has been working on this item back a browser "back button" approach - but I would prefer a "Cancel" button that appears somewhere as opposed to using the back button. The back button on my iPhone does now appear to work - whereas before it did not. I will keep this on our list and hold out for an actual "cancel" button.

Today I logged in and 1st thing I did was initiate a booking, the 15 min clock started. I used the back button, it logged me out and when I logged back in I'm back in the middle of my -- the 15 min clock. Essentially had my account tied up for 15 min (unless I wanted to complete the booking). :-(

 

[Sandi Bo]

This is partially addressed in regression item #21, however I've since had another idea on how to approach this in a way that would allow owners to customize the Transaction History view specific to their needs. I'm adding an item to the enhancement list today to capture my idea. Essentially - the transaction history section is table data - that lists specific field data. Beyond the default fields displayed today - offer an owner configurable column manager. So each owner can configure the columns they would like to have appear in this view. You can them move the columns around - and sort by each column by simply clicking on the column itself (which would switch between ascending, descending, and none). This way each owner can customize the Transaction History view as they see fit - and change it at any time as needed - adding or removing columnar data that is or is not important to them. I've added this as enhancement #24 on our list.

Love the idea, sounds like awesome functionality. In the interim, it sure would be nice if they would show us the basic data currently missing.

 

[paxsarah]

It's a tradeoff between the calendar's initial load slowing down, or a user potentially clicking on multiple check-in dates and receiving the message that they won't work. The latter could easily take longer and be more frustrating than the former. I don't actually know which would be a better solution for the user.

Part of the issue is that say 9 months out, most check-in dates are probably viable and a user will more likely find something acceptable on the first or second try. In that timeframe, the slow load of the initial calendar may not result in an actual benefit to the user. But closer in or during the discount period, there might be 15 nights showing available but only 3 viable stays starting on those dates. A slower calendar load will likely pay off for the user who doesn't need to click on multiple check-in dates that don't work. So the real tradeoff is between helping the second user's experience at the expense of the first user's experience.

Just to revisit this, even if the functionality isn’t changed, the messaging around why there appears to be availability but then there’s no stay available when you choose a check-in date needs to be clarified. People just don’t understand it. I see this kind of message in the Facebook groups almost daily.

 

[Eric B]

Just to revisit this, even if the functionality isn’t changed, the messaging around why there appears to be availability but then there’s no stay available when you choose a check-in date needs to be clarified. People just don’t understand it. I see this kind of message in the Facebook groups almost daily.
View attachment 22700

If I ran a business that offered an availability search that I had to set up to apologize for providing misleading results to the users, I would do my darnedest to try to fix the search instead of apologizing. It's not a terrible place to be if you're in the IT business and trying to set up a simple and fast interface for availability searches. Looking at the big picture, though, that's not the business Wyndham is in. That's the problem with stovepiped organizations; they have a tendency to suboptimize the performance of the collective mission because of the needs of individual components. This implementation of the availability calendar seems like an example of that problem.

 

[Cyrus24]

I'll take this flaw over not having a calendar at all, people just need a little education. I'd always check the accessible units, as there probably is continuous availability in one of those units. Do I advocate taking an accessible unit when not needed. NO. But, if that is all that is available, it's fair game.

 

[Eric B]

I'll take this flaw over not having a calendar at all, people just need a little education. I'd always check the accessible units, as there probably is continuous availability in one of those units. Do I advocate taking an accessible unit when not needed. NO. But, if that is all that is available, it's fair game.

I agree with you in part; despite its flaws, the calendar does serve a valuable function for me. I just think it's bad customer service to set up an interface that is fated to provide inaccurate information and count on public relations or customer education to get people to accept its limitations. I understand why it's happening and why it would be difficult to correct, but this is an example of not listening to the voice of the consumer.

 

[Cyrus24]

just think it's bad customer service to set up an interface that is fated to provide inaccurate information and count on public relations or customer education to get people to accept its limitations.

I've learned to manage my expectations with Wyndham. Supposedly, it was the complaints on availability not being 'real' that led Wyndham to ax the calendar this go around. Agree, poor customer service, but, I'm so happy it's back that I plan on monitoring my complaints for a while.

 

[HitchHiker71]

Just to revisit this, even if the functionality isn’t changed, the messaging around why there appears to be availability but then there’s no stay available when you choose a check-in date needs to be clarified. People just don’t understand it. I see this kind of message in the Facebook groups almost daily.
View attachment 22700

The AC is behaving in the exact same manner as the Voyager based AC behaved before - so there is no change in functionality in this respect. Any solution requires changes to the back office components - which will be months in the making - it's not just a front office website change in other words. The team that runs the back office is still using waterfall management methods - as opposed to agile sprints - so we're not going to see any changes in the near term. The asks are in however, so I anticipate fall timeframe for any changes in scope.

 

[HitchHiker71]

I'll take this flaw over not having a calendar at all, people just need a little education. I'd always check the accessible units, as there probably is continuous availability in one of those units. Do I advocate taking an accessible unit when not needed. NO. But, if that is all that is available, it's fair game.

The core problem in attempting to do what is being asked here is that, with the current back office system, basically the AC would have to submit a date based search for each day of the month displayed. The back office system, when it receives the call for the AC display, provides the initial search result back that displays what we will call "rough availability", and then once you click on a specific start date, it performs another search at that moment and then returns back search results that, in this case, show the "no contiguous stay" result. Using the back office as it is today, this would mean the AC would have to submit 30+ searches, just to initially display the AC - which was looked at - and was declined by the back office team due to performance constraints. To offer up this function, the back office system needs to be changed to actually build and maintain new search indices that would have this data readily accessible and returnable in the resultsets such that the AC could then pull that data easily and display only dates that have contiguous availability. This is on Wyndham's radar - but it's not going to happen until fall timeframe best estimate.

 

[Eric B]

The core problem in attempting to do what is being asked here is that, with the current back office system, basically the AC would have to submit a date based search for each day of the month displayed. The back office system, when it receives the call for the AC display, provides the initial search result back that displays what we will call "rough availability", and then once you click on a specific start date, it performs another search at that moment and then returns back search results that, in this case, show the "no contiguous stay" result. Using the back office as it is today, this would mean the AC would have to submit 30+ searches, just to initially display the AC - which was looked at - and was declined by the back office team due to performance constraints. To offer up this function, the back office system needs to be changed to actually build and maintain new search indices that would have this data readily accessible and returnable in the resultsets such that the AC could then pull that data easily and display only dates that have contiguous availability. This is on Wyndham's radar - but it's not going to happen until fall timeframe best estimate.

Great to hear that they are considering including the functionality. Last I saw on here wasn't as optimistic. As I see it, the option of doing the individual day searches on the back office system to build the calendar might not be the best way to accomplish things; it would result in a calendar display of what check in days are available in the month, which does respond to one way of framing the "ask." If they subdivided the categories of suite types instead, the display would wind up being of days for which a particular subcategory of a suite would be available, which would allow someone to quickly figure out that for the month of XXX, a room would be available between day Y and day Z - the other option only conveys the information that a room would be available for the minimum booking period. My personal preference would be the latter type of option as it provides more information for less interaction.