Expedia Group

Rate Plan Modernization

Making a critical self-serve tool easier for hotel partners to use, decreasing support costs and increasing Expedia’s commissionable sales.

What’s a Rate Plan?

Each rate plan is a set of parameters – managed by the hotel partners – that dictates the conditions of a potential rate. Rate plans generate the available room options and prices when travelers search for a room. 

Problems:

Users couldn’t even get through the old creation flow, with only a 48% success rate when creating a rate plan, and 37% success rate when editing an existing one.  

Over half the people who try to add or edit their rate plans just call Expedia for help, contributing to over $2 million in support costs annually. 

“The website is utterly confusing with no guidance. It’s really hard to set a price for a room and make it available. This is why we withdrew our hotel in the past and, coming back, it seems as bad as before.”
-Research participant
“I find the setting of rate plans and rates to be impossible to understand. Even when I do think I have done them correctly they do not seem to have worked.”
-Research participant

Design challenges:

  • Legacy tech stack with spaghetti code
  • 3 changes of PM
  • Constant plot twists and slow-drip of requirements
  • Strategy scope creep
  • Considerations of third-party software integration.
  • “We don’t want a lift-and-shift.”

 

Content design outcomes:

  • Handling “Base rate” 
  • Side sheet strategy
  • Side sheet technical limitation
  • Help documentation
  • General content improvements
  • …and more!

Tackling “Base Rate”

 

“What does this field even DO?”

It’s entirely unclear. If I’m a Partner and I put a dollar figure in here, what does the traveler pay? How much am I getting paid out from Expedia? Why is the rate displayed on the site different?

We weren’t telling users the answer.

Worse: we didn’t know either. Not even our engineers had the answer. Yikes.

I hunted down scraps of info and cobbled together the answer: base rate can go through one of three different calculations before generating the rate the traveler sees.

This was previously documented nowhere.

The previously-undocumented BAU calculations:

Simplifying – or making it seem simplified.

A single string covering three different financial outcomes was a no-go.

I decided to make the copy around the input field dynamic based on that first condition – the Rate Acquisition Type – which saved users from deciphering a wall of text if all three possibilities were described.

Because users could potentially change their tax settings in the future, it was important to indicate that Base Rate would be affected if they chose to do so. 

The calculations remain the same, but only the relevant pieces are displayed to the user:

The copy:

What else?

  • I documented the history and decision-making around Base Rate in an extensive Confluence document, to ensure a future CD doesn’t similarly tear their hair out. 
  • Base Rate prompted me to develop the Help article independently of our support team, anticipating that the intricacies of this flow would make it inefficient to brief them from scratch. 

End-to-end project outcomes

 

Forecast results:

Anticipated 10% increase in self-serve completion rate, leading to:

  • Est. over $350,000 in saved support costs year 1
  • Est. over $2 million annual revenue contribution from enabling partners to create specialized rate plans
  • More intuitive
  • Improved interactions
  • Stronger visual hierarchy
  • Streamlined user experience
  • Clearer content
  • Easier to create multiple rate plans
  • Strengthened user’s mental model of linkages
  • Scalable design 

Beyond Base Rate

Base Rate was just one problem I solved for in this flow.

If we chat, I’ll walk you through more.