A few weeks back, I wrote a post contending that, as traditionally defined, the term unified communications has no meaning. Since then, I have had many interesting conversations with people who have varying opinions on the subject. This post is to pass along some of what I have learned.
Un-unified
In alignment with my contention, most of the conversations on the subject have confirmed that when someone in a work situation needs to communicate with someone who is not within earshot, they typically use tools that are very, well, un-unified. If we need to talk to someone, we call. We still email as much as any other modality. Second to that, we text and increasingly group message. If we need to share or collaborate on information that is in a document, we webchat. Begrudgingly, we occasionally video chat. A few people do use a single tool for these functions, but more often we choose between a set of tools—applications that are specialized to the task at hand.
The elephant in the room is that there is a disconnect between the aspirations of the companies that are considered part of the unified communications industry and how customers use the products they sell. The term unified communications evokes a mental image of the mythical “single pane of glass.”
Single pane of glass
Although “single pane” may be a great marketing term, in practicality it applies less to the UC industry than it does to other fields. When such a single pane exists, where users see a unification of communications applications, various services, and other applications, traditional UC companies usually play more of supporting cast member roles than that of star of the show.
In many cases when a single pane of glass deployment exists, it is a function of some type of core application. Two examples are customer relationship management (CRM), such as Salesforce.com, or an enterprise resource planning (ERP) system, such as SAP. Although the user may toggle to other system windows during their workday, it is in these panes where the worker spends most of his screen time. It is in the ideal deployment where the UC application is plugged in or exists as a widget to the CRM or ERP application.
Take, for example, CRM. In enterprise organizations, the primary purpose of a CRM application is to give insight into the customer journey and to provide tools to support employee engagement into the customer’s journey. As a customer browses a website, makes a purchase, awaits delivery, seeks post-sale services or any number of other events where the customer “touches” an organization, the CRM system is intended to record, organize and make actionable the information about those touches. Not only should inbound communications be captured in the CRM as part of the information about the customer journey, ideally all communications with the customer should be captured. Plugging UC into CRM makes sense in maintaining a holistic record of the customer journey.
Among the ways that this tie-in is important is when a salesperson, customer support representative or other employee needs to contact a customer. In the best of deployments, the employee would use information from the CRM system for that contact. In the case of a phone call, the employee should be able to simply click on the number or a screen icon within the single pane of the CRM application and the system would dial. Here is where an important value of the single pane exists.
Unifying the customer journey
For the customer journey “chain of care” to remain whole, businesses shouldn’t want that phone call to take place untethered to the CRM systems. A reason why is that when an employee dials the customer’s number on an un-unified application or appliance, information about the call is lost, as is the ability for the company to employ compliance measures such as call recording. Employee mobility and the fact that customer relevant information might exist outside the enterprises systems, such as on the employee’s mobile device, is yet another challenge that this approach combats.
Instead, when the UC application is “unified” with the CRM system and the employee executes the phone call through the enterprise system, the customer journey chain of care remains whole and the enterprise’s best interests are protected.
The aspirations of firms considered as offering UC applications (by the traditional industry definition) often compete against the model just described. Traditional UC vendors try to reverse the dynamic. They present a user interface intended to be more attractive—a single pane of their own making that pulls in elements of the customer journey to the UC interface.
Admirable as these attempts may sometimes be, fundamentally they run upstream against the ways many enterprise organizations arrange work. CRM and ERP are mission critical, whereas there are many ways to make a phone call.
Hedging their bets, traditional UC players also make efforts to coexist. A visit to the Salesforce App Exchange, for instance, shows that as of this writing, there are 72 telephony integrations of UC components for the platform. Most of the major vendors are there, along with an industry of companies that create applications making UC features available from within Salesforce.
The hard truth
As the application programming interface (API) economy grows and telephony moves further away from being a concept that is distinct from other software elements, the term unified communications will continue to morph and further lose relevance.
The “D-word” (disruption) is thrown around a lot today. In few industries is disruption more apparent than in unified communication. The hard truth is that in the UC industries, those who fail to understand where they exist in this new technology ecosystem risk being “Ubered” out of existence.