ResyOS is a complete restaurant reservation platform built on iOS offering cutting edge and user friendly tools, including inventory management, reservation booking platform, in-service table management, ticketing and events, CRM and guest management, analytics, POS integration, and more! Our mission is to create technology helping the restaurants we love from the inside out, seamlessly enabling them to provide their best dining experience.

As we expanded our offering from single-venue restaurants to multi-venue restaurant groups, it was clear that we needed to provide the back-of-house call centers a reservation system tailored to their needs. 

Contextual Interviews and Reservation Office Shadows

I shadowed at multiple restaurant groups’ reservations office. Below are two case studies that represent different types of reservation office scenarios. 

Case Study 1: Union Square Hospitality Group by Danny Mayers

• 19-unit restaurant group

• Combination of high- and low-demand restaurants 

• Combination of restaurants heavy on reservations and heavy on walk-ins

• 99% of reservations are bookable online

• Reservation booking window: rolling 28 days before day of reservation 

• 17 Reservationists

Observations and Insights

• There is one phone queue for all restaurants. They use ShoreTel software which tracks the number of guests on hold, shows the next call, and which restaurant they are calling for.

• At any point in time there are at least 20-40 people on hold, therefore speed and efficiency is of paramount importance. 

• There are a couple of trigger questions, such as “I am calling for a reservation for 2 at Manhatta at 7:00 pm this Friday”. The rest of the process is very repetitive and mechanical.

• Guests almost always know their venue and party size, but they can be somewhat flexible on the date, and most are flexible on the time.

• Reservationists prioritize dining room seating, offering bar seats options only when the former are unavailable.

• When the requested date and time is unavailable, reservationists do their best to offer up other options - they never want to say no. They offer the following options:

  • other times on the same day (add a note of the original requested time)

  • bar seats if dining room is not available

  • other days in close proximity

  • add them to the Resy notify (virtual waitlist)

  • if the date and time is not flexible, offer other restaurants within their group

• The greatest amount of time is spent on adding guest information. They inquire about special occasions, allergies, special requests, and any other visit notes.

• If a guest calls and states their name first, the reservationist has an opportunity to look up the guest before starting the reservation process. 

• Reservationists receive many calls from concierges or personal assistants, but want to both maintain the assistant’s contact and link it to the diner’s guest profile.

• Reservationists will occasionally overbook to accommodate a VIP or a special occasion for a guest. Overbooking is usually approved by a manager, and requires knowledge of the restaurant’s current reservations and schedule to accommodate the overbooking. 

• 30% of calls are to change or cancel a reservation.

• There is high turnover in reservationists, the tool should be easy to use with a limited learning curve.

Breakdowns with Existing Solutions

Concierge Portal

Resy had outsourced the building of a concierge portal to show availability across multiple restaurants. This was intended for Hotel Concierges to view what was available at a glance, and rapidly make reservations for their hotel guests. It was given to restaurants too, however, as a quick solution for reservation booking for their internal call center. It was clear that the concierge portal was not built for restaurants, and was not optimized for internal restaurant scenarios, as it:

• Provided the ability to book, but not change or cancel a reservation

• Provided no options to add notes and tags

• Did not allow overbooking

ResyOS on iOS

ResyOS on the iPad or iPhone is optimized for in-service use. When used in call-centers, several shortcomings were made clear:

• Inefficient to quickly change between venues for reservations

• Reservationists use their desktops for all other tasks, for example ShoreTel to track and claim incoming phone calls, and Slack to communicate with their team

• The iPad touch interface is not the most efficient platform for detailed data entry of notes and tags

Design Iterations

Navigation

To ensure we optimized for repetition, speed, and clarity we decided to opt for a step-by-step workflow and enabled keyboard navigation.
We also ensured that each step in the workflow increased in the diner’s perceived flexibility (Venue -> Party Size -> Date -> Time), improving diner’s satisfaction and increasing the success rate of reservations booked.

While the platform catered to Reservationists’ workflow, the interface supports responsive-web for mobile, accounting for managers who would need to book VIPs or other overbookings while on the go.

Availability View

Displaying availability was the trickiest part of the process. With a new inventory management system, Resy transitioned from a static list of availability (slots) to a dynamic table-based inventory system (Resy Fly), which factors in turn-times (length of a reservation by party size), minimizes gaps between reservations, optimizes for table capacity, and respects pacing (the number of allowed covers per 15-minute increment). We iterated on options that mimicked the visual of ResyOS (iPad) Classic as well as options that were representative of these new features of dynamic booking. We conducted several feedback loops with both internal stakeholders (account managers, c-suite executive) and external stakeholders (reservationists).

Prototype and Usability Testing

I conducted a usability test with 3-4 reservationists from two restaurant groups: Union Square Hospitality Group and Happy Cooking. Acting as a guest calling in, I used a list of common trigger questions and observed how the reservationists navigated the web prototype and the mobile-web prototype.

Design Acceptance Test

As we approached the final phases of development, I did a design acceptance test to ensure the visuals looked and worked as expected. I documented all bugs in a google sheet. Some tweaks were also added based on executive review feedback and the final usability test.

Metrics and V2

Some insights from our usability studies as well as ideas that came out of our brainstorming sessions did not make it into the V1 release. We added data points using MixPanel to track behaviors and funnels where possible, and in other cases we plan to follow up with feedback loops in the form of focus groups and restaurant shadows. (First one scheduled for December 3rd, 2018 with Union Square Hospitality Group)

Some ideas we are watching for:

Team and Timeline

The entire project took about 6 weeks with Design involved at different touch points.

• 1 designer (me)

• 1 product manager

• 2 front-end engineers

• 2 back-end engineers