Giving restaurants more control over how they take reservations

The OpenTable GuestCenter platform originally allowed restaurants to specify that a table on their floorplan was either available for online reservations, or not. There was no customization by date or time, so to be safe restaurants marked many tables as not reservable, potentially losing out on business. We hypothesized that if we could allow restaurants more flexibility about how and when they took online reservations, we could get restaurants to make more tables reservable online, and get more inventory on OpenTable.com for diners.

Research

Before we designed any solution, we wanted to understand why restaurants were asking for more customization. What's special about a particular table that makes it not reservable by a diner online? We took a research trip to Seattle to talk with 10 restaurants about their dining rooms.

Insights

1. Time of night affects how restaurants manage their tables. During the prime time period, restaurants want to hold back a few tables for VIPs and walk-ins. However, during the slow shoulder times, they would want as many reservations as possible.
2. They need to set expectations with the diner about sitting at a non-standard table. No one expects to book a reservation and then get sat at the bar.
3. Large parties slow the kitchen down and take longer to dine (which limits turning the table over to get a new paying party). Restaurants want to limit when large parties come into the restaurant.

Design principles

The research also revealed customer pain-points that influenced our design/product principles:

1. The system should be easy to reverse engineer - if a new General Manager gets hired, she should be able to look at the settings and understand the intent of the old GM.
2. Use progressive disclosure. Settings should be minimal for a simple restaurant, but a complex restaurant should be able to use the same system to achieve their goals.
3. When a General Manager changes a setting, it should be clear to her how it will affect the availability of online reservations.

Concepting

One of the major findings from the research was that table types behave the same, simply because of their type. Bar seats are not reservable because they are a bar seat. With that, and design principle 2 of easy setup, we designed several concepts. Theidea pictured below allows the user to group all their bar tables together and then apply settings to the 'bar' group as a whole. I hypothesized that this would be faster than applying settings to individual tables, and would help a new GM understand the intent of the settings.

We user tested with restaurant customers in San Francisco, here are a few key things we learned during this research:

1. The model satisfied the need to set table availability.
2. There was confusion if diners would also see the names of the tables types.
3. No unflattering names. Even if the table by the bathroom is not reservable online because it's near the bathroom, they'd never label it like that.

Design: what type of table is it?

First, we had to let the restaurant tell us what types of tables they had.

Design: non standard tables

Next, they had to be able to tell us when each table type was taking online reservations. But here's where the challenge became harder: high-demand restaurants needed a way to say that bar tables were taking reservations only during some parts of the night. During research, restaurants talked a lot about the early and late shoulders being slow and the prime time of the night being the peak.
Following principle #1 of easy audit, why not let restaurants define early and late periods, and then they can apply settings for each table group to those time periods?

How do restaurants express what's early and late? The time selector went through several iterations to simplify the design. I removed the jargon of "time periods" or "sub shifts", and put the choice of early/mid/late into a modal because it's a less frequent action.

We designed several different mental models around setting table availability. Natural language input would have better expressed intent, however it's scanability was really lacking and it gets very complex when there are a lot of options. Instead, we moved forward with a grid organized by table types and time periods because it's easy to look at the list and get a good gut check of "yeah, that looks right".

Design: non standard tables

Finally, what does the diner see? I worked with my partner on the consumer team to give a choice to the diner of where they want to sit.

Results

Identifying non-standard tables was a major win and a quick way to gain more inventory from restaurants who wouldn't list those tables online only because they weren't standard. In the first quarter of the launch of special table types, we had 795 restaurants putting non-standard inventory online.

What's next?

We're listening to customers about what's working for them and what's not. Here's what we're iterating on next:

1. There is ambiguity in the table type list about where big tables live. Would a patio table that seats 12 be under large, or the Patio section?
2. Even though the 3 time periods work for 90% of restaurants, there are some restaurants that need even finer control. We need to figure out how to address those 10% of use cases.
3. The list of tables is a poor representation of the floorplan, how can we make it more visual?