Vacasa - Extend My Stay
My Role: Product Manager leading the product team (4 engineers, 1 designer) for post-booking applications, in this case the Trip Manager web application.
Background: Many vacation rental guests choose to extend their stay beyond the dates of their original booking, either because of a change in plans or because they’re having a great time and want to stay longer. Allowing for trip extensions was a great revenue driver for Vacasa, creating millions of dollars in value each month, and helping to fill in gaps in a unit’s calendar.
However, this came at a cost: in order to extend their stay, a guest must call in to customer service and have an agent manually alter their dates. Besides being a poor guest experience, trip extension calls had an average handle time of 10 minutes, and with thousands of calls per month, that added up to a lot of customer service time, making it expensive to scale.
Objectives: By implementing a self-service “Extend My Stay” feature for guests in Trip Manager (Vacasa’s post-reservation web application), guests could add dates to their trip without having to call in to GX. This would ideally result in:
A shift away from trip extension calls, saving customer service time and money
An increase in total trip extensions by exposing the feature to guests and making adding dates easy and intuitive
Project:
Reservation Service Endpoints
First, we worked with the internal platforms team to design an API that would allow Trip Manager to make and pay for date adjustments to a trip, without having to go through customer service.
UX Research
Our initial plans called for a calendar similar to the one the guest originally used to book a unit, but there were some issues with making that work.
First, we tried testing the calendar UI using usertesting.com, and we found that many users were under the impression that the calendar allowed them to change their dates (meaning potentially removing dates) which we could not allow.
The second issue was performance. Showing which days were available after a stay was simple, but showing available days before the original check-in was a totally different beast. Vacasa’s unit calendars are governed by different unit-level rules — for example, a unit might have a min stay of 2 nights or a max stay of 10, it may have rules that prevent booking Fridays and not the rest of the weekend, etc. All of these rules are based on the start date, which is why when you select a start date on a Vacasa calendar, you’ll see the available dates change. So, in order to see if a days prior to the check-in date were available, we not only had to look to see if the day was unbooked, but check to make sure that a stay with that start date would be valid. That meant running those rules for every single day prior to the start date, each as individual requests to the quotes service, which ended up being a big performance hit if we scaled it out past a handful of days.
So we took a different approach. We looked at past trip extensions (over the phone) and found that 95% of extensions were for 3 or fewer additional days. We decided that offering extensions much longer than that was overkill, and not worth the performance hit. We decided we’d offer 4 days prior and 4 days after the trip instead.
Based on that data, our UX designer came up with a more focused experience. The guest would see up to 4 dates (if available) at either end of their stay. This focused approach would make the action clearer to users, and wouldn’t allow for the perception that dates could be removed. And indeed, we ran another round of user testing, and participants preferred this streamlined UI vs. the original calendar proposal.
After selecting dates, the guest receives a quote for the new amount, and is able to go through a payment flow.
Results
Right off the bat, by simply adding the “Extend Stay” link in the Trip Manager navigation (without notifying users of its presence via communications) we saw hundreds of trip extensions, with hundreds of added days, totaling tens of thousands in revenue in just the first month.