CallingTab 2.0 — A Pivot away from a Hardware Product

Part 1 of 2

CallingTab 1.0 — the backstory

While traveling for work in 2014, my team and I stopped for dinner at a nice restaurant after a long day. It was already 10PM and only a few people were around the bar. The polite girl at the desk asked us where we would like to sit. We chose to sit outside–since it was a beautiful evening and we had been indoor almost the whole day.

Sitting outdoors at 10PM at a big restaurant where the hostess was busy with other guests and preparing to close was a mistake — mistake number #1. We were one of the only two occupied tables sitting in the outside portion the restaurant. Between giving us menus, taking our orders, bringing drinks, serving the food, checking how things were, and getting the check, the server could only stop by to check on the tables once every 10 minutes or so. Sometimes we didn’t need her attention when she stopped by; sometimes we would have to wait 10 minutes to request something small.

The time spent waiting for our hostess made my mind tickle. Being the man I am, a consultant and a perfectionist, if I see a problem (anything that is not 100% efficient), it needs a solution.

The problem that night was:

Why can’t there be a simple button on my table that could get my server’s attention? Why do they need to interrupt what they are doing to periodically check on our table? Why aren’t they available when we really need them?

Instead of just enjoying dinner and going back to the hotel to catch some sleep, I decided to find a solution to the problem. And there it was — mistake number #2 of the evening.

After digging for a couple of nights, I came across a few products that solved this exact problem. It was a mini-eureka moment! Typically, I would attempt to build the solution. But I convinced myself that this time instead of building a new solution, I simply had to sell the solution.

I contacted a few manufacturers in China, spending a few weeks back and forth between international shipping. Eventually, I tested products from two vendors. I showed some images and a prototype to a couple of restaurants. Their response was positive — One potential restaurant agreed to pilot the prototype before it was even ready! After three long months into the process, a manufacturer and I agreed on the final products, a price, and my branding of the products. The money was wired, products were manufactured and shipped, being branded as “CallingTab”.

Image for post
Image for post
CallingTab v1.0

CallingTab consisted of two types of products:

  1. Transmitters — table-tabs to communicate when customers need servers at their table, and
  2. Receivers — display units and smartwatches to show the waiters and their managers that a table has customers that need attention

Table-tabs are what the customers would see on their table and use to request service. I re-branded the transmitters as “table-tabs” since they were part of the CallingTab brand and went on the table. I had the manufacturer enable the table-tabs to light up any time a button was pressed. The final product had three buttons, “Order”, “Pay”, and “Cancel”.

Image for post
Image for post
Image for post
Table-tabs — buttons on your table to order or request a check

CallingTab Display Units showed the table number requesting service. The display units chimed and had a colorful flashing LED backgrounds to attract attention. This was useful if the restaurant was too loud, or if the chimes were set to be silent.

If multiple tables had requested service, the display would cycle through all open requests. One table tab device could be paired with multiple display units. For example , if one display unit was near the register and one was near the kitchen, all display units would see the request.

Image for post
Image for post
Image for post
CallingTab Display units - show the table number requesting service

The CallingTab Smartwatch — flashed the table number requesting service and worked similarly to the display units. With these smartwatches, servers could pair them to only to receive alerts from their tables rather than the entire restaurant.

Image for post
Image for post
CallingTab Smart watch —shows the table number requesting service.

Once the shipment arrived, I had the products professionally photographed, the website prepared, and eCommerce set up and tested. I was ready for my launch.

But as they say, launch is just the start.

The trial started at one restaurant with a central display unit, 10 table-tabs, and four smartwatches. I hired an assistant to call nearby restaurants and a salesperson to make the in-person visits to restaurants to try to sell some units. But then within a few days, I got a call from one of the pilot restaurants.

“Hey, one of the table-tabs is not working.”

I rushed around and eventually figured out the battery that came with the products was dying within a few days of use. I replaced the batteries of all table-tabs at the pilot restaurant and gave them an additional central display for free.

Three days later, I got another call

Pilot restaurant: “We tried using the system but it’s not reliable. It’s becoming a headache for us to use.”

By the time I reached the restaurant to troubleshoot, it was too late. The equipment was unplugged and loosely packed in a bag, ready to be picked up.

Mistake #3 had finally caught up to me. Some situations demand not only accuracy, but also precision. During testing, I had noticed that if you pressed the “Call Waiter” button 10 times, the CallingTab Display unit would only receive the message 9 times out of 10. Admittedly, the system was not 100% reliable. Even though I had selected the more reliable of the two vendors and tested the products, that was not good enough.

In the back of my mind, I knew this problem existed. But the idea was to still showcase the units and test the products in the market. No amount of customer research was going to provide the required insights until trying it out in the field. Try explaining an iPhone to customers before it had been launched!

In the end, we stopped taking new orders, refunded restaurants who had similar problems, and decided to move on.

Key Lessons from CallingTab 1.0

  1. Quality is not just important, it’s paramount This is especially true if it is part of the MVP flow. The core MVP features must work reliably and precisely.
  2. UI/Form factor matters I showcased three different versions of table-tabs to customers. 70% of them first reached for the rectangular black table-tab just because of its form factor. Also, I had the manufacturer put LED in the table-tab to make it light up on every button press. It now responded in a visible way to customers and that improved overall user experience.
  3. Users need feedback Even after the LED was added, the table-tabs were only one-way communication devices. There was no feedback received back from the central displays. The customer had to trust that their waiters must have received the button-pressing signals. This takes away from the customer experience and introduces unnecessary anxiety to the customer journey.

When all is said and done, if there is a problem, try to solve it. At best, the problem will be solved; at worst, you will learn a few things along the way.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store