Unified Communications is a name for functionality

admin — Tue, 23 Mar 2010 21:19:23 GMT

Marty

Posted: Tuesday, December 15, 1:52 PM

Joined: 1/13/2007
Posts: 2

It doesn't matter so much what we call it, but what UC does. Thus, our definition of UC as, "Communmications integrated to optimize business processes" is about how UC creates benefit (through integration) and about the result (optimized business processes). Any number of technology elements, from the dozen or more new communications functions that have emerged, can be combined to create a UC solution, depending on the problem that is being solved. But the point is that an improved business result is being created. So, look at our the industry case studies and the definition of UC will become prett clear. Visit the Case Study Library here: https://ucstrategies.com/unified-communications-case-study-library.aspx

Pam Avila

Posted: Monday, December 21, 1:57 PM

Joined: 7/16/2008
Posts: 17

Yea, Marty! Thanks for not getting hung up on what UC is - but rather emphasizing what it does!

Art Rosenberg

Posted: Thursday, December 31, 12:00 PM

Joined: 1/16/2007
Posts: 16

I agree with your view of UC as a means to optimize business processes, but that only describes the objective of the technology (the "Why of UC"). It provides the important business justification for supporting end users in their specific roles in a business process. The "How of UC" then becomes important in terms of functionality at the technology level and how it will actually be utiliized. That area is where I think further clarification is needed.

In my view the main "communication problems" that UC is aimed at are in initiating contact with a human being, who may or may not always be "accessible" in all modalities of communication or "available" from a time and priority perspective. Mobile users exemplify the first challenge of selectable accessibility, where a recipient may or may not be able to always talk, listen, read, or type to communicate. Further, it doesn't have to be a particular individual that must be contacted, but any person who is qualified, accessible, and available, as in tradtional customer contact centers.

It goes without saying, the contact initiator doesn't have to be a human being too, but can be any automated business process that needs to notify or deliver important information to a human being. It is also obvious that a business process will be exchanging informational messages, not trying to have a voice conversation with a person. However, message exchanges may be exploit speech if necessary.

The flexibility of UC for communicating with a person should not be limited to selecting one modality of contact for communicating, but must allow for easily and dynamically switching from one modality to another, e.g., asynchronous messaging (text, voice) to instant messaging to conversational voice to mutli-person conferencing. Too many people think UC is only about telephony capabilities via IP telephony or VoIP connectivity, but those are infrastructure and application server considerations that must support what the individual end users really need at the moment.

End user needs should actually be broken down into two functonal categories; their needs for initiating a contact and needs as a recipient of a contact. Obviously, that covers a lot of different functionality that must be kept simple and endpoint-device independent. With all the form-factors and capabilities of new mobile "smart-phones," that is not an easy challenge. However, the mobile user is the one who really needs the flexibility of UC the most!