Pages

Total Pageviews

Tuesday, May 27, 2008

UC and Voice Message Delivery

May 27, 2008

Will UC Change Traditional Voicemail MWI and Message Delivery?

Art Rosenberg, The Unified-View

Back in the early days of voice mail, there was a challenge to integrate voice messaging capabilities with proprietary telephone systems. Such integrations concerned enabling the voice messaging system to interoperate with the telephone system in the following areas:

1. Forward calls that did not answer after n rings to the voice mail system (Ring, No Answer) or if set to forward immediately

2. Enable the voice mail system to turn on a Message Waiting Indicator (station set light, stutter dial tone) to notify the device user that there were one or more voice messages waiting to be retrieved.

Back in those early days, however, telephone systems were very “closed” and integration was not readily available. In particular, those phone systems controlled proprietary desktop station sets completely. As a result, early voice mail system developers like Octel had to overcome such integration problems by reverse engineering and emulating proprietary station sets in order to integrate their voice mail systems with those telephone switches.

The problem with the MWI function of the telephone switch, which was usually an indicator light on a telephone set, is that it didn’t tell you too much about the waiting messages, i.e., how many messages you had, who the senders were, the urgency of the messages, etc. Only after the message recipient called into the voicemail system, was some of that information given.

With the growth of mobile devices, “push messaging” notifications and delivery have become practical for all forms of messages (voice and text). What started out with voicemail's outbound delivery of voicemail messages, also enabled email messages to be proactively delivered in real-time, using text-to-speech” technologies under the label of unified messaging (UM). Then email became proactive by moved to “Push email,” inaugurated first by RIM for their enterprise mobile Blackberry servers, then followed by Microsoft Exchange. Now that mobile devices are converging all forms of communications, i.e., becoming “multimodal” under UC for both messaging interfaces and message content, it is time to revamp old voicemail methodologies, especially when your voicemail system is reaching it's end of life!

It has always been very inefficient to retrieve important voice messages because the early voice mail systems played back voice messages in sequential order, since they did not have a visual interface for random access retrieval. The first such capability for voicemail took place with the early desktop integrations with email, where extensions to email software clients included the display of voice messages and online access to the voicemail system to deliver the voice messages through the desktop phone. This was part of the early approach to Unified Messaging (UM). The question now is, do we really have to retrieve and reply to voice messages with a voice interface?

“Visual Voicemail” and Voicemail-to-Text Messaging Services Bringing More Change

As I have been reporting in the past, speech recognition technology is upsetting the traditional voicemail apple cart by removing the constraints on retrieving voice messages through inefficient legacy Telephone User Interfaces (TUIs). This new approach allows a caller to use the phone to conveniently and efficiently leave a voice message as with a traditional voice mail system, but the message recipient doesn’t have to retrieve the message in it’s voice form. With more people using personalized mobile devices, the convenience of voice input for messaging “on the go” will always remain high.

However, no longer will the voice message recipient be limited by the lack of selective, random access to voice messages. What was originally provided only at the desktop through unified messaging (UM) integration with email, has now moved to mobile devices like Apple’s iPhone as “Visual Voicemail.” But, even that has been improved upon by enabling the recipient to also more efficiently “see” voice message content as text, rather than be forced to navigate blindly through voice content and transcribe any important information manually.

This capability to see voice mails in text form will be particularly useful for mobile users who find themselves in a noisy environment or where they have to be “quiet” (e.g., in a meeting or public venue). “Voicemail-to-text” messaging will also speed up the screening of voice messages, since traditional voicemail systems don’t even ask for a “subject line” like email, and even then such information might rarely be accurate.

In addition to those reasons for retrieving voice messages in text form, exploiting a visual screen interface facilitates all UC/UM options of responding to a message by the message recipient, including:

· “Click to call” (or “Call Return” in voicemail systems)

· “Click to Chat” (IM)

· “Click to email” (Reply, Forward)

· “Click to Voicemail” (Reply, Forward)

Where speech interfaces are indeed necessary for hands-free/eyes-free environments (e.g., driving a car), the “Click to” actions will simply become available as intelligent "barge-in" interactive voice commands for initiating and managing calls or messages, rather than the legacy error-prone TUI interfaces that required memorizing complex touch-tone commands.

In the world of business UC we would expect that such new choices of messaging will also be governed by the practical use of presence/availability management. That is, if people are not “available” for a real-time contact, second prize will be a choice of messaging with immediate notification/delivery/response when there is time urgency involved.

What’s The Bottom Line For Business Communications?

What all this really means is that contact recipients will have greater flexibility in being able to respond to other people’s messages when they are just not “available” or “accessible” for a real-time connection. This will translate into faster messaging responses and faster “cycle times” for business process performance, While mobility and the flexibility of UC will increase a recipient’s communication “accessibility,” it will not necessarily increase their “availability” for real-time conversations. (But voice conversations may not be really so necessary any more in light of "real-time messaging!")

SIP–based, "federated" telephony presence management will also shift business calls from traditional “person-to-person” contact attempts to a “person-to-process-to-person” approach. This is where a real-time connection with anyone who is qualified and available can be automatically “orchestrated” by a business process application using presence management technology. This is what internal customer call centers have done for years with self-service IVR applications and telephones, but will now become part of all forms of business communication through both open online Web and IP telephony real-time services.

However, rather than waste time in a queue always waiting for a live person, callers can also take advantage of leaving a message (to identify why they are calling) and the ability for a business process application to screen such input and orchestrate a real-time response (callback or IM) “as soon as possible” when all parties are both “available” and “accessible” for a voice or video conversation This will make such real-time contacts more time efficient for both contact initiators and recipients, especially when they are mobile. Most importantly, please note that all parties won't have to be in the same location or the same organization to exploit such communication services.

What Do You Think?

You can contact me at: artr@ix.netcom.com or .

Confused About Implementing “UC?”

The experts at UCStrategies.com just published a comprehensive UC eBook that focuses very heavily on defining the various components of UC and how to systematically migrate current business communications to UC. Take a look and see if it answers your questions!


What Do You Think?

You can contact me at: artr@ix.netcom.com or at (310) 395-2360.