0%
Portfolio » Case study

Competitive sets

company.

Wheelhouse

role.
  • Strategy
  • Product management
  • UI / UX design
  • Front-end development
duration.

6 weeks

team.
  • Mike – Lead engineer
  • Ian – Engineer
  • Vu – Customer exp.
deliverables
  • End-to-end feature
  • Ready to beta test
  • Allows free-trials
  • Subscription-based payment
What is Wheelhouse?
Wheelhouse is a revenue management & market insights software designed for professional short-term rental operators. Built from the ground up by PhD Data Scientists.
What's the challenge?

There was a lack of trust in Wheelhouse Pricing. Early on, limited data was provided to provide users insights into the recommendations. Over time this changed but it was never 'enough'. In addition, Wheelhouse was looking to move up market and attract more professional revenue managers and teams.

To do so, providing more customizable, explorable tools that allowed users to compare against similar properties garnered the most interest.

the problem[s]

Existing customers

  1. Didn't trust Wheelhouse pricing recommendations
  2. Requested more insight (on a daily basis) into our data
  3. Wanted to centralize their tooling & save money

Potential customers

  1. Saw Wheelhouse as an amateur tool as it lacked standard tooling
  2. Needed a big push to move away from existing tooling

Wheelhouse

During this time, Covid greatly impacted both the industry and Wheelhouse's revenue. It left us scrambling to find solutions. We had been building competitive set solutions internally for a few months and knew it could be a new revenue stream and increase out customer base.

Ideal Outcomes

Increase automated nights

We earn a % from each automated night booking. Based on conversations with our customer base, we knew there was a trust gap causing many to turn automation off.

New revenue stream

There were companies selling services, products, and feature sets focusing on similar features, all with less data than we had.

Broaden customer base

Wheelhouse started as a solution for smaller Airbnb hosts. Overtime we developed solutions for larger property managers and small hotels. However, there was reluctance in the latter to use Wheelhouse.

Background

Research

Our team reviewed existing solutions in the short-term rental & hotel-grade software space. Our head of support, Vu, had hundreds of conversations with our users. Quinn, our product manager spoke extensively with companies and our internal revenue managers about competitive sets and how they are used to create pricing strategies.

We continued to see a pattern of issues, highlights included:

  • Static—Couldn't dig into the data enough
  • Context switching—People ended up paying for multiple services while having too many tabs open
  • Rigid—The defaults often weren't good enough
  • Incomplete outlook—Missing data left people spending time filling in the gaps
  • Overall cost—The results made it hard to justify the high monthly or yearly subscriptions

Our existing solutions

Before the release of a full-feature product, different variations of a competitive sets feature we already being used within the Wheelhouse ecosystem.

External

  • Wheelhouse Pro–Provided aggregate metrics of comparable listings
  • APIs–Provided a limit set of market & competitive set data

Internal (Built for Lyric)

  • Quick comparisons—An internal app comparing our properties to relative Airbnb listings
  • Comp. sheets–An internal app provided to Lyric revenue managers to monitor daily performance

getting started.

Scope

This was the last project Mike and I would be working on for Wheelhouse. We had 6 weeks to create something we could beta test with our existing customer base & pitch to larger revenue management teams. It needed to be a complete experience which addressed the core needs, fit into the existing application, and included on-boarding [trial, payment, subscription UI].

  • On-boarding
  • Overview
  • Viewing specific competitive sets
  • CRUD UI
  • Subscription management

Use cases from Lyric

Luckily, we'd been building internal tooling for competitive sets for months. Our hospitality brand, Lyric, and its revenue managers were using these while giving us feedback on a weekly basis. One of the revenue managers on the team provided a few use cases they felt mandatory:

  • View & customize my competitive set(s) based on property
  • Filter & sort by short-term rentals and hotel data
  • Review building & unit type performance (past & future-looking)

Baseline principles

  • Macro & micro: Existing solutions didn't provide the whole picture while also providing the tooling and data to drill down into the specifics.
  • Defaults with customization: Experienced revenue managers sift through the data. They have pre-existing methodologies and want their tooling to work within this. At the same time, with the massive amount of data Wheelhouse stores, doing some of the legwork beforehand saved these managers a lot of time.
  • In context: Have the UI show all of the necessary information at once instead of making people use multiple tabs or jump to different areas of the app.
  • Transparency: Display timestamps for when the data was last updated and the overall system functionality.

high-level work.

Early on in the process, Mike and I reviewed the existing Wheelhouse application and denoted how competitive sets would exist. While the initial version would be completely separate, we felt it worthwhile to show where the product could progress. In addition, we started outlining the specific pages of Competitive Sets through sketching & flow charts.

1 / 3
2 / 3
3 / 3

Initial journey

  1. Notification regarding Competitive Sets
  2. Visit overview
  3. Start free-trial
  4. View recommended competitive sets
  5. Confirm recommendations or create a new, personalized set
  6. View performance data
  7. Compare nightly pricing across calendars
  8. Compare pricing strategies
basic wireframe.

Most of the interactions customers would be doing would take place within the main view. This view would consist of everything a manager would need to review pricing strategies and take the next steps.

Initial wireframe

Default view

The default view provides the viewer a quick and easy way to compare their pricing strategy with the competitive set properties. From this view they can make in the moment changes to their pricing settings. In the future the viewer could set alerts when specific competitors changed their settings as well as automate their own settings to react accordingly.

Calendar view

The calendar view provides high-level insights of the aggregate competitive set along with a table view breaking down specific dates. One of the most requested features, the calendar table will make it easy for the viewer to review a specific pricing timeline and quickly make adjustments to their own pricing strategy. To help keep the viewer within the calendar view, we added a map.

Performance view

The performance view provides multiple sections of macro & micro insights. At the top is a graph which can display the most common metrics—revenue, average daily rate, average occupancy, etc. The viewer can filter the data by time (specific dates or chunks) and view different types of graphs based on the metric being viewed.

Underneath the graph section is a table view. By default we highlight information pertaining to the properties bookings. The viewer can compare against the aggregate competitive set or drill down into specific properties.

Both sections can be exported to CSV or PDF. In the future this view will provide more customization. The viewer could select default graphs & tables to appear on the first visit as well as setup automated exporting to slack or email.

Intro view

This view serves both initial on-boarding and lists all competitive sets tied to a specific property. In addition, it would be a place where we could provide updates and educational content directly pertaining to the feature.

Outcome

In 6 weeks we went from a concept to a complete feature ready to beta test with the existing customer base. Before leaving I put together a list of next steps, both near and long-term, for the team. This included:

  • Release to beta users and track use
  • Schedule on boarding sessions & after a couple weeks interview users
  • Confirm final subscription price, free-trial duration
  • Create release process—videos, help center articles, etc.

[Update May 2021]

I recently checked the status of competitive sets and it's now been released to all of Wheelhouse's customer base. In addition, a new pricing structure was created to take advantage of this feature as a new revenue stream.