“Contextual” Contact Notifications Must Be Unified

If you think about communication contacts with people, you must also consider their role as “recipients” of a contact, whether the contact is a real-time connection attempt, an asynchronous message from another person, or from an automated business process application. Until now, business communications has been heavily focused on the contact initiators, because that is where communication activity originates. This is true whether it be a person making a phone call, sending a message, etc., or, increasingly, an automated business application sending information or a message to an end user. In either case, we have been primarily trying to make contact initiation more efficient by dynamically providing contextual contact information and determining what mode of contact might be best for the recipient in order to minimize and simplify the efforts of the contact initiator. I discussed this perspective of what I called “Contextual Contacts” in a white paper I wrote for Microsoft when they were starting to get into UC at the desktop.

With legacy desktop phone systems, this involved guessing about the physical accessibility and location of the recipient, whether at an office extension, a home number, or another location. With increased use of cell phones, the next concern was recipient “availability” to insure a call attempt would be successful and not result in “voicemail jail.” That’s where IM and “presence” information have started to become useful as a prelude to a real-time voice or video conversation, where IM availability could start with chat but then escalate to a voice connection. But, as more forms of messaging information become exploited, including social networking, it is now becoming obvious that selective “notification” management must be more unified for recipients to optimize their accessibility and time. I guess this would fall under the label of UC-U, which benefits end user productivity.

I recently signed up to use a “spam blocker” feature on my email service, which filters out “known” spam and also screens out “suspected” email because they originate from contacts not currently in my address list. “Suspects” are notified that their message has not been delivered because they are “unknown,” and invites them to send a response message identifying themselves to the recipient. The “spam blocker’ notifies me whenever there are “suspect” messages (that I can review and also sends any responses from the message originators clarifying the purpose of the message. I then have options to accept the suspect message and add the address to my list.

Aside from the screening information that will be needed by recipients, the mode of real-time notification must also be an option that is dynamically controlled by the recipient and dependent on their environment and end point device they have available. This where mobile multimodal endpoint devices can provide the basis for flexible recipient control of contact notifications, whether it is a phone call, an IM request, or any form of asynchronous messaging.

With UC-enabled smartphones and tablets, I expect that the old “voicemail” may not be the only alternative to a failed direct voice connection. A good example of this type of flexibility is the increasing use of “voice messaging-to-text” for callers to leave a voice message that can then be optionally retrieved in text or voice by the recipient. However, just as one can “escalate” a contact from email to chat to a voice or video connection, a voice call attempt could also be shifted to chat or some other form of messaging by the recipient. With the increased use of “presence” information as a precursor to any  call attempt, the “caller’ might easily end up with a messaging action when the recipient is not available to talk.