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:

• My client operates in all major countries worldwide with customers spanning all time zones. Till now Clarify was operated in a local server model, with each country site having its own local data center. Now with the proposed follow-the-sun model the data should be accessible across all sites with same efficiency and scaling the Clarify data center organization was perceived as an infeasible option.
• The existing Clarify solution does not provide notifications features for new service requests, making it difficult to track the outstanding requests, often leading to missed SLAs. A dedicated duty manager was assigned to queue the incoming requests to the right engineers, but it was an ineffective solution since the workload keeps varying, leaving the duty managers either under-utilized or over-utilized.
• The text based operations of Clarify were becoming fast obsolete and the cost of ownership was becoming increasingly unjustified as the need for more customized features were growing.
• Since the customers are from various language zones, the need for languages integration was perceived and the existing solutions were limited in their capabilities in that respect.
• Importantly, embedding customized workflow enforcements to suit the changing SLAs were problematic with Clarify and an in-built solution was perceived as the alternative.

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:

• When a customer wants to raise a service request, he would either call the local desk (close to his location or a toll-free central location) or use the customer support web site to describe his need and create a request.
• Based on the customer input, the request would then be classified into different categories determining its urgency and impact and the team/department that should be handling it. With customer consent the request will be dispatched to the team's queue in the central location accessible to all sites.
• A notification in the form of e-mail will be raised indicating the arrival of the new request for the corresponding team engineers' group alias.  Any engineer whose work-hours happen to be in the same time zone (irrespective of location) and available to pick up the request will respond to the notification and accepts the service request for follow-up.
• In case no engineer owns the request within the stipulated time as per the IRT (initial response time SLA), a further notification will be sent to the escalation site indicating the need for an immediate assignment for the about-to-expire service request. The escalation team will then make sure that an engineer is assigned to the request for follow-up.
• When the engineer owns the request, he communicates with the customer to establish a memorandum of understanding on the deliverables for the request. Once the deliverables are agreed, engineer starts working on the request to meet the customer needs and complete the delivery.
• Throughout the delivery process, various stages are flagged automatically by the system to track the progress and automatic notifications will be raised if the issue falls out of track (such as resolution getting delayed or commitments not meeting etc.) to the corresponding service delivery manager.
• Once the delivery is complete, the system will flag the request as complete and a notification will be sent to a third-party vendor to capture the customer feedback on his experience with the delivery. The metrics will be logged into the system and used for generating reports for further CSI analysis.

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 CRM solution now supports a centralized data center that is accessible round the clock for engineers at any place. The distributed architecture enabled the handoffs to be smooth. Performance was achieved by replicating the frequently accessed data to the local data-centers keeping them always in sync with the central data repository. This also improved the data redundancy factor, making the local data-centers work as failover servers in case of any catastrophic failures for the central repository.
• The notification mechanism in-built in the new solution improved the IRT factor, increasing the customer satisfaction ratings. It became apparent that an early responded customer was who turns out to be the most satisfied customer.
• The new system now supports more varied type of records to be stored for in case logs, such as screen shots of problems faced in the client's application, voice communication records, web meeting records etc., increasing the problem management effectiveness. This helped engineers to do postmortem analsis of incidents with ease, leading to more improvements in the internal knowledgebase organization.
• The new system now enables multiple language content to be recorded and tracked and the SLA workflow rules to be reconfigured on demand (by authorized managers).

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 http://gopalakrishna.palem.in/