Building the Pingup mobile-optimized booking API
by Mark Slater

Over 2 years ago, a small group of us got together with the mission of shortening the distance between a consumer and a local business. The proliferation of smartphone technology presented us and many others with an innovation plane not seen in many a year (if ever). We felt strongly that the way we interacted with businesses (phone calls primarily) was outdated and that the mobile macro-shifts presented us with an array of arrows to fire against the proverbial innovation wall.

Our first volley was to connect the two participating entities with a chat platform. “Texting” and “chatting” were firmly established dominant behaviors on smartphones and we believed that we could leverage this and point it at businesses. The challenges were two-fold: the first was our ability to ensure a timely response from a business to a consumer’s question, and the second was supply-side scale. For it to be useful, we would need hundreds of thousands of active and responding businesses nationwide. We didn’t want to pretend. We did NOT want to be a virtual concierge – we did not want to dupe people into thinking that they were chatting with a business, when they were really chatting with a call-center on foreign shores whose mission was to go and find the answer in an analog way once the question was posed.

Once we’d built the chat framework we raised capital and began to onboard users and businesses in the Boston area. It was during these early onboarding days – about a year ago – that we discovered something amazing…

Close to 80 percent of the time, users were asking questions around scheduling. They simply wanted to either order an item or schedule a service. They did not want to “chit-chat,” and they were only rarely asking about specific product availability or details. This was only mildly interesting except for the fact that during our outbound calls to businesses, we discovered that a good amount of them were using scheduling software of some kind. In essence we had a situation emerging where the dominant use case of the app was met on the supply side – in some instances – by software that the business was using to manage the inbound dominant behavior.

We realized we had an opportunity and quickly split into two groups – the business development team was tasked with mapping out this scheduling software landscape, and the tech group explored the beginnings of scheduling flows that could be deployed through APIs.

Our findings were fascinating. There was this astonishing fragmentation that existed on the supply side of our hypotheses – a fragmentation that at last count exceeds 70 different software companies – all selling scheduling products into any manner of small, medium, and large businesses. This was in North America alone. Furthermore we surmised that the market – the amount of businesses that have and will adopt scheduling software – is vast, in the many millions actually. Plus, the adoption of this software was accelerating – some of these companies today are growing at 10% per month (net).

But we began to get really excited when we looked at the demand side of the market. Sure there were website widgets driving bookings in to most of these SaaS platforms, but there was no marketplace – no single booking application, no destination that consumers were gathering around. We were convinced that this fragmentation was a contributor to the absence of this capability being available to the consumer in an aggregated way, but we were not convinced that the existence of a single purpose or “booking app” would gain traction given the relative infrequency (booking being more of a monthly than daily or weekly habit) of the action being proposed. It was and continues to be harder and harder to get user share on an app, and we believed that unless the action was a daily or weekly required one that the chance of a user forming a habit on a booking app were slim and the cost associated onerous.

When building our own booking app, we also realized that in many ways we were re-inventing aspects of “directories,” and other local business listings networks, as a necessary means of helping users find and discover the live-schedules of businesses in our network. While we felt our own app could be notably simple in comparison to these other business listing communities, we weren’t explicitly interested in competing with these other established players. In fact, it occurred to us that we’d be much happier to see a book button on every business listing out there – mobile and web – rather than users having to discover and download our app. What we had built was a scalable infrastructure that called for the greatest possible exposure to customers looking to schedule business transactions – an impressive feat of “plumbing” with more potential than simply the backend of single booking app.

So as the company moves into its next phase of evolution, and as we get ready to become the leading booking platform API, a quick look over our shoulder represents a fascinating moment of reflection on our journey and perhaps a cautionary tale for entrepreneurs trying to find their feet.

We as a company and as a culture embrace change – we look for it in every feature we discuss – we try not to be too stubborn as to not see the opportunity when it comes along. Failing fast is in our DNA at this stage. Our founding mission remains in tact – we are still shortening the distance between a consumer and a business – how we do that is radically different to what we thought starting out…and thats just fine with us.

We believe today that we are the first and largest aggregated mobile-optimized booking API that will power a whole new transaction layer into local business listings wherever and whenever a user encounters them.



Related Post