There’s a reason most of us have such a hard time sticking to our new year’s resolutions-changing behavior is hard, and the longer we’ve been behaving in a certain way, the harder it gets. A recent blog by the New York Times’ John Tierney highlighted this in an interesting way. The post is about the smart elevators at the paper’s new headquarters—and the fact that they’re tripping many riders up, including Times employees who have been riding them for months.

From what I could gather from the post, the elevators save time and energy by grouping passengers according to floor. You push a button in the lobby stating your desired destination, and you are directed to an elevator. The odd thing is, once inside that elevator you don’t do anything else—like push a button to get to your floor. Not surprisingly, the process has people very confused, because it doesn’t conform to the elevator behavior they’ve been conducting for years. And it goes beyond simply expecting to push a button after entering an elevator—as numerous studies have shown, most of us are also conditioned to repeatedly push floor buttons in a (usually vain) attempt to get the doors to close faster, for instance. (Tierney doesn’t mention whether the elevators have “door open” and “door close” buttons, but their absence would at least let riders avoid the awkwardness of having to hold—or choosing not to hold—the elevator for late arrivals.)

The Times’ elevators were also the victim of a few poor design choices, such as not displaying the current floor—instead, the system showed only the next floor, leading people on that floor to depart one stop too soon. You’d think that’d be a pretty obvious user-interface snafu, but according to Tierney, “It took months before engineers finally added a feature to the sign showing which floor the elevator was on.” But the bigger issue here is getting people to change their elevator-riding behavior—not just being willing to push buttons on a central console rather than a local one, but also accepting that doing so changes the elevator-riding experience.

Transformational technology can change the way the world works, but it also requires a transformation in behavior—and that requirement can stall adoption for years, even in the face of significant benefits. Sometimes, we don’t make the transition at all. (Tierney ends his blog with a discussion of cars that will drive themselves, which he says could arrive in five years but won’t be adopted for 50; I’d be surprised if they’re adopted at all.)

Often, I think, our resistance is about control—and the desire not to give it up. When you really get down to it, that’s why people don’t like new technology—they fear the tools will take over the process, losing the human element, and their ability to influence it. And the fear isn’t entirely unjustified, because many technical processes actually involve very human interaction. One responder to Tierney’s post named Erika pointed out that the new elevator system interrupts human conversation—if you’re talking to someone who works in the same building but on another floor, you can’t “ride up with them” to continue your conversation. That may seem minor to an engineer, but it’s major to the humans having the interaction.

The idea that transformational technology requires transformational behavioral change—and sometimes, that that change is actually not what you want—has real meaning for communications and collaboration vendors as they develop new technologies to make communication easier. As unified communications and collaboration tools enter the enterprise, we’re sure to notice bugs and glitches related to the interface and the infrastructure—but we’ll also discover some problems that no one expected, and which simply can’t be fixed.

Of course, none of this should keep any of us from trying to achieve our own personal resolutions in 2008; just don’t be too hard on yourself when, like me, you give up around January 15.

The rise of Facebook is arguably the most explosive technology trend in 2007. Facebook launched in February 2004 from a Harvard dorm inhabited by now CEO Mark Zuckerberg. By December of that year Facebook had over a million users and today is one of the top visited sites in the world with over 50 million users. With this kind of growth there was no doubt that the Facebook phenomenon would infiltrate business - and it has. That blurring of boundaries between business and personal worlds is giving some IT managers a bad case of social heartburn and has sparked much debate around the appropriateness of consumer social networking tools in business.

I came across this story in Techworld about a company that may offer a solution to the problem.

“WorkLight has released a tool that’s designed to allow companies to provide employees with access to Facebook while ensuring the social network is run from behind secure corporate firewalls.

The server-based tool, known as WorkBook, stores proprietary company data on secure servers, not on Facebook servers, WorkLight said. In addition, the tool integrates with a company’s existing single sign-on tools to authenticate employees, it said.

Non-proprietary data can be viewed on the larger Facebook network, but proprietary company data, along with employee phone numbers and job roles, will be hidden behind the firewall, said David Lavenda, vice president of marketing and product strategy at Boston-based WorkLight.”

Some companies will chose to block out Facebook and other public social applications. For others, Workbook might offer the best of both worlds by tapping the value of Facebook, keeping users content and keeping sensitive information behind the firewall.

In December 2003, Basex named spam e-mail our Product-of-the-Year for 2004, explaining that this was akin to Time magazine’s naming Adolf Hitler Man of the Year in 1938.  Spam, we wrote back then, was "a disruptive force that has had a major impact on almost everyone who uses a computer." 

