Copyright © 2008 Unified-View, All Rights Reserved Worldwide
January 30, 2008
Comments On Ending “Telephone Tag” With UC-based “ASAP” Calls
By Art Rosenberg, The Unified-View
In my last column, “ Adding ASAP Voice Calls to UC,” I described ways to place a phone call that would recognize the fact that callers may want to have a person-to-person voice conversation as soon as possible, but that callees are really not very available, unless that is their job, e.g., as a call center agent for enterprise customers or as an emergency first responder.
In general, business contacts, whether internal to the organization or outside of the organization (sometimes referred to as “information workers”) fall into the category of rarely available. In fact, an old call activity statistic still holds true, that over “70% of calls within an enterprise do not reach the intended party” and result in voice mail messages or a hangup.
Recognizing that fact, the new UC capabilities for both contact initiators (“callers”) and contact recipients (“callees”) should be put to work to make business communications more efficient and effective for both parties. In other words, we should not be playing the old “telephone tag” game with UC and more flexible, personalized, multimodal endpoint devices such as desktop “softphones” or mobile “smartphones.”
“ASAP Calls” Generates Response
Some of my readers responded to the article with practical concerns about how they see exploiting UC for their business phone call requirements. This reflects the need to personalize business UC capabilities at the individual end user level. So, rather than preach the general “Gospel of UC,” here are their constructive comments.
----------------------------------------------------------------------------------------------------------------------------------------
Art,
Rather than just leaving voice mail, I'd like a presence-based system that would
automate requests for callbacks based on both parties’ schedules. The caller would
allow caller ID to identify themselves to the recipient and then select two
categories; one for ID category [customer, vendor, employee, etc.] and the other
for their perceived level of urgency. For example, I could call a vendor and their system would give me the option to
request a callback using voice recognition. I'd ID myself as a potential customer
with a low level of urgency. My system would sync with the vendor's system [I know
I'm dreaming] and eventually put the call through based on both parties’ preferences
[as previously scheduled]. So, if I scheduled my presence setting to accept low urgency calls on Friday
afternoon between 3 and 5 pm, and the vendor was available at that time as well, the
call would be put through without either party doing anything other than answering
the phone and listening to a voice clip regarding the topic. Doug Baumwall--------------------------------------------------------------------------------------A.S.A.P. & Siemens:This sounds very similar to the "Call Back" functionality of a traditional PABX, TDM or IP,
which also tracks the "status" of the particular terminal called. When the called party
either ends his current conversation by hanging up or the called party returns to his or
her phone and makes a call (alerting the PABX) that the user is now "available". This
feature is, in effect, only available to users on the same PABX or PABX’s QSIG networked
together for this specific functionality (very difficult to implement in a multi-vendor
environment. It has never really worked over the Public Switched Telephony Network even
where ISDN is being used.It would appear that the same issues would arise in the UC world when the same
circumstances are met. SIP presence, for example, can be linked together with telephony
availability similar to the old CTI (either first or third party) associated call control
software with a telephone. However, complex SBCs and SIP trunking are required to, say,
Integrate Company A's presence solution (Microsoft OCS) with Company B's Presence solution
(Avaya SES). These are capabilities which will have to be provided by operators (or some
sort of DNS for presence information).But there is a very large question of security in this case, as you don't always want to
have your presence information available to all. Secondly, presence is only as good as the human administering his or her Presence. How
often is the presence information being published by one or more platforms (i.e. telephone,
mobile, email, IM, etc...) collated into a single interface via UC actually wrong. The user
has simply walked away from his or her desk without changing the presence status?The real usefulness of email lies in the fact that it is effectively both a real-time and
delayed-time mode of communication for which alerts can be presented to a number of devices
different simultaneously (like twinning between your desk phone and your mobile phone). The
"called" party can then evaluate whether or not they wish the communication attempt to be
real-time(immediate answer) or delayed time. For me, the real effectiveness of UC is the real-time negotiating and transitioning between
the available modes of communication once a connection" or "contact" has been made. An urgent
email to user A, is alerted on his mobile phone as he is out of the office on the road (as
well as his email and IM client's). He reads it and immediately from his device attempts to
set up a call with the sender. The sender is not Available on the phone but is able to message
(email, IM, SMS), the conversation continues in the negotiated mode between the 2 people.Working in this way, however, (negotiating an agreed upon mode of communication from a
multiple number of modes) is a massive cultural change for the employees of most
organizations. I agree, however, that this will be something expected by my 15 year old son in
5-10 years when he hits the workplace.Thanks!RegardsChristopher Alderman
Sr. Convergence Sales ConsultantBT Global Services | Telecomlaan 9 | 1831 Diegem | BelgiumT: | M: | F: E: christopher.alderman@bt.com | BT Meet Me PIN # ------------------------------------------------------------------------------------------------------------
Art,
and other pests invent a way to use it to force their way onto my "desk".
While I certainly support the idea of getting important people in touch with me ASAP, I'm
worried about letting a caller specify their level of urgency. They already manipulate
their Caller ID data to get past blocking filters and social engineer higher level contacts.
Just imagine what they can do with new features and functions. The features I'm still trying to set up are, "Call Forward - someone who cares" or
"Busy - Go Away!". Pete Romfh ---------------------------------------------------------------------------------------------------------------
“ASAP Calls” - What Do You Think?
I am not sure what users should call a UC-based phone call attempt that won’t necessarily result in an immediate voice conversation, but it sure shouldn’t always end up in “Voicemail Jail” and “Telephone Tag!” What do you think? Let us know what we should this new way of communicating that will be descriptive of what we really want. Send your comments and opinions to artr@ix.netcom.com
COMING SOON!
Go to www.ucstrategies.com to read my upcoming daily UC Commentary, which critically reviews the important enterprise user developments in Business UC and not just tons of “me too” announcements.
Posts
