Last week's post on human latency got things cooking here, because my description of the concept of human latency really didn't do justice to the concept the way that (as it turns out) most people see it. Brent Kelly, Marty Parker and Art Rosenberg all weighed in to correct me.
Last week's post on human latency got things cooking here, because my description of the concept of human latency really didn't do justice to the concept the way that (as it turns out) most people see it. Brent Kelly, Marty Parker and Art Rosenberg all weighed in to correct me.Brent sums it up this way: "Human latency is not the time it takes to change communication channels, it is the delay in a business process that results when human interaction or intervention is required." Marty offers something very similar: "Human latency is the time that a business process is pending or delayed while waiting for the humans who are required to act on the process. The important thing to the enterprise and to the enterprise's customers or constituents is that the process be completed."
I'm good with that, and I think Brent's explanation, highlighting the difference between shifting communications channels vs. delaying business process, reflects the larger case that people are making around Unified Communications: There's some value in saving people time as they muddle through their day communicating with others, but it's not large or even quantifiable enough to make enterprises buy. But speeding up business processes could make a serious impact.
However, I do think we run the risk of overstating the benefits that UC can offer in reducing human latency, and how much of a breakthrough UC would be in dealing with this problem. For example, Marty writes, "Many, many examples exist [of technology overcoming human latency]. How about IVR systems and [automatic teller machines] and web sites, so that the customer or constituent does not even have to wait? How about e-mail, voice mail or texting so that a dialogue can occur without waiting for both (or several) parties to be available for a phone call (simultaneous by definition)?" He goes on to offer more examples, which don't include, but could, based on this list: How about the telephone, so you don't have to wait for a letter to get there?
The point being, business telecommunications from its inception has been all about reducing human latency. So the question becomes, how big of a deal is the incremental improvement that Unified Communications promises?
Marty sort of leads the way to this answer as well, when he writes about the application of advanced communications to contact centers: "The resulting improvements in both customer satisfaction and business profitability (from cost cutting, revenue growth or both) are matters of record. Why won't we do this in the rest of the business?"
Pre-UC, the answer to that question was simple: It cost too much and was too much work. The costs of CTI in time and money were justified in the contact center, and weren't justified anywhere else.
We often think that whatever technology is hot now will be some sort of end-state. When I worked at a magazine that covered the public network carriers, we had occasion at some point during the mid-'90s to name ATM (asynchronous transfer mode) as "Technology of the Year." One of the package of stories was to answer the question, "What comes after ATM?" As far as the carriers were concerned, the answer was, "Nothing." They actually seemed to believe that ATM was the end of history for carrier technology.
So all I'm saying is, maybe UC isn't here to put an end to "human latency." Maybe the advantages it holds over CTI will indeed let it penetrate deeper into the enterprise (as well as further improving the contact center). But at some point, the same cost/benefit equation that stopped CTI at the outside border of the contact center will come into play with UC.
In practical terms, what I think that means is you should go into UC looking to solve a couple of discrete issues rather than thinking it's going to transform everything.