The Product-of-the-Year designation is meant to recognize technologies that have had a major impact on how we work using information technology - and nothing has had a more profound effect than the disruptive nature of spam.  Until now, that is.

This week Basex named Information Overload as the 2008 Problem-of-the-Year.

Whether sitting at a desk in the office, in a conference room, in one’s home office, or at a client, the likelihood of being able to complete a task (what many call "work") without interruption is nil.  Content creation has gone off the charts and new forms of content are being pushed towards us at a rapid pace.  It’s not just e-mail, junk mail, text messages, phone calls, and monthly reports anymore.

Intel, a company with 94,000 employees, sees Information Overload as a serious problem.  "At Intel we estimated the impact of information overload on each knowledge worker at up to eight hours a week," says Nathan Zeldes, a Principal Engineer focusing on computing productivity issues at Intel.  "We are now looking at applying new work behaviors that can help reduce this impact".

Shari Lawrence Pfleeger, a senior information scientist at the RAND Corporation, sees Information Overload as an impediment to getting her work done.  "We are more connected than ever, but we must manage not only our connections but also the increasing volumes of information flowing over them.  We continue to sort useful mail from junk mail, but we are additionally stressed by sorting useful phone calls from junk calls, useful email from spam, and in general useful from useless (and even dangerous) information.  To get really important work done, I find it helpful to take a holiday from my connections so that I can focus on the work at hand."

We believe that 2008 will be the year we begin to solve the problem of information overload in a substantive way.  

In conjunction with the Problem-of-the-Year announcement, Basex is announcing a survey on information overload and today’s work environment challenges.  Ironically, the latest office productivity tools designed to increase productivity are often having the opposite effect.

The survey can be found at http://www.basex.com/btwiosurv1 and survey takers are eligible to win a Palm Treo 750 smartphone with Windows Mobile 6.

Please take the survey today and feel free to share this link with colleagues.  The more input we get via the survey, the more we can do to solve the problem of Information Overload together.

As I was posting this here, The New York Times published a piece on Information Overload  - take  a look by clicking here.

This week Google announced plans for the “knoll project”, a site designed to allow individuals to share the knowledge they possess on a particular topic.  A “knoll” in Google-speak is a unit of knowledge.  But as Google moves forward with this plan, it begs the question “don’t we already have Wikipedia?”

Google’s tool differs from Wikipedia in a few key areas.  First, contributions are by invitation only (at least for now).  Google hopes that those with specific expertise in a particular area will contribute a written article sharing their knowledge.  Unlike a Wiki, where a group of individuals collectively builds and maintains a data repository, knol is meant to be more of an individual effort, highlighting authors.  Google argues that assigning an author’s name to a particular document will improve credibility and help users find quality sources of information.

Google hopes to leverage the social networking community to rate, comment, on, and contribute additional information to knols, again blurring the line between the knol project and Wikipedia.  And since it’s Google, authors will be able to include ads in their knols and profit from clicks.

In my mind the problem with the Google knol project is that it starts with a centralized model and then hopes the community will help shape development.  Contrast that with Wikipedia which relies on the open community to create and police content, only stepping in when controversies or other situations warrant.  

To me, the Google knol project sounds like a management nightmare.  Who will certify that knol submissions are accurate?  Who will vet authors?   Perhaps a more accurate comparison of the Google knol project isn’t with Wikipedia, but with About.com, which offers a very similar model, using public subject matter experts to maintain data repositories for a variety of subjects.  If knol is simply reinventing what already exists, what is the point other than to draw people away from the other sites into an environment where they will be subject to Google ads?

Hmmm…will Google accept a knol on the merits of using open social communities to build information repositories versus a closed, centralized model?

Despite their recent efforts at conciliation, Microsoft and Cisco continue to go head to head in defining what makes each “different” from the other in the unified communications market. For Cisco, it’s all about the network; for Microsoft, we’re moving telephony to IT. Cisco will tell you they support openness and integration, but when push comes to shove they spout the ultimate value in running Cisco applications on an all-Cisco network. For its part, Microsoft promises that its applications-based approach will save companies significant amounts (up to 50%, according to Jeff Raikes’ OCS launch speech) in voice management costs.

