What Do Mobile UC and Hotel Alarm Clocks Have in Common?

It is no secret that some companies have thrived in the transition to mobile while others have floundered. That transition has also given rise to entirely new and transformative business models like Uber, along with untold piddling failures. Among the latter are the UC&C vendors who while they love to extol the importance of mobile and wax eloquent about the importance of the user interface, still have had absolutely no success in tapping into that opportunity. However, there is one industry that has missed the boat on mobility to an even greater degree than UC: hotel alarm clocks.

When the whole mobility thing started, hotel alarm clocks were simple, cheap, single function devices and everyone used them. Then Apple introduced the iPod and followed with the iPhone, and someone decided they could sell hotels more expensive alarm clocks that could play music from the guest's iPod or iPhone. These new clocks first showed up in high-end hotels, but as the price came down eventually every hotel went for them.

There were two very important outcomes from this shift to fancier alarm clocks. First, almost no one used them to play music - if they did so it was typically only once. As it turns out, even though the clock was fancier, it generally had one 2-inch speaker so the sound quality was akin to a 1960s-vintage AM transistor radio. If the guest wanted to listen to music, they just used their headphones.

The other byproduct was that the clock was now so complicated that no one could figure out how to use it as an alarm clock! They couldn't set the thing, either, if it had the wrong time. Since guests were only going to be staying in that hotel for a couple of nights, no one was going to invest a lot of time in figuring out how to make this dopey thing work. So the new clocks fed a major resurgence in the use of wake up calls. So on a positive note, the alarm clock fiasco generated a spike in use for yet another anachronism of times past, the hotel phone (probably the only calls made and received on it that day), but that's a subject for another article.

Irony of ironies, in September 2012, Apple introduced the Lightning connector on the iPhone 5. Of course, all of these fancy hotel clocks had the older 30-pin connectors. So now, the alarm clocks that couldn't be used as alarm clocks couldn't play music, either, on any Apple devices going forward. You could start carrying a 30-pin to Lightning converter, but that would leave your iPhone tottering on top of the clock. ShoreTel ran into the same problem with their ShoreTel Dock for iPhone/iPad endpoints and eventually introduced a model with a Lightning connector.

The hotels took a different route - they bought a new lamp. Yeah, they bought a lamp that had an electrical outlet in the base so the guest could plug their iPhone in next to the bed and use the alarm clock in the phone - goodbye wake up calls (and the last reason to have a phone in the hotel room). By this rather circuitous route, the hotels learned what their guests really wanted: an alarm clock they knew how to work. They also wanted access to their smartphone as soon as they woke up in the morning, but that shouldn't have been a surprise to anyone.

The UC&C guys stumbled through a similar set of misadventures in their mobile offerings, but for somewhat different reasons. Interestingly, the UC vendors' first foray into mobility, simultaneous ring, was a raging success. Avaya was the pioneer with this, but I don't know how proud any of them should be, because if you look at this capability objectively, what you're doing is effectively getting the call out of the PBX and onto the phone people really want to use. Technically the call is passing through the PBX (tying up two trunks for the duration of the call - one, if the call is originating from a station on the PBX), but the way the user sees it, they're just able to get their business calls delivered to their mobile phone, which was 99% of what they wanted.

Working from the flawed assumption that the user actually found some value in being "connected" to the PBX, the UC vendors all moved on to the moribund mobile UC client. In this adventure, the PBX/UC vendors were essentially forced into an inferior solution as the phone manufacturers didn't allow them access to the phone's native dialer. So absent the ability to deliver a user experience that the users had already endorsed, the UC vendors had to go with Option 2.

Option 2 was to build an app with its own dialer that the user would have to open, select the contact (or dial from the keypad), click "Call" and the app would send a signaling message on the data service to the PBX which would dial the user's mobile number (in some cases the user would actually have to manually answer that call) and the PBX would then call the contact and hook to two connections together. Once again we're tying up two trunks for the duration of the call, but now for outgoing as well as incoming calls.

Some implementations offered the option of placing the call over a Wi-Fi or even a cellular data service, which is all but useless now that we have cellular plans that include unlimited talk and text. A few even allowed the call to start on Wi-Fi and automatically transition to a cellular connection if the user moved out of the Wi-Fi coverage area - sometimes.

This idea of opening a separate app to place business calls had all of the appeal of an alarm clock nobody could use, and the additional features it could provide like presence and mobile number privacy came nowhere near to justifying the aggravation involved in using the mobile client. If the PBX/UC guys could have implemented this capability while using the native user interface, it very well may have hit the mark.

The other problem was the declining use of voice and the ascendance of text - two other phenomena driven by the shift to mobile. Since the people grinding out the UC stuff were at heart "PBX guys," they focused on phone calls. In the mobile space, text is far outpacing phone calls as the medium of choice for most communications, but you wouldn't expect "PBX guys" to catch the significance of that. The mobile UC clients can exchange texts with internal users through the PBX/UC platform's text capability, but only a few can interface to SMS (the one public [i.e. "inter-company"] text option whose volume is declining) and none of them integrate with the fast-growing OTT messaging systems like Apple Message or WhatsApp.

While I'm typing this, I'm sitting at a conference and there's yet another UCaaS vendor talking about the importance of mobility (no argument there), how attached people have come to their mobile devices (definitely no argument there), and is trying to tell us that they have a great mobile client that's just what the doctor ordered (big disconnect on that one).

To get up this morning, I wonder if he: a) used the hotel alarm clock, b) left a wake up call, or c) used the alarm clock in his phone that was plugged in next to his bed. I know which one I used.