If you knew where you would fall, you’d not only lay down some straw, but also roll out a mat. However, life and practice throw such surprises that even experienced specialists sometimes make mistakes. And this can disrupt the implementation of a new software-hardware complex or the launch of a call center. Here is a story based on real events. Thanks to a confluence of circumstances, it ended well. The implementation was successful, but everything could have ended badly. Just for record, we were not the ones implementing, but do not repeat the mistakes of others.
This article relates to the tool for the manager
Introduction
In the company “Daisy” there was an in-house contact center capacity of 200 seats, which consisted of two parts. Let’s call them the sales department and the service department. The sales department was involved in attracting new customers, serving incoming calls and inquiries through chats with the help of a cloud CRM system.
The service department provided assistance to existing customers, handling calls utilizing Asterisk, and managed them on their proprietary CRM system (which, by the way, simultaneously utilized four database management systems: MS SQL Server, Oracle, PostgreSQL, and MySQL, for a diverse and dynamic environment).
Interestingly, the IT department was a separate organizational unit and did not modify or service their own CRM, instead, the service agents would periodically fine-tune the CRM, reflecting the unique historical development of the company’s operations. The company was engaged in the manufacturing and supply of equipment.
The management decided to implement a contact center platform (launching a call center in the cloud) to help department managers make sense of the “zoo” of information systems, where data was, of course, synchronized, albeit somewhat imperfectly. It was proposed that the contact center would handle the unified management of calls, while the CRM systems would manage contacts, with the latter receiving a contact for processing and returning it to the “correct” CRM, that is, the synchronization mechanism was to be implemented within the “bowels” of the contact center. This scheme is feasible under certain conditions because it was impossible to directly access the “cloud” of the sales department, only via API.
Difficulties in launching a call center, and their solutions
Difficulties in launching the call center arose immediately. For ideological reasons, a platform was chosen, followed by the issue of its integration. We drafted technical requirements, approached four companies with similar experience, and ended up with four vastly different proposals. How do we determine who to assign the work to? We opted for the cheapest SIP provider, and surprisingly, it worked out. They turned out to be less audacious, while still being qualified. However, this was sheer luck, as no proper evaluation of the integrator’s potential was carried out. And the worst thing in business is relying on luck.
We signed a contract and got to work. It then became apparent that the IT department (which was steeped in its own juice and knew nothing about internal CRM, and would never have learned because there simply were no existing documents) was appointed the responsible service. We reached out to the service department, but the supervisor explained that she simply didn’t have enough programmer-hours to assist with platform integration. There just weren’t any. But there was an established general plan of work, which were all, of course, “urgent-important” tasks.
We then approached the head of the sales department. He was fully on board, but stated that the implementation of This individual is unable to manage because they’re not a technician, but a salesperson with… their own plan. With considerable struggle, the integrator’s representatives, after reaching out to the business owner, managed to secure some programmer-hours from IT and the service department. You guessed it… the head salesperson was appointed as the implementation manager on the customer’s side! They sit down to write and approve the technical task. At this point, someone realized that the operator seats might simply be incompatible with the contact center platform due to operating system requirements. They dodged the bullet… but it could have gone wrong. This needs to be checked in the pre-project discussion, before the main contract is signed. The integrator’s manager made a mistake – according to him, in the places he saw with his own eyes, the operating system was just the one needed. He missed the fact that there could be places that he did not see. The first thing they tried to do was connect the contact center with the cloud CRM. They managed to connect them through the API with some struggle and the link worked quite well… until they tested it under real load. Turns out, the number of queries to the cloud’s database in a given time is limited, and this information is not mentioned anywhere, just a given. In general, the problem boiled down to the fact that the specific cloud could not handle the specific contact center. They have led budget calculations for a boxed version… The solution – we almost bought it after shedding a few tears. Almost – because this time, the integrator asked the right question about data migration from the cloud to the box. As it turned out, there certainly wasn’t and won’t be a migration of resources. Through certain twists and turns, we managed to reduce the number of requests to the cloud. We decided against purchasing the box.
The time came to connect the contact center with the service department. Needless to say, the only programmer who could help from there went on vacation three days before the work began. The project came to a halt for two weeks (always monitor the vacation schedules of key specialists, emphatically). But when the person returned – we finished the work.
The question arose, what to do with the data that already exists in both clouds, to bring them into alignment with each other. By the way, there was a complicated script for routing contacts depending on which CRM and what status the contact was found, creating a rather chaotic experience for the clients, such as eternal cycles in IVR. Clients paid ‘Oki-Toki’ a tidy sum and weren’t quite pleased because when they had equipment troubles, their business continuity was disrupted. The decision was made to ‘leave the existing data as is and clean it later’ and properly manage the data for new clients. It turned out that … The problem, obviously, wasn’t completely solved.
Having almost met the deadlines and (with a struggle) fitting into the technical requirements, but not the technical specification, the integrator proceeded to submit the work. And here it turned out that the call center reports, 100% matching the spec, well…they are unattractive… they are not liked. Why they are unattractive and how to redo them – no one could explain, there is a suspicion that there simply was no money left for redesigning. In general, the customer squabbled with the integrator for another couple of weeks concerning the aesthetic appeal of the reporting.
There were many more problems, for example, internal conflicts between the customer’s department managers emerged. However, – it was accomplished. And it still works to this day.
Conclusions
The moral of this fable is very simple: assume things might be incompatible with each other. Either in terms of their characteristics (like the agent’s operating system and the contact center software), or in certain conditions (under load and without), or due to human factor. And on paper everything is usually fine, but… It’s always easier said than done.
