If you knew where you would fall, you would not only spread straws, but also roll out the rug. However, life and practice throw up such surprises that even experienced specialists are sometimes mistaken. And this can disrupt the introduction of a new software and hardware complex. Here is a story based on real events. By coincidence, it ended well. The implementation was successful, but it could have ended badly. If anything, we didn’t implement it, but don’t repeat the mistakes of others.
introductory
Romashka had its own call center with a capacity of 200 seats, which consisted of two parts. Let's conditionally call them the sales department and the service department. The sales department was engaged in attracting new customers by servicing incoming calls and inquiries via chats using a cloud-based CRM system. The service department assisted existing customers by processing calls using Asterisk, and kept records of them in their own CRM (which, by the way, used as many as 4 RDBMS at the same time: MS SQL Server, Oracle, PostgreSQL and MySQL for the kit, so that it was not boring. And The IT department was a separate organizational unit and did not modify or maintain its own CRM, the service workers themselves periodically completed it – this is how it “has happened historically". a “zoo” of information systems, the data in which, of course, was synchronized, but “somehow not so.” It was assumed that the CC would take over the unified call management, and the CRM systems would manage contacts, while the CC would receive a contact for processing and return it back to the “correct” CRM, that is, the synchronization mechanism was supposed to be implemented inside the “guts” of the account ct center. In principle, such a scheme is possible under certain conditions, because it was not possible to get into the "cloud" of the sales department directly, but through the API.
Difficulties of implementing a call center platform and their solution
Difficulties arose immediately. For ideological reasons, they chose a platform, the question arose about the integrator. We wrote technical requirements, requested four companies with approximately the same experience, received four proposals with a price range of three times. How do you know who to entrust the work to? We chose the cheapest supplier and, oddly enough, guessed it, the guys just turned out to be the least arrogant, while having sufficient qualifications. But it was luck, the assessment of the potential of integrators was not carried out. And the worst thing in business is hoping for luck. We signed a contract and got started. And then it turned out that on the part of the customer, IT was appointed as the responsible service (which was stewing in its own juice and did not know anything about internal CRM, and would not have known, because the documentation simply did not exist in nature). We went to the service department, the manager explained that she simply did not have enough programming hours to help with integration with the CC platform. Simply no. But there is a general plan of work approved by the general, which, of course, is all from the “important-urgent” category. Went to the sales manager. He replied that he was “for” with two hands, but he could not manage the implementation, because he was not a techie, but sales, and he had … his own plan. Somehow, with a big scratch, the representatives of the integrator, having contacted the owner of the business, knocked out the programmer-hours from the IT and service department. At the same time, the customer appointed the implementation manager…that's right…the main salesman! They sat down to write and approve the terms of reference. At this, some people realized that operator places may simply not be compatible with the KC platform due to the requirements for the operating system. Passed … but could not carry. This should be checked at the pre-project discussion, before signing the main contract. The mistake was made by the manager from the integrator, according to him, in those places that he saw with his eyes, the OS was what it needed. And that there may be places that he did not see – he missed it. First of all, we tried to dock CC with cloud CRM. With some creaking, they docked via the API and the bundle worked quite well for itself … until they checked it under a real load. And there – the number of requests to the cloud base per unit of time, it turns out, is limited, and this is not mentioned anywhere in any form, just a given. In general, the problem came down to the fact that a specific cloud does not pull a specific CC. We calculated the budget for a boxed solution – shed a tear and almost bought it. Almost – because this time the integrator asked the right question about migrating data from the cloud to the box. It turned out that under the migration of resources it is definitely not and never will be. Through some tricks, the number of requests to the cloud was reduced. Didn't buy a box. The time has come to connect CC with the service department. Of course, the only programmer from there who could help went on vacation three days before the start of work. The project stopped for two weeks (see the vacation schedules of key specialists, be sure to look). But when the man returned, the work was done. The question arose of what to do with the data that already exists in both clouds in order to bring them into line with each other. By the way, there was a complex scheme for routing contacts depending on which CRM with which status a contact was found, so the data conflict created an amazing experience for customers like eternal loops in IVR. Customers paid Romashka a lot of money and were not very happy, because if they had problems with the equipment, business continuity was disrupted. We decided to “leave the existing data as it is and clean it up later”, and keep the data on new customers normally. It worked, but the problem, of course, did not remove. Having almost met the deadlines and (with a creak) within the technical requirements, but not the terms of reference, the integrator went to hand over the work. And here it turned out that the reporting of the CC, which is 100% consistent with the TOR, is … ugly … I don’t like it. Why ugly and how to remake – no one could explain, there is a suspicion that there was simply no money left for rework. In general, for a couple of weeks, the customer butted heads with the integrator on the issue of the aesthetic appeal of reporting. There were many more problems, for example, internal conflicts emerged between the heads of the customer's departments. But they did. And it works to this day.
conclusions
The moral of this fable is very simple: assume that things can be incompatible with each other. Either by its characteristics (as the operating system of operator places and software of the CC), or in certain conditions (under load and without it), or by the human factor. And on paper, everything is usually fine, but … It's always easier said than done.
