Creating Distributed Enterprise CRM Systems for Service Management

Continual Service Improvement (CSI) in ITSM is a self-invalidating activity that sometimes triggers changes right at the core of operations. It might be the way daily operations are performed by the frontline engineers or the way strategic decisions are made by the business owners, where ever the change be, without a right balance between the need for improvement and the urge to stick to the existing system, the results could be catastrophic. And finding the right balance, it comes only with experience.

In this web of experiences, this article is about a recent CSI implementation that I had to supervise for one of my clients who was in need of replacing their existing third-party CRM solution with an in-house solution. This article presents how my technical expertise combined with the ITSM experience helped the implementation become successful and discusses the reasons that triggered the need for the change followed by what went right and what could have gone wrong. The lessons learnt are for you to take home.

In a world of separate cultures, simple local desk structures suffice for the needs of customer service. In today's world of global culture, however, advanced models such as follow-the-sun are the need of the day and being one of the early adapters of that model, my client soon realized the importance of having to upgrade the existing tools and processes to suit the model. 

My client, whose identity I would like to keep confidential, is one of the premier Clarify CRM solution owners for the past 12 years and it must be admitted that it was all that my client needed to address the customer service needs till date. Till the move from local desk structure to follow-the-sun model was proposed, that is. Notwithstanding the merits, it was soon decided that the Clarity must be replaced with a new solution and the more customized it is, the better. Some of the key points that lead to this decision are:

Once the requirement specifications were frozen for the new CRM solution, it was decided to go for an in-house production, mainly for the cost-beneficial customization possibilities. The system was decided to be built around the following process workflow:

One important feature of the proposed system is that the above workflow is strictly enforced and it is not possible to detour any of the above steps without completing the required preliminaries. For example, an engineer cannot start working on a delivery without first completing the agreement on deliverables with the customer. This ensures that the expectations are set correctly on both sides and reduces the chances of misunderstanding and misdirected engineer efforts. 

The main challenge in architecting this solution came from the requirement to have the data be available round the clock across geographic locations worldwide, since it is now possible for scenarios such as a North American customer raising a service request mid of his night, causing an engineer from India or China pick it up (being it their work hours of the day) and work on it till the North American engineers become available in the morning and hand it over to them for proceeding further. This kind of frequent handoffs across geographic locations demand a versatile distributed architecture that needs to scale with the work load demands of 10000 engineers (My client happens to be one of the largest customer service providers in the world with about ten thousand engineers across all locations dedicated for customer support). 

This is where my expertise in successful design of distributed enterprise architectures played crucial role. While it was my ITSM experience that demanded for a change in the existing CRM preferring a new in-house solution, the technical expertise on the enterprise architectural background, nonetheless, was what has become the key factor in deciding final result. A great business vision (such as the move towards the follow-the-sun model) could not have survived without the support from the IT expertise. In the end, after few man years of efforts, the final product (the in-house CRM solution) was successfully launched with the following highlight features:

The features in the new solution immediately started to yield positive results upon deployment as more and more engineers started to embrace it with a mixture of curiosity and apprehension, the latter being replaced with appreciation as time progressed. However, during the initial deployment one of the major problems that we encountered was the transition of data between the old system and new system. 

Somehow, the aspect of the compatibility with the old system and the possibility of data transition between the two systems was overlooked during the design, mostly due to being over farsighted, so to say. When the new system was put in place, the question of what should be done with the old data and old system became a major concern. The choice was either to leave the old data in old system or to transit the old data to new system. 

Since in this case some of the data goes back to dates decades back, moving all the data to new system is out of question. It was decided that the existing data would be kept in the old system, pushing it into maintenance mode just for safe keep of records, using the new systems for all new service requests. Any still pending (in-progress) requests from the old system were decided to be continued on the old system till their completion. 

Within few weeks, after the last open request was closed, the CRM that has served the client for more than a decade finally went to the standby maintenance mode, with the new system growing busy day by day, unaware that one day it would be its turn to be replaced as the never ending cycle of Continual Service Improvement (CSI) keeps repeating. 

About the Author:

Gopalakrishna Palem is a veteran in Enterprise Distributed Architectures with more than a decade experience in IT Service Management. He was part of the Distributed Services Escalation team for the North America Business Unit at Microsoft Pvt. Ltd., and led the OLECOM India support unit. He is well known for his CFugue Runtime and CarMusTy Typesetting Environment and many of his open source libraries are wide adapted in the research community. Some of his contributions can be accessed at blog/ and at