CAKE GUEST MANAGER

rethinking the functionality of a classic restaurant waitlist tool

The Challenge

Guest Manager is an app meant to help busy restaurants manage their waitlist. Instead of the traditional method of having a hostess take down a party’s name and relying on the guests to hover nearby until they hear their name called, Guest Manager allows guests to receive a text when their table is ready. This frees guests up to spend their time elsewhere and keeps restaurants from having that impatiently crowded, about-to-board-your-Southwest flight feel.

Users of our app loved the simplicity, but it had been several years since we had done an extensive usability study. Other than updating the dated look (sorry, fans of wood paneling!) what changes could make this tool even more helpful to the hosts who use it?

The Plan

In order to witness how Guest Manager is used at different restaurants, the plan was to combine in-person observations at about 15 restaurants with interviews of hosts and managers at those locations. Since all of those observations occurred in the metropolitan areas of Chicago and the Bay Area, we also added in some phone interviews to achieve more geographic diversity.

Observations lasted up to 3 hours and would occur when Guest Manager is at peak demand: Friday and Saturday nights or other busy times for that particular restaurant.

User Research

Guest Manager has two separate components that work in tandem: a waitlist for keeping track of parties waiting to be seated, and a floormap for keeping track of where you seat those parties, how evenly you are distributing parties to servers, how the diners are progressing in their meals, etc. We assumed that most people would be using both of these parts of the app, but were surprised to find that 68% of venues only use the waitlist. Only 29% use both parts of the app, and 4% use the floormap exclusively.

Why only use the waitlist?

For some small restaurants, the entire floor can be viewed from the hostess stand. The act of updating a table’s status to show that the party is done with their appetizers and moving on to their main course is unnecessary in such a case. Especially with only one hostess working, as is common in a small restaurant, who does this information benefit? The added table and server stats that come with using the floor map were not compelling enough for these locations to use the floor map.

A surprising use of statuses

One feature that we saw being used in a surprising way was party status. This was something originally conceived of as a way to distinguish guests that had visited multiple times, or were otherwise VIP. Users could change a party’s status and also add on other statuses. What we found were users creating statuses to note party preferences, like “inside”, “outside”, or “first available”.

Other statuses used included "high chair”, “wheel chair” and “booster seat”. The issue here is that only one status can be assigned to a party, and this set of tags is not mutually exclusive.

Fast access for area codes

At one location I witnessed a hostess take down a phone number, only to realize the guest had neglected to give the area code, assuming she knew it was the local area code. She then waited till the guest had left, wrote down the number on her notepad, and then re-entered the number with the correct area code preceding it. What if the app surfaced the top-used area codes and users could press this fast access button at any time during number entry?

Design principles

Optimizing the Waitlist

If 68% of restaurants were only using our waitlist, we needed to make it even quicker to use and more personalized for each restaurant. Taking what some restaurants were doing with statuses, and changing that to tags that users could create and apply to parties would allow restaurants to gather all of the information they required for each party.

To further save time for users, we made the party size a scrolling wheel of options, focused on the most common (2-7 guests) and made space for up to 5 of the most commonly used area codes, which are automatically generated by the app after a month of use.

Using the Waitlist as an Gateway to the Floormap

Knowing that less than a third of users are utilizing the floormap, we wanted to make a bridge between waitlist and floormap, thus the split screen view. Additional server statistics, and ways to turn on and off filters for table views also made this view and the full floormap more user friendly.

A Full View of the Calendar

Originally, the calendar only had a day view, which was great for users who were checking in parties for the day, but what we found was that this view was not conducive to planning for the night, and was especially bad for looking ahead at the week or month. A calendar that could show a few weeks at a time, and surface the biggest parties of the night, would help users as they took reservations over the phone or planned for busy periods at the restaurant.

USability testing

Although we had been thoughtful in our research and design, we still wanted to have greater confirmation before releasing the design to every restaurant. Ben, our product manager and I developed an idea for a very small beta— just 8 restaurants— that would try out the new design over the course of a busy weekend. We observed this beta very closely, tunneling in so that we could see them use the app in real time. They knew how to switch back out of the beta if needed, and had our numbers to call as well. While we did see some restaurants switch out (4 of 8), we also saw them switch back in (2 of 4). The feedback was overwhelmingly positive, and we were able to make some minor but important changes before release to the rest of our customers. It was from this beta that we got the feedback to develop our dark mode, for more dimly lit restaurants.

End result

The final result, in both light and dark modes (to accommodate both dimly lit restaurants and patio seating).

Ultimately, we were very pleased with the new version of Guest Manager.  Usage of both parts of the app increased from 29% to 65%. Our rating for “Ease of Use” on Capterra went from a 4 out of 5 to a 4.9 out of 5. We were even able to transition from a sales-person based sales model to a self-serve sales model.