Table42, a mobile app for restaurant discovery and on-the-go booking
Context: Studio X entrepreneurship course, Spring 2013
Team: Otso Hannula, Antti Häkkinen, Harri Sarsa, Eevert Saukkokoski, Max Sjöblom
Role: project manager, service designer
Table42 (i.e. "table for two") was an online service concept that allowed its users (restaurant goers) to discover restaurants, access real-time vacancy information and reserve tables through an easy-to-use mobile application. Restaurants that would opt to join the service (for a fee) would have access to an electronic table reservation system provided by the service and gain visibility through the location-based discovery aspects of the consumer mobile app. The market position of a table reservation service was at the time still largely unoccupied in Finland, and there was a chance to hold the position of a dominant table reservation provider (similar to e.g. Pizza Online in the domestic pizza delivery market). The concept was created on an ICT entrepreneurship course in the Spring of 2013 in a team of five master's students from different sides of ICT field.
The key pain of our customer was that reserving a table in advance or just getting the assurance that there’s vacancy at the diner you’re on your way to can be a hassle. Restaurants do take reservations but they can only be made by contacting the restaurant personally, either by calling when the restaurant is open or by email which often takes days as reply times accumulate. In case you want to compare which of your regular places have vacancies at a certain date you will need to have this interaction at least once per restaurant.
On the other end very few restaurants have table reservation systems beyond simple forms that send an email to the restaurant. Some of the larger restaurant chains have their own reservation systems, but the long tail of independent restaurants don’t have expertise and resources to invest in and implement their own reservation system. These restaurants would benefit greatly from having a ready-made reservation system directly connected to a customer base.
We developed an iPhone application prototype so help us understand the service as it was being developed and to gather feedback from potential users. A shipped version would also have the restaurant end of the service but because of the scope of the assignment we focused on the patron end.
Our consumer market was urban regular restaurant patrons who have access to a smartphone and are comfortable using smartphone applications. We considered out primary age range to be from 25 to 45 years for a patron to have steady income but still be comfortable with ICT to take our service into use. The age range might have been as wide as from 20 to 65 years as smartphones are becoming more popular among the population even beyond early adopters and young professionals.
According to our interviews, many of the 25 to 45 customer age bracket have a selection of 1-10 restaurants where they usually book tables. This is due to perceived difficulty of finding good new restaurants. Furthermore, while reservations are seen as a necessary pain, there could be room for an improved experience. Particularly, there are irritating moments when the patron is not quite sure whether his/her reservation has been properly received by the restaurant.
Our initial restaurant segment would have covered all restaurants in the greater Helsinki area that have seated customers and take or would be willing to take table reservations. We would have initially marketed the service to smaller restaurants that don’t currently have an electronic reservation system and could get one with no up-front investment, and larger restaurant chains and multi-brand restaurant companies that could leverage the service as a marketing channel. In a successful market penetration the restaurant segment would have expanded to cover all restaurants that are willing to take table reservations.
The most promising segment of restaurants for our service were the restaurants that have many tables that do not get filled during an evening. Restaurants that are fully booked many weeks in advance and do not get cancellations are not our main target, but there are very few restaurants that manage this. We have decided not to segregate lunch dining and dineries on a service level, but given the different nature of such dining the restaurants themselves might be willing to limit or disable lunchtime reservations.
The project was an immense learning opportunity because it allowed us not just to work with the business or technology side of the service but see as the interviews and concept development feed into the iterative service and application design. While we were not convinced that the concept would take off if we developed it commercially, I still sometimes think about having such an app on my phone.