Now let’s be clear: Microsoft and Cisco each have good reason for betting on UC. For Microsoft, it’s the best way to ensure its current installed base of Office and Exchange users spends more money with the company—money beyond annual maintenance fees, money that actually goes toward new products and bi-annual upgrades as those products continue to mature. It’s also helping the vendor secure itself against upstarts like Google and Zoho, which are offering free or low-cost software to compete with and improve upon Microsoft’s productivity software in new and inventive ways. Cisco, meanwhile has indicated in a recent earnings statement that its future rests with emerging technologies—and big among those are unified communications applications (as well as telepresence, which presumably surprises no one). After all, one way for Cisco to grow revenues is to dominate new markets (not a new idea of course, as the telephony market knows).

Given the stakes, there’s no reason to expect Cisco and Microsoft to go all Kumbaya on us. But the fact is, their visions of UC are not mutually exclusive. Unified communications applications are just that—applications. The require back-end servers (unless they’re entirely Web based, which these CEP products are not), and those servers run on a data network. That’s how it works. (Theoretically, companies could develop appliance-based UC applications, but I’m not aware of any yet that go beyond IM or conferencing.) The real issue is where you put the intelligence, for purposes of management, performance and control: in the network (as Cisco prefers) or at the software endpoints (the Microsoft model). That’s worth debating, but it’s hardly significant enough to define the entire market.

So why do it? Well, when I asked Microsoft’s Michael Croan who the company sees as it’s biggest competitor in the UC market, the answer wasn’t IBM. It was Cisco. Likewise, Cisco’s Andy Leong told me the company’s biggest UC threat will come from IBM and Microsoft, not Avaya et. al. And that, of course, defines the differentiation debate.

In “The Age of Spiritual Machines” Ray Kurzweil writes about the pace of change of technology, noting that not only is technology itself constantly advancing, but the pace of change is rapidly accelerating.  As an example, it took humankind thousands of years to get to the point where we could build flying machines, but roughly sixty-five years after the Wright brothers first took to the skies; mankind put a person on the moon. 

Since then we’ve seen such a rapid advance of technological change (some would say “progress”, others might disagree), that futurists are now talking about a singularity in the not so distant future, a point in which technological change advances beyond the point of human comprehension, meaning the technology will move so far forward so fast, we’ll have lost the ability to manage it.

Looking at the evolution of Facebook over the last year it’s easy to see how this rapidly accelerating pace of change is manifesting itself in the applications and environments we use.  Not more than 15 years ago or so many of us had our first experiences with this thing called the “Internet”.  But Internet evolution was relatively slow (as were 9600 baud dial-up connections), voice over IP really didn’t emerge until around 2000 or so.  Video didn’t become ubiquitous until the rise of YouTube.  Even now, we are still in the early stages of transition from thick-client applications to browser-based “Web 2.0” services based on development frameworks such as AJAX.  While the pace of change has grown, we can still easily understand major milestones when the Internet became more than just a lose collection of web sites and instead became a set of increasingly integrated applications.

Compare the 15 year development of the public Internet with what we’ve seen over a much shorter period of time on Facebook, itself becoming a platform for innovation, collaboration, and change.  Launched in February of 2004 Facebook really didn’t enter the mainstream until September of 2006 when it was opened to the masses.  Early users of Facebook found it to be a useful way to connect with friends and colleagues, plan events, and perhaps play a rudimentary game of movie trivia or blackjack.  In many ways, the functionality of Facebook over its first two years resembled that of the early Internet, so much potential, but little real substance.

Now, take a look at what we’ve seen just in the last few months.  In May Jangl launched a Facebook-based calling service. In August Yugma launched a Facebook and Skype mash-up enabling Facebook users to share their desktop with other users.  In September Iotum launched a VOIP-based audio conferencing tool for Facebook users.  In December Truphone launched “click-to-call” services integrated into Facebook.  In November Alfresco introduced the Alfresco Facebook Platform to enable enterprises to push content out to Facebook users. 

All of these applications have been enabled by a combination of Facebook’s open architecture coupled with the realization that one must quickly move if they want to beat the rush to deliver services on Facebook.  In many ways what we are seeing in Facebook is the development of the Internet on steroids.  Services that took years to deliver to the Internet at-large are coming to Facebook in matter of months if not weeks.  At the current pace, Facebook will become the dominant communications and collaboration platform for the masses, replacing or swallowing up what today is a mish-mash of stand-alone applications.

For those pondering delivering services on Facebook, speed is of the essence.  For those who are users, change is coming faster than we can adapt, perhaps we’ll see the singularity on Facebook before we see it in the larger technology market?

