‘Standards’ and ‘interoperability’ are fast becoming restaurant industry buzz words, at least from the tech side. Restaurants still largely operate in a very ‘Web 1.0’ way, with flash websites and PDF, word, or scanned menus. This is fueling an explosion in restaurant-related online food ordering, review, and recommendation websites, who are all trying to come up with creative ways to digitize and keep restaurant menus current. This entrepreneurial activity, however, has resulted in an entire ecosystem of apps and websites that have invested significant resources in work that’s already been done (sound familiar?).
Is this the largest problem? On the surface no, but it does have wide-ranging implications affecting much more than the consumer who wants to order food or locate a restaurant.
Menus contain a wealth of data that could be used in a variety ways, such as helping farmers, health professionals, restaurants get better insight into ingredient trends, or for building apps that help consumers make dining choices that are better for their health and inline with their values. Yet currently, each system describes the same information in different ways, making it impossible or extremely difficult for them to communicate and for companies to collaborate.
Challenges related to the accuracy, completeness, and format of this data have severely hampered innovation in an industry that could really use it. Now, a growing number of technologists like OpenMenu founder Chris Hanscom are trying to change all of this. OpenMenu has developed a standard format for storing and sharing restaurant menu information. The website offers tools that make it easy for restaurants to seamlessly update multiple networks and web applications, and for developers to build off of the data. To date, the website has over 50K menus with 2.4 million menu items in their database. I got a chance to speak with Hanscom about the OpenMenu, developing the standard, and his business model.
___________________________________
DG: Danielle Gould: What was the inspiration behind OpenMenu?
Chris Hanscom: It all started with one simple question asked by my wife; “Where do you want to go eat for your birthday?” The question was simple but the search was not. All I wanted that day was a piece of death-by-chocolate cake. So I started searching for a restaurant, looking at websites, loading menus. Loading menu after menu in formats that where large, clunky and often difficult to search through. PDFs, scanned-in images and Flash based. All things I consider user-unfriendly. There had to be a better way.
I thought about this idea for almost 2 years. I thought about how things should work, how the information should be structured and what else would be required for OpenMenu to provide a platform that meets the needs of restaurants and developers.
DG: How does the site work?
CH: OpenMenu is broken into two main parts, one for restaurants and one for developers, all built off the OpenMenu Format specification.
Restaurants create their menu, and detailed restaurant information, in our standard which is called an OpenMenu. This OpenMenu is the version of their menu which becomes plugged into the internet and drives their online presence. Make a change to your OpenMenu and all services connected to this publically available menu instantly gets the change either directly by watching the OpenMenu or indirectly via our API. For example: add specials at 9:00am and they are instantly reflected on a restaurant’s website, Facebook page and any website in our distribution network. One menu, maintained in one location, driving a restaurant’s complete online presence.
Developers get access to the complete specification as well as a powerful API to assist in powering their solutions.
DG: You call OpenMenu a regulatory system, could you describe what you mean by that?
CH: The difficultly in any open data system is the integrity of the data. OpenMenu has the specification, the central repository for requests and the API to extract data. We’ve created a system that balances between remaining open and controlling the information enough to maintain the integrity of the data. The regulation we’ve put into place is the OpenMenu Registrar system. In short, an OpenMenu Registrar is the only place to get menus into the OpenMenu Platform and the trusted sources for menus and restaurant information. We handle the routing of requests, via the API or direct connect to an OpenMenu, to the proper OpenMenu Registrar.
This system in place provides a level of confidence to developers in the quality of the information they receive and gives restaurants a single point of access into the OpenMenu Platform.
DG: How did you develop the standard?
CH: I looked at the standard from both a developers perspective and a restaurants perspective. I reviewed many menus and developed the first release. Then I watched how things were used and most importantly listened to others. The standard is a dynamic entity that needs to adapt and change to meet our internal goal of a standard that can handle 98% of the world’s menus all the while protecting developers with backwards compatibility.
DG: Why would a restaurant choose to use OpenMenu? Have restaurants been receptive to this value proposition?
CH: Restaurants have totally embraced OpenMenu. We provide the system for restaurants to manage, display and distribute their menu. We provide the online/mobile menu manager and everything from a Facebook App (OpenMenu Tab), WordPress Plugin, Drupal Plugin, Mobile Website, QR Code, OpenMenu Template and even a basic website displaying their menu and restaurant information. All for free.
DG: Please describe your business model.
OpenMenu operates very similar to other data providers with the main difference being we offer a full suite of open source, open standard information.
DG: How do you differentiate yourself from other restaurant menu websites?
CH: OpenMenu is different in a four major ways:
1) We’ve established a standard for restaurant menus and information ensuring everyone is speaking the same language. This facilitates the sharing of information.
2) We’ve created the tools so restaurants can manage and display their menus with ease. All of our solutions are tied to a single, maintained, OpenMenu. W make it easy for restaurants.
3) We believe in being open to protect the interest of restaurants and developers. This means each restaurant’s OpenMenu (the version of their menu in the OpenMenu Format) is open and always publically available. This is to encourage the use of OpenMenu’s.
4) Developers using our data can cache the data. A core value of OpenMenu is to create a risk-free platform for developers. We want to protect the interest of developers.
DG: You recently began working with Factual’s Crosswalks API, what does that mean for restaurants and developers?
CH: Restaurants that are part of OpenMenu will now have their information pushed further out across the internet by being found, and connected, via Factual. This further strengthens OpenMenu’s position that “one menu, maintained in one location, powers a restaurant entire online presence” which is obtained by us setting up the distribution channels on the restaurant behalf.
For developers it’s slightly different; Crosswalks allow developers to use OpenMenu to obtain the IDs for restaurants in other system thus making it easier for cross-referencing of information. A single entry point of access for information about a restaurant.
This is an exciting relationship for OpenMenu and we couldn’t be happier to be part of Factual’s Crosswalk API.
DG: What challenges have you faced getting larger companies to use your API?
CH: It’s really about adoption of a new way to do things in relationship to menus, and that’s our standard. As OpenMenu grows so will the adoption of the standard giving larger companies more confidence that OpenMenu’s standard is here to stay and reshape how restaurants publish, and maintain, their menu and information on the internet.
As time goes on the fractured nodes of restaurant menus will find it harder and harder to maintain their menus to properly support their users and developers. This is when they will begin to look at OpenMenu and the OpenMenu Platform as an option for them. They need to stop worrying about the menu/restaurant data and focus on the solution they are providing.
DG: What’s next?
CH: We are going to continue developing solutions for companies who want to adopt OpenMenu and create better, more powerful tools for restaurants to become part of the OpenMenu Platform. Also, we will be transitioning the specification to OpenMenu.org and provide developers with more confidence in the standard.
It’s about moving OpenMenu forward to properly and effectively support both sides of the restaurant industry; restaurants and developers.