Beyond Unified Communications: Optimized vs Unified
Just like my previous projects, as we first designed TEN DIGIT, one of my first jobs was to pick a use case to drive the architecture and design. By starting with the simple idea of “how can we text enable a call center”, we quickly found that it was more than just text that was transformational to customer contact. The facts that text came from smartphones, and smartphones came with other habits and functionality, were hard to ignore. As we thought about the use cases we could pick, the additional functionality of the smart phone always yielded positive impacts. So, even before we thought about the use case, it was important to take a look at the foundations themselves. How far did the basic functionality of a smartphone, were we to depend on it, make a difference?
The first difference to appear between smartphones and traditional communications was that in polite society, we would often text before we would call — sometimes to see if people could talk, but just as often in replacement of the call itself. I call this new behavior, to text before we call, as the modern call model. This felt like the first break from unified communications, as this behavior begged for preferential treatment of some modes of communications over another. As a Ruby on Rails developer, I had seen something like this before: Rails supports convention over configuration. Instead of aiming for the ultimate in flexibility (you can do anything!) by providing a blank sheet of paper, it made more sense to fill in the blanks as to what most people would want, and then providing hooks for flexibility for the minority of cases. The practical examples are legion. For instance, cross site scripting is a well known vulnerability of web applications. Traditionally, frameworks would not provide this functionality, as the predominant thought was that there were bound to be differences and improvements, so why lock yourself in? Rails showed the web development world that not accelerating 98% of implementations for 2% implementation flexibility was a bad trade. It was simply far more effective to take the default than it ever was to ask for flexibility.
The same situation exists in unified communications: we have a large number of communications possibilities, yet people have a very clear preference. Yes, a company has to handle voice, faxes, messaging and sometimes video, but the large majority of actual communications has an opinion. We use smartphones, we prefer messaging, and we all have SMS. In this particular case, it was clear to see that if we optimized systems that started with messaging, then connected to other systems, the implementation path was not only much faster, but the efficiency gains are clear. We actually provide a better experience for our customers because we eliminate the friction between how they use phones, and how businesses use phones. This all comes from designing to an explicit opinion: use SMS first to start business communications.
More over, when viewed from a functional standpoint, it became clear that when you could design for the smartphone, traditional communications problems and solutions we all take for granted are in play. As one example, and there are many, consider authentication. We are all familiar with what I call “trivial pursuit” authentication: the last four of my social security number is 8765 and my mother’s maiden name is Baumgartner. We use these methods (unthinkingly) every time we call our bank. However, consider the happy smartphone user. They could send a selfie in a text message to validate their identify. Language independent, stronger than trivia and appropriate for discrete situations, it is a big step forward for the user. For the company, it’s more efficient and more friendly.
And, unless you happen to be carrying a smartphone, hard to pull off. Try it with a browser, it’s hard. Try it with a landline, it’s impossible. But if you are carrying a smartphone, and we basically all are, it’s quick and efficient and friendly. When you consider all of the features that were designed for landline phone — IVR, authentication, transfers, voice mails and on-hold — in the time of the smartphone, there’s a large amount of pain to be removed from business communications.
In order to achieve these kinds of improvement in customer experience, all we need to do is to acknowledge that we need to optimize for the form factor of our customers. Just like Rails shows us, convention is more important than configuration. And in communications, we have a convention, and it’s called the smartphone.