When you talk to the leading unified communications vendors these days, you hear a lot about integration and interoperability. But mostly what they’re talking about is integration—allowing a voice product from one manufacturer work with a data product from another, and vice-versa. That’s important, especially as companies look to deploy best-of-breed UC environments that allow them to leverage their existing IT investments and continue to use the software they like best for specific functions and processes. But it doesn’t address one of the biggest challenges this market will face over the next several years: presence interoperability.

Today, companies that want to expose telephony and PC-based presence in a single application can do so, but only to their own users. There is no way for them to expose telephony presence from one vendor to another (say, a Cisco user to an Avaya user), and although they can use federation agreements between the leading consumer IM services and Microsoft and IBM to expose presence from, say, AOL to OCS, they need to do actual back-end work to federate across organizations on a enterprise IM system—and even then, it has to be the same EIM system (OCS to OCS, yes; OCS to Sametime, no go).

For a communications application, that would seem to have limited value. I mean, if UC is so great, shouldn’t I be able to leverage those benefits across all my communications and collaboration sessions? Who says my interactions with co-workers are more important that my interactions with partners, or even with customers, who are, after all, king?

Few would argue that point. (Although some will, I know—the holdouts who still believe that real-time communications must be controlled or all productivity hell will break loose. These are the same people who didn’t exchange real, live receptionists for voicemail until the late nineties.) The problem is two-fold: the technology, and the business.

On the business side, blame the vendors who worry that freely exposing presence information will make it impossible to lock users into their UC products. Today, presence is really the part of UC that’s monetized; the rest is either skin (the UC client interface) or commoditized functionality (audio and Web conferencing). Open up presence to all, and which product to deploy becomes much more a matter of end-user choice. (I prefer Outlook, you prefer Lotus, we can talk to each other so we don’t need to pay for both.)

On the technology side, blame e-mail. No one wants to treat presence information the way we do e-mail. E-mail’s openness has its merits, of course (see above), but the resulting viruses and spam have rendered the technology unworkable for many users. Put everyone’s presence status—and the ability to ping them with an IM, or invite the to attend an audio, video or Web conference call on the fly—and the potential security and productivity risks are daunting.

So what to do? On the business side, the vendors will have to realize that playing together will ultimately be better for the market—and their position in it—than playing apart. This is not a new problem; we saw it in the e-mail world, and more recently in the cellular one.

The technology problem is more painful, and will require more thought. But one option is to create clearinghouses that collect, aggregate, filter, store and disperse public and private presence information. A handful of vendors are positioned to do this, and they don’t all come from the same industry today. I’d love to hear your thoughts on who should be looking at this opportunity—as well as other ways to solve the presence problem.

Microsoft recently announced its Unified Communications Developer Portal. The site, found on the Microsoft Developer Network (MSDN), includesinformation related to  software developer kits and application programming interfaces (APIs) devcelopers can leverage to build applications on its unified communications platform (e.g., Office Communications Server 2007, Office Live Meeting 2007).

What’s the significance of this announcement?

Some Microsoft speakers at the October UC launch event signaled that Microsoft’s next move would occur in the developer area related to UC-enable business and productivity applications. The announcement is significant since it is often the application solution (and its potential ROI) that helps build the business case for infrastructure upgrades and deployment of new products. In this case, if IT organizations can see how to build UC-specific applications, or augment existing applications through UC-related services, then the business case for adopting/migrating/deploying Microsoft’s products (such as Office Communications Server) becomes more complete. By delivering an application scenario around its UC platform, Microsoft alleviates some of the delays that occur when infrastructure upgrades lack an identifiable business solution. That said, there are a lot of different API’s in this announcement. To some extent, the possible permutations of API’s a developer might need to utilize when building a UC-enabled application reflects a lack of maturity and cohesiveness around the development model for Microsoft’s UC platform. In some ways, the amount of API sets reminds me of a mashup of sorts as Microsoft packages multiple products into a “platform” that is not entirely normalized underneath. While there are a lot of API’s here (arguably, an abundance of riches for those building software products), application developers are not software engineers and simplification wins out over complexity. There will likely be some initial confusion regarding the different techniques programmers can adopt when developing UC-based systems on Microsoft’s platform. I would expect Microsoft to raise the abstraction layer up a notch and be more consistent with the different ways applications can be built with the various toolkits in subsequent releases.

What does it bring to developers?

Everything that I mentioned above related to developers – plus – this strategy leverages the experience (e.g., .NET) developers already have with Microsoft tools (e.g., leverage UC plug-ins for Visual Studio).

How credible is Microsoft’s position in the unified communications space?

Very credible but it has different areas of competency that are at different levels of maturity. Microsoft’s core strengths are in the real-time collaboration re: IM, presence, web conferencing. They are rapidly moving into the area traditionally dominated by communication vendors – VoIP/IP Telephony, audio/video conferencing. But right now, I believe most organizations are going to deploy OCS and “get stable” around the real-time collaboration capabilities, then move to VoIP and integration with existing communication vendors as driven by business requirements. I do not see anyone ripping out their existing IP-PBX infrastructure in the short run. I do expect more rapid adoption of Round Table however given its price point, form factor and integration with Live Meeting. But make no mistake, Microsoft is in the UC game for the long run and fully intends to dominate it from a platform perspective - that includes mobile and speech as a standard application interaction model.

Who is the typical "developer" they are targeting?

Microsoft wants to appeal to different segments of the developer community. They want to make it easy for the average developer to UC-enable productivity applications, deliver more complex UC-centric systems at a platform level, and extend the modality of applications with speech interfaces – so I really think it is across the board – from the historical “VB”-like developer to the IT Pro who might be developing at a core infrastructure level.

Microsoft Introduces Unified Communications Tools for Developers

Q&A: Kirt Debique, general manager for Microsoft’s Office Communications Platform & Solutions Group, discusses how a new Unified Communications Developer Portal will provide enterprise developers with secure and reliable tools for building applications.

Related Links

MSDN Unified Communications Developer Portal
Developer Tools News
Unified Communications Virtual Pressroom
Microsoft Unified Communications: How Developers Can Blend Messaging, Voice and Conferencing with Next-Generation Applications
UNC301: Unified Communications for Developers: Building Communications Into Your Applications

Microsoft Introduces Unified Communications Tools for Developers

Microsoft recently announced “FeedSync” (refer to the article cited below), as the evolution of its previous work known as Simple Sharing Extensions, or SSE.  My initial reaction is that this announcement is somewhat of a "one off". Microsoft has not articulated any coherent vision on XML feeds and the end-to-end management of feeds in general and this announcement does not clarify its strategy. Microsoft is correct in pointing out the proliferation risks related to XML feeds. But FeedSync tries to solve more advanced problems that are outside mainstream adoption of XML feeds within enterprises right now. It also leaves Microsoft clients without a clear framework for how XML feeds and feed syndication comes together for those investing in the Microsoft platform. What I do believe is that we need to move away from feed synchronization being left up to individual vendors - so there is a clear need for a community-effort to standardize in this area (as mentioned by Sam Snell of IBM at the bottom of a blog post of the FeedSync topic). There is also the broader challenge of data synchronization (where tools like Groove and Notes have advanced replication engines that are unfortunately locked up inside those respective products).

Perhaps someone will take this spec and run with it - creating some interesting and innovative applications that can better showcase its value. But I wish Microsoft would fix some of the more basic gaps and glaring holes in how it is approaching XML feeds and feed syndication in general. Right now, "the cart is before the horse" so to speak.

Initially, Microsoft delivered the Windows RSS Platform as part of IE7. IE7 included its own lightweight feed reader (which I actually like, it does what it is supposed to do and no more). Windows RSS Platform (which I also like), was positioned as common client-side infrastructure to provide consistent feed-related services for desktop applications (e.g., feed subscriptions, download, storage).

Then the Outlook team undercut that effort by implementing (essentially), its own version of Windows RSS Platform as part of Outlook 2007. That’s bad enough - but the implementation is absolutely horrible when you use it for a large number of feeds (BTW, my machine literally dies when Outlook 2007 syncs and despite deleting feeds several times, they keep coming back – my experience with Outlook 2007 and its native support as a feed reader has been very frustrating).

Microsoft further confused the picture when it appeared to be working on a hosted feed syndication platform but never executed. Niall Kennedy was hired with the assumption (on my part) that he would spearhead the effort. Indeed, he initially appeared excited about coming on board, but soon announced that he was leaving.

SharePoint exposes a lot of information via RSS feeds but it apparently has no support for Atom - in fact, Microsoft seems to be very unclear on its support for Atom (and Atom Publishing Protocol). Perhaps Microsoft will continue to play with RSS extensions. I hope not since this would only end up muddy the waters given RSS is essentially an architectural dead-end. It is important for IT organizations to realize that SharePoint is not a feed syndication platform - it’s just another application that exposes feeds. This gap forced Microsoft to partner with NewsGator (i.e., Social Sites), but even that integration does not eliminate the need for enterprise IT organizations to look at what Attensa, KnowNow and NewsGator offer themselves as complete feed syndication platforms.

