At Booking.com, as we strive to give partners (property owners) a frictionless experience, we originally had our extranet setup to only support one account (user) per property. From previous research we knew there was an interest in having the possibility of creating accounts and controlling their permissions, both from a partner and company perspective.
So why did partners want to have multiple accounts? According to my research and analysis, the limitation of single account was that properties had to share their username and password with their whole team. Allowing for everyone to have full access across the property account on the extranet was risky. There was also the fact that on each login attempt, there was a 2FA security check which would be sending a temporary code to the account owner’s phone and they could have been absence for many reasons like not at the office or out of their working hours. Then the login process was a painful blocker for their business.
If passwords were shared between employees, if one of their employees would quiet or get fired. The password would require to be changed immediately and shared again with the rest of the team. If there was a malicious current or ex-employee wanting to change details on the property account, there wouldn’t be any way of tracking who did the changes.
I needed to understand more detailed requirements why partners wanted to do with the capability of having multiple accounts connected to their properties. I decided the best way was via a qualitative user interview research. The interviews help me know what actions users were performing on their extranet accounts. For example, in order to be able to manage the accounts themselves, including restricting access were important features for them.
Through a survey, I wanted to understand who was interested at a property type next. If the features they were most interested changed between property size, team size and type. As expected from the results, the larger properties were more interest in the possibilities of having these accounts and permissions. But the most important features was still about tracking user activity, the ability to manage accounts themselves and choosing permissions for each user.
I created a user flow and design for the new extranet feature where partners would create and manage additional user accounts and tailor the permissions for each user individually. I believed this change of allowing properties to manage more then one account and control their permissions was going to be beneficial because it would allow partners to manage accounts autonomously. It would increase security, as partners would not need to share anymore one username/ID and password among members of their team. It would also be easier for us at B.com to tailor a more personalised interaction with them, by using our role options provided. So when they visit the extranet or receive communication from B.com it would be more relevant.
This new feature was going to be optimised to use for individual properties. Depending on the success and perceived value for our partners, this would possibly had been further improved with more functionality and the ability to manage our more complex level of properties (group accounts).
The product was launched to all listings worldwide, with one exception being the group accounts. The initial feature is optimised for individual listings. To create or manage group user accounts, the procedure still remains broadly unchanged and B.com needs to be contacted for assistance because of its large complex scale.
Because of my effort in creating a frictionless experience for partners to create and maintain their work more efficiently and improve their security. It was a huge improvement for them all. Our customer service tickets went down in creating multiple accounts, it also reduced submissions of partners having lost their password and someone login into their accounts without their awareness. Partners felt more secured and could monitor any discrepancy themselves.