For partners, hosting guests at their property can be very personal, for a majority, it’s their home. According to Booking.com’s statistics, it’s rare for guests to cause damage; – one in every 5,000 bookings, and most are accidental rather than intentional.
However the disruption damage can cause partners can be significant; not just the damage itself, but it can impact the next guest reservation, as well as create hesitation and uncertainty about hosting in the future.
Partners can safeguard against damage by opting to have a self-managed damage deposit in place where they can deduct money from the guest to recoup costs. This experience however can have challenging aspects; like guests needing extra cash on arrival, sometimes in a different currency. For partners, having the deposit can be peace of mind, but if they have a lot of guests or properties to manage, it can be an extra layer to manage.
Our team conducted a worldwide study to better understand partners’ concerns when hosting guests at their property. 80% of concerns are trust and safety related, with the top concern being property damage.
Knowing the difficulty of self-managing damage deposits, and the top concern of property damage, we hypothesised that if Booking facilitated the damage experience, it would improve partners’ experience hosting on Booking.com, as well as improve business metrics.
Partners wouldn’t have to ask guests for cash on arrival either. Instead, if damage occurs, they can ask the guest for payment after the fact. Booking.com facilitates this communication, collection, and return of payment on the partner’s behalf, solving a big user problem if they self-manage deposits themselves.
|Base: Self-managed damage deposit||Variant: Booking-facilitated damage programme|
|Collect deposit manually in advance or when guest arrives at property||No deposit needed, no surprise for the guest|
|Handle deductions||Partner creates damage payment request, Booking contacts guest and collects payment returning it to the partner for them|
|Return deposit||If no damage occurred, no deposit needs to be returned|
A simplified timeline of a damage payment request
Before testing our hypothesis, we wanted to see the bigger picture first, so I designed multiple user flows for partners, guests, and Booking customer service agents.
A work in progress of various user flows during the product’s creation
Using existing data points, we proposed amounts partners can ask the guest to pay up to in the event of damage, as well as where in the guest journey they will agree to this policy when booking a stay. For customer service agents, we had to lay out where in both journeys they are involved and in what capacity since they answer guest and partner inquiries.
After we agreed on our approach, we collaborated and aligned with various internal teams.
I then designed the product that partners would use to make a damage payment request as well as the experience guests have when paying for the damage.
A close up of how I structure my Figma file
I aligned closely with other UX teams, followed style guides, and collaborated closely with my UX writer.
A prototype overview of partners creating damage payment requests
I made sure to create prototypes that were as interactive as possible so that in usertesting, we could see what partners and guests were doing in order to refine both experiences.
When we learned as much as we could from usertesting, we built the product as an MVP to test our hypothesis. We needed a statistically significant sample size, as well as a considerable run time since it required real-world damage plus partner and guest interaction.
A mockup of the damage payment request process for partner and guest
After many months of experimentation and observation, a Booking facilitated damage experience proved successful for both partner and guest. It was rolled out globally to all applicable partners.
During this project I learned to:
Check out Liability insurance