Surprisingly, IBM is also completely absent regarding a feed syndication platform. I find it amazing (in an underwhelming manner), that a company touting social computing (e.g., Lotus Connections) and "Info 2.0" has not articulated a strategic vision related to XML feeds outside a simplistic client implementation in Notes 8 and surfacing XML feeds in its related back-end products (e.g., Domino, QuickR, etc). For now - Attensa, KnowNow and NewsGator remain the only credible options with perhaps Oracle as perhaps the only large vendor that could make a move here.

Synchronization for the Web

The creation of FeedSync was catalyzed by the observation that RSS and Atom feeds were exploding on the web, and that by harnessing their inherent simplicity we might enable the creation of a “decentralized data bus” among the world’s web sites. Just like RSS and Atom, FeedSync feeds can be synchronized to any device or platform.

Previously known as Simple Sharing Extensions, FeedSync was originally designed by Ray Ozzie in 2005 and has been developed by Microsoft with input from the Web community. The initial specification, FeedSync for Atom and RSS, describes how to synchronize data through Atom and RSS feeds.

Windows Live Dev

IBM is releasing version 8 of its Sametime UC platform next week, as well as Sametime Entry, which is designed to deliver basic IM and presence capabilities to Outlook users. New features in Sametime Standard (formerly just “Sametime”) include expanded platform support for IBM Lotus Domino 8 server and server support for VMWare environments; extended support for mobile workers, including the Nokia E-series, Sony Ericsson, and Microsoft Windows Mobile 6 devices; new point-to-point video capabilities for Macintosh users; and integration with Microsoft Office 2007.

Meanwhile, Sametime Advanced is on track for delivery in Q1 2008 (it adds persistent chat, broadcast and instant-share capabilities), and Sametime Unified Telephony is still due mid 2008. That product is expected to include telephony plug-ins for the Sametime application, click-to-call and click-to-conferencing, aggregated IM, phone and calendar presence, incoming call control, an embedded softphone, and connectivity to legacy PBX and SIP-based systems. Unified messaging and voicemail capabilities are due in release 2. What’s nice about SUT it that it will truly support mixed-vendor environments, so that companies with, say, Cisco and Avaya gear already installed can use IBM’s middleware layer (and that’s essentially what SUT delivers on top of—or, underneath—the Sametime client) to give employees a single, consistent communications environment, regardless of what specific telephony and network products they have in place.

I love the Sametime products, because they’re mature, elegant and easy to use. I also think that in the past 12 months, IBM has done a terrific job of detailing and delivering new products that build on the company’s history in the collaboration arena, and that IBM is in the best position to add social networking and other Web 2.0 tools to its software in a way that meets both end user and IT staffer needs. But I still think the company should yell a little louder about its success in the marketplace.

On a recent analyst call, for instance, Bruce Morse, VP, Unified Communications & Collaboration Software, highlighted three customer case studies that actually talked about customers using a true unified communications application—not just a subset of UC features, such as VoIP or conferencing or IM. That’s unusual—none of the other vendors who’ve showcased customer stories in the past few months have said the same. Here they are, boiled down:

• A major European bank is giving Sametime to tellers, who in the past were making long-distance calls to the home office to get information on products and services as customers came up to the window. They contacted IBM in search of a way to get those telephony costs down—and ended up deploying Sametime not just save on toll charges via VoIP, but also to give tellers the presence information and chat and capabilities they need to get information on the spot. The company expects to save $3.5-$4 million dollars its first year, as well as drive new business.
• Colgate-Palmolive is using Sametime to shrink development cycles for new products by leveraging the presence and conferencing capabilities within the system. By linking various constituents in the development process, wherever they are and whenever they’re needed, the company expects to shave considerable time off the process of getting new products to market—and gain considerable revenues as a result.
• Celina Insurance Group is using Sametime to get an edge with the independent agents who sell its products and services. Because those agents sell insurance from multiple firms, Celina needs to give them excellent and immediate service and support, ensuring agents get the information they need when they need it, and collaborating with them on new offerings and opportunities.

Those are the kinds of case studies other companies want to see in order to justify their own UC deployments. I’m excited to hear more of them in 2008.