Hotels are complex. There are many areas that must be mastered every day, without fail. Each department, from revenue management to housekeeping to maintenance to the front desk, must work in concert to deliver a consistent guest-facing experience. Without each working well, a hotel becomes dysfunctional, with reduced revenues and inefficiencies creating an unprofitable asset for the hotel owner.
Without technology, a hotel risks being left behind as far as the expectations of both profitability and guest experience. Yet there’s a dark side to this proliferation of hotel technology — the feeling that the technology is running the hotel and not the hotel running the tech.
This is the core theme of tnooz’s latest hackathon, being held this weekend in Austin at HomeAway HQ as part of the HEDNA conference. The mission is to craft a better hotel experience across the back office, front office, and pricing/revenue management components.
Our presenting partner is SnapShot, which provides an API that allows hotels to build a customized tech stack that is interoperable by making it so third-party apps can connect and communicate. To explore how this API was developed, we chatted with Dominik Pinter, SnapShot’s VP of Product, and David Turnbull, SnapShot’s co-founder.
Hotels have complicated technology stacks. What is it about hotels that make for this proliferation of technology tools and services?
David Turnbull: The operations behind effectively running a hotel are extremely complex – from taking reservations, managing transactions, figuring out the right distribution channels and rates for inventory, understanding your marketing campaigns and website performance, interacting with guests before, during and after their stay, cleaning and preparing rooms at the right times, managing F&B, and more.
And hotels are using different software to manage and track each of these things because there is a major integrations problem in the industry. We have legacy systems that do not connect to other systems and come with long sales cycles and complicated integrations processes.
Dominik Pinter: On top of that, technology is moving faster than ever and is completely changing the way we live our daily lives, including, of course, how people find and expect to interact with hotels. We have talked to hundreds of startups that are developing applications to help hotels leverage new technologies – they just struggle with the integrations pain.
SnapShot was created in part to help hotels manage this proliferation. Tell us about the company and why it was created.
David Turnbull: SnapShot was founded with the goal of killing the spreadsheet. We wanted to consolidate all hotel data on one platform so that hotels could quickly understand it and use it to improve business. We did this by aggregating and structuring hotel data on one data platform that now has 40+ PMS integrations and data from 6000+ hotels.
We’ve built a range of solutions, from simple applications to a customizable enterprise data warehouse as a service solution (SnapShot on Demand), making SnapShot perfect for properties of all sizes, from independent hotels and hostels looking for simple analytics, revenue management, and pricing tools to large hotels and chains looking to build their own interfaces.
On top of that, we have a Marketplace where hotels can easily find pre-integrated applications, as well as an API that allows developers to build and sell their own applications.
Dozens of developers are already working with our API to build apps for the SnapShot Marketplace, and we anticipate the Marketplace to soon become the one-stop- shop where hotels can find the software they need to best run their business.
Creating an API has become an essential piece of growth for many businesses. What was the process of deciding to build the API? How did you get started?
David Turnbull: We are well-aware of the lengthy and painful process of building PMS integrations. We wanted to remove that hassle for developers and to give hotels easy access to new software.
Since SnapShot had already built these integrations, it made sense to develop an API for developers who need this data. Ultimately, we want the hotel industry to be innovative, and that can only happen when developers are able to focus on their products rather than on building custom integrations.
What are some of the hardest parts of building out an API? Is it deciding where to start? Is it understanding the problems of the customers of other companies that may use the API?
Dominik Pinter: The hardest part is figuring out when to expose which APIs. We want to choose the right APIs to expose first so that we attract the most developers to our platform.
To do this, we must understand the endpoints that developers need and all the different use cases for using the API. Also, knowing that once we release an API, it is out there – we can’t take it back or change it because we would risk breaking the functionality of all the apps that use it.
One an API is built and deployed, the next step is marketing and supporting the API out in the wild. What have you learned as far as promoting an API to potential partners? And how much of a challenge is it to provide customer service to developers across a variety of use cases?
Dominik Pinter: The first big learning is that our API is attractive to many developers! We’ve had high demand so far, which is really exciting. Second, we have found that we need to be very specific and precise in describing what we offer. Phrases like, “we have reservations data” can be interpreted in many ways.
When we first start talking with a new developer, we want to make sure that we are all on the same page, so instead of just giving them access to our developer portal, we have both technical teams talk, and in parallel, both commercial teams also talk.
As far as support, we have found that our developers don’t typically need much handholding once these initial discussions have happened. We attribute this to our developer portal and the fact that we have built APIs according to generally accepted standards. Still, we do provide a sandbox environment and have a dedicated team available to answer questions and provide a great customer experience.
SnapShot has a unique model of making it possible for developers to integrate among many technologies that hotels use. What are some of the most interesting applications of the API you’ve seen so far?
David Turnbull: The revenue manager side of me really loves Climber, which is a revenue management tool that uses machine learning to deliver intelligent pricing in real time, and Enigma, which is a fully automated BI application.
Dominik Pinter: Those are some good ones. I also really like StayDelightful and BookBoost, which have developed communication tools for hotels to better engage with guests. And KePSLA, which has some innovative technology to help hotels manage their online reputations.
SnapShot is presenting the tnooz hackathon in Austin this month, where developers will be building new solutions for the hotel industry. Which areas are ripe for new tools? If you could suggest a few areas for developers to consider building over the weekend, what would they be?
David Turnbull: I’d really love to see some pricing intelligence apps that consider external factors like weather, events, flight patterns and other items.
Dominik Pinter: In addition to our API that exposes reservations and transactional data, we are also releasing our Fabric API for this hackathon. Fabric is a hotel communication tool (think Slack, but for hotels). This API allows developers to read and send information to and from Fabric native messaging and is great for developers looking to develop chatbots, automate communication, and analyze messaging within Fabric. I’d love to see this API put to use in an innovative way, eg. for a guest experience app that automates requests from guests to hotels.
Powered by WPeMatico