Saturday, January 30, 2016

Two Apps I'd Love to See

In the 1990s, I witnessed the dot com boom. The Web was clearly the way of the future. Thousands of dot com companies popped up, trying to replace market inefficiencies with Internet based technologies. Some companies did well, other's, I joked, lost money on every transaction but tried to make it up with volume.

After the dot com bubble burst, Web 2.0 came along with user generated content and dynamic web pages. This was followed by the dominance of social media which killed print media as it connected more people on both personal and professional levels.

Today, the cutting edge trends are seen in mobile apps. ForeFlight has revolutionized the cockpit as much as Uber's changed the car service industry. Twitter and Facebook have seen increased growth after moving from desktop to mobile. Mobile, "always with you" Internet connectivity, along with GPS, creates a lot of opportunities.

Here are two mobile apps that I'd like to see, and I wonder when they will come.

Bluetooth Beacon Heat Maps

Why is it I can see rush hour traffic on my map apps but I can't see how many people are at a restaurant, bar, or nightclub? Map apps have been displaying real-time traffic for more than a decade. These apps don't require crowdsourcing the data. Sure, Waze can help, but the DOT has cameras set up on roads and highways; they have all the data they need. So, what's stopping the same kind of heat map for a Yelp venue where our Bluetooth enabled phones provide the source of the data?

Ideally, I'd love to see a wireless provider anonymously license its subscriber GPS data so I could see how empty or packed a bar was. Even better would be if they could include simple demographics such as age and gender. But, I realize this might be a bridge too far, not to mention that people would consider it creepy.

Having patrons check in at a venue won't work. An alternative solution would be to have Bluetooth beacons ping patrons' smartphones. Let's call it a beacon cookie. The beacon cookie doesn't even need to connect to a person's phone. All the beacon needs to do is ping a person's phone for their Bluetooth address (BD_ADDR). Discovery mode is ideal for this, but not practical. Perhaps a passive discovery mode? Over time, people's Bluetooth addresses could be matched to profiles much like DoubleClick with anonymous cookies. Now we'd have interesting demographic data to use, even if it's only for a venue heat map. Google knows a lot about me in the virtual world (that's why, when I search for something on Amazon, I see related ads in my Facebook feed), why not apply that same data to brick and mortar stores via Bluetooth beacons?

One Meal, One Transaction

In this day and age, I'm surprised that restaurants still need to process a customer's transaction twice. First, for the full price of the meal, and second for the tip. This is a different situation than a gas station which needs to run an authorization, to see if you have enough credit, before pumping the gas. At a restaurant, the customer has already eaten the meal by the time they're presented with their check.

How should the restaurant payment process work? Instead of the food server bringing over a paper receipt, s/he could simply present a QR code with a UUID for the receipt. The customer would scan the code and see their detailed meal receipt with tip and payment options. At this point, the receipt is linked to the customer (much like Uber). Even better, why wait until the end of the meal to scan the meal receipt's QR code. The QR code could be presented by the food server at the beginning of the meal. As the customer orders more food, it shows up in real-time on their phone. At any point, the customer could walk out and, like Lyft, they could complete the payment anytime within 24 hours, otherwise it would automatically be processed with a default tip (say 18%). What's more is that everyone at the table could scan the same QR code and then, at the end of the meal, they could choose what they ate and split the check so that everyone pays for only their food.

I'm sure there are apps that do something similar to what I'm describing, but I'm not aware of any that are mainstream. These apps wouldn't have to be created by a single company if a public API is developed for secure data interchange. We only need one holistic system to make it work.

No comments: