Pipeline Publishing, Volume 4, Issue 2

	This Month's Issue:
	Keeping Customers

Tit for Tat: Meeting Customer Expectations

article page | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |

once in a blue moon failure results in a bad customer experience with the interactive problem-resolution-process, the negative impact is disproportionately severe.

Using today’s tools to solve the problem: Collaboration Technology

We have advanced IT integration architecture with NGOSS and SOA and integration technology with ESB and web services. Now it is time to identify, and then apply, technology for Process and People integration. The solution for this problem can be found in the roots of collaboration applications. Back in the late nineteen-nineties, after he successfully introduced Lotus Notes (the root seed of both collaboration infrastructure and ERP), Ray Ozzie introduced a novel product called Groove.

Ozzie’s Groove introduced the notion that each party interacting in the collaboration group would have its own queue of messages and information. The collaboration service would contain a log of all interactions and a repository of all shared documents. When participants would leave the collaboration service, their queues would record interactions in the space and then play them back to the participant when they returned – providing a synchronized view over long term interactions.

Of course Groove was not the only instance of collaboration technology to be independently developed in the late nineties. Wedge Greene’s NewWave team at MCI and Sun Microsystems’ open-source Rio each independently developed collaborative technology based on Jini Networking software. The Jini-based collaborative services introduced the notion of long-duration distributed transactions to collaboration and control of the shared items with software agents/objects. Both approaches provided a common view for all participants and shared updating of all documents and data associated with the repository of the collaboration.

Today Collaboration technology is represented by two approaches: a peer-to-peer approach where each participant exists independent of the collaboration which is implemented as individual queues synchronized at each peer interaction. This has the advantage of allowing ad hoc interactions to occur such as in advanced social networking applications. However, for larger groups this approach gets very complex to implement. In this case a “collaboration space” is used. Often this collaboration space is implemented on Javaspace technology, an approach recommended by Mr. Greene. But it is possible to use specialized server-side applications (EJB, .NET, or web-servers) which is, for one example, the approach used by Microsoft’s NetMeeting and its recasting of

“A customer with a skeptical temperament needs proof, and a company representative might mistakenly think the customer is resistant to what is being presented; when, in fact, the customer might be in strong agreement.”

the 2005 purchased/assimilated Groove into today’s ‘Groove Networks for Office 2007.’

A proper Collaboration Space will have many or most of the characteristics of a governed ESB; however, it extends the interactions significantly (such as both synchronous and asynchronous interactions, distributed long duration transactions, and synchronization services). Collaboration spaces can be used for message-based application integration, but usually, integration is triggered by events which span processes or distributed transactions. What is typically exchanged at the tightly-coupled end are software objects, and at the loosely-coupled end are XML-ish documents.

All Collaborative applications are inherently event-driven architectures. A triggering event is defined which, when fired, invokes a specific behavior or set of actions. Often Collaborative applications have an embedded state model which releases control via firing off an event at the point some established state is met. In this sense, collaborative applications are made up of a series of agents keyed to specific events. They act together, often in repeatable patterns, yet in apparently unpredictable sequences, yielding stable, and desired results.

Besides Collaboration spaces, we believe the new technology of social networking will provide significant new tools that should be added to the architecture of the post-millennium Service Provider. Social network allows people, or software agents, to interlink in remarkable computational engines that are counterintuitive yet produce results. Detailed treatment of the use of Social networks in OSS and customer service will be covered in a future article.

Cross-fertilization of Applications

The hand-off process flow that routes an issue stepwise from the CC to the SOC to the NOC and back as described above is sub-optimal. The escalation process in OSS is just too costly to keep around.

Before [in part one: Customer Service in the Enhanced Contact Center, Pipeline 10/06], we showed the proposed integration of and active use of CRM, ITSL service desks, and

article page | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |

© 2006, All information contained herein is the sole property of Pipeline Publishing, LLC. Pipeline Publishing LLC reserves all rights and privileges regarding
the use of this information. Any unauthorized use, such as copying, modifying, or reprinting, will be prosecuted under the fullest extent under the governing law.