[:en]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.[:ru]Знал бы где упадешь, не только соломки бы подстелил, но и коврик бы раскатал. Однако жизнь и практика подбрасывают такие сюрпризы, что даже опытные специалисты порой ошибаются. И это может сорвать внедрение нового программно-аппаратного комплекса или реализации запуска колл-центра. Вот история, основанная на реальных событиях. Благодаря стечению обстоятельств она закончилось хорошо. Внедрение прошло успешно, но все могло закончиться плохо. Если что, внедряли не мы, но не повторяйте чужих ошибок.
Статья относиться к инструменту для руководителя
Вводная
В компании “Ромашка” был собственный контакт-центр емкостью 200 мест, который состоял из двух частей. Условно назовем их отделом продаж и сервисной службой. Отдел продаж занимался привлечением новых клиентов, обслуживая входящие звонки и обращения через чаты с помощью облачной CRM-системы.
Сервисная служба оказывала помощь действующим клиентам, обрабатывая звонки с помощью Asterisk, и вела их учет в CRM собственной разработки (которая, кстати, использовала одновременно целых 4 РСУБД: MS SQL Server, Oracle, PostgreSQL и MySQL для комплекта, чтобы было не скучно.
А ИТ-отдел был отдельной организационной единицей и собственную CRM не дорабатывал и не обслуживал, сервисники сами ее периодически допиливали – так “сложилось исторически”. Компания занималась производством поставками оборудования.
Руководство приняло решение внедрить платформу КЦ (запуск колл-центра в облаке), чтобы помочь руководителям служб как-то разобраться с “зоопарком” информационных систем, данные в которых, естественно, синхронизировались, но “как-то не так”. Предполагалось, что КЦ возьмет на себя единое управление звонками, а CRM-системы – управление контактами, при этом КЦ будет получать контакт для обработки и возвращать его обратно в “правильную” CRM, то есть, механизм синхронизации предполагалось реализовать внутри “кишок” контакт-центра. В принципе, такая схема в некоторых условиях возможна, потому что внутрь “облака” отдела продаж напрямую было не залезть, то по API.
Сложности в запуске колл-центра, и их решение
Сложности в запуске колл-центра возникли сразу же. По идеологическим соображениям выбрали платформу, встал вопрос об интеграторе. Написали технические требования, запросили четыре компании с примерно одинаковым опытом, получили четыре предложения с разбросом цен в три раза. Как понять, кому поручить работу? Выбрали самого дешевого SIP-провайдера и, как ни странно, угадали, ребята просто оказались наименее наглыми, при этом имеющими достаточное квалификацию. Но это было везение, оценка потенциала интеграторов не проводилась. А самое плохое в бизнесе-это надежда на везение.
Подписали договор, приступили. И тут оказалось, что со стороны заказчика ответственной службой назначена ИТ (которая варилась в собственном соку и ничего про внутреннюю CRM не знала, да и не узнала бы, потому что документации просто не существовало в природе). Пошли в службу сервиса, руководитель объяснила, что у нее просто нет достаточного количества программисто-часов, чтобы помогать с интеграцией с платформой КЦ. Просто нет. Зато есть утвержденный генеральным план работ, которые все, конечно, из категории “важно-срочно”.
Пошли к руководителю отдела продаж. Он ответил, что “за” двумя руками, но внедрением руководить не может, потом что не технарь, а сэйлз и у него…свой план. Кое-как с большим скрипом представители интегратора, выйдя на собственника бизнеса, выбили программисто-часов из ИТ и сервисного отдела. Руководителем внедрения со стороны заказчика при этом был назначен…правильно…главный сэйлз!
Сели писать и утверждать техзадание. На этом кое-кто понял, что операторские места могут оказаться просто не совместимыми с платформой КЦ из-за требований к операционной системе. Пронесло…но могло не пронести. Это надо на предпроектном обсуждении проверять, до подписания основного договора. Ошибку допустил менеджер со стороны интегратора, по его словам, на тех местах, которые он видел глазами, ОС была какая надо. А что могут быть места, которых он не видел – это он упустил.
Первым делом попытались состыковать КЦ с облачной CRM. С некоторым скрипом состыковали по API и связка вполне себе заработала… пока не проверили под реальной нагрузкой. А там – число запросов к базе облака в единицу времени, оказывается, ограничено, причем об этом нигде ни в какой форме не сказано, просто данность. В общем, проблема свелась к тому, что конкретное облако не тянет конкретный КЦ. Посчитали бюджет на коробочное решение – прослезились и почти купили. Почти – потому что в этот раз интегратор задал правильный вопрос о миграции данных из облака в коробку. Оказалось, что под миграцию ресурсов точно не и не будет. Путем некоторых вывертов число запросов к облаку удалось уменьшить. Коробку покупать не стали.
Наступил час связать КЦ с отделом сервиса. Само собой, единственный программист оттуда, который мог помочь, ушел в отпуск за три дня до начала работ. Проект встал на две недели (смотрите графики отпусков ключевых специалистов, обязательно смотрите). Но когда человек вернулся – работу сделали.
Встал вопрос, что делать с данными, которые уже есть в обоих облаках, чтобы их привести в соответствие между собой. Кстати, там была сложная схема маршрутизации контактов в зависимости от того, в какой из CRM с каким статусом нашелся контакт, так что противоречие данных создавало для клиентов потрясающий опыт типа вечных циклов в IVR. Клиенты платили “Ромашке” немалые деньги и были не очень довольны, потому что при проблемах с оборудованием у них нарушалась непрерывность бизнеса. Решили существующие данные “оставить как есть и почистить потом”, а данные по новым клиентам уже вести нормально. Это получилось, но проблему, понятное дело, не сняло.
Почти уложившись в сроки и (со скрипом) в рамки технических требований, но не техзадания, интегратор отправился сдавать работу. И вот тут оказалось, что отчетность КЦ, на 100% соответствующая ТЗ, она…некрасивая…она не нравится. Почему некрасивая и как переделать – никто объяснить не смог, есть подозрение, что на переделку просто не осталось денег. В общем, еще пару недель заказчик бодался с интегратором по вопросу эстетической привлекательности отчетности.
Было еще много проблем, например, всплыли внутренние конфликты между руководителями отделов заказчика. Но – сделали. И оно работает по сей день.
Выводы
Мораль этой басни очень простая: предполагайте, что вещи могут быть несовместимы друг с другом. Либо по своим характеристикам (как операционная система операторских мест и софт КЦ), либо в некоторых условиях (под нагрузкой и без нее), либо по человеческому фактору. И на бумаге все обычно нормально, но … It\’s always easier said than done.[:ua]Якби знав, де впадеш, не тільки соломи підстилай би, але й килимок би розкатав. Однак життя та практика подають такі сюрпризи, що навіть досвідчені спеціалісти іноді помиляються. І це може зірвати впровадження нового програмно-апаратного комплексу або реалізації відкриття колл-центру. Ось історія, що ґрунтується на реальних подіях. Завдяки стеченню обставин вона закінчилась гарно. Впровадження пройшло успішно, але все могло закінчитися погано. Якщо що, ми не впроваджували, але не повторюйте чужих помилок.
Стаття стосується інструменту для керівника
Вступ
У компанії \”Ромашка\” був власний колл-центр місткістю 200 місць, який складався з двох частин. Умовно назвемо їх відділом продажів і сервісною службою. Відділ продажів займався залученням нових клієнтів, обслуговуючи вхідні дзвінки та звернення через чати за допомогою хмарної CRM-системою.
Служба обслуговування надавала допомогу діючим клієнтам, обробляючи дзвінки за допомогою Asterisk, та проводила їх облік в CRM власної розробки (яка, до речі, одночасно використовувала цілих 4 РСУБД: MS SQL Server, Oracle, PostgreSQL та MySQL для комплекту, щоб не було нудно.
А ІТ-відділ був відокремленою організаційною одиницею і власну CRM не доробляв і не обслуговував, сервісники самі її періодично змінювали – так \”склалося історично\”. Компанія займалася виробництвом поставок обладнання.
Керівництво прийняло рішення впровадити платформу КЦ (запуск кол-центру в хмарі), щоб допомогти керівникам служб якимось чином розібратися з \”зоопарком\” інформаційних систем, дані в яких, звичайно, синхронізувалися, але \”якось не так\”. Передбачалося, що КЦ візьме на себе єдине управління дзвінками, а CRM-системи – управління контактами, при цьому КЦ буде отримувати контакт для обробки та повертати його назад в \”правильну\” CRM, тобто механізм синхронізації передбачалося реалізувати всередині \”шлунків\” контакт-центру. В принципі, така схема в деяких умовах можлива, тому що всередину \”хмари\” відділу продажів безпосередньо було не залізти, то по API.
Складності при запуску кол-центру та їх вирішення
Складності при запуску колл-центру виникли відразу. Вибравши платформу за ідеологічними міркуваннями, виникло питання об інтеграторі. Ми сформулювали технічні вимоги, запитали чотири компанії з приблизно однаковим досвідом, отримали чотири пропозиції з витривалим розсіянням цін у три рази. Як зрозуміти, кому доручити роботу? Ми обрали найбільш дешевого SIP-провайдера і, як це не дивно, вгадали, хлопці просто виявились менш безскрупульними, при цьому маючи достатню кваліфікацію. Але це було щастя, оцінка потенціалу інтеграторів не проводилася. А найгірше в бізнесі – це надія на щастя.
Ми підписали договір, і приступили до роботи. І тут виявилося, що з боку замовника відповідальною службою призначена ІТ (яка готувалася в своєму власному сусідстві і нічого про внутрішню CRM не знала, і не знала би, тому що документація просто не існувала в природі). Ми пішли до служби обслуговування, керівник пояснила, що у неї просто немає достатньої кількості годин програмістів, щоб допомогти з інтеграцією з платформою КЦ. Просто немає. Зате є затверджений генеральний план робіт, які усі, звичайно, відносяться до категорії “важливо-терміново”.
Ми пішли до керівника відділу продажів. Він відповів, що “за” двома руками, але впровадженням керувати не може, тому що не технік, а сейлз і у нього… свій план. Наполегливі представники інтегратора, виходячи на власника бізнесу відкололи години програмістів з IT і сервісного відділу. Руководителем впровадження з боку замовника був призначений…правильно…головний продавець!
Сіли писати та затверджувати технічне завдання. На цьому кое-хто зрозумів, що місця операторів можуть виявитися просто не сумісними з платформою call-центру через вимоги до операційної системи. Пройшло… але могло не пройти. Це треба перевіряти на передпроектному обговоренні, до підписання головного договору. Помилку допустив менеджер з боку інтегратора, за його словами, на тих місцях, які він бачив очима, ОС була та, яку треба. А що можуть бути місця, яких він не бачив – це він пропустив.
Спочатку намагались з\’єднати call-центр з хмарною CRM. З певним скрипом з\’єднали через API і зв\’язка з\’явилася… поки не перевірювали під реальним навантаженням. А там – число запитів до бази даних хмари за одиницю часу, виявляється, обмежено, причому про це ніде не сказано, просто даність. Загалом, проблема звелась до того, що конкретна хмара не витягує конкретний call-центр. Порахували бюджет на коробкове рішення – плакали і майже купили. Майже – тому що цього разу інтегратор задав правильне питання про міграцію даних з хмари в коробку. Виявилося, що під міграцію ресурсів точно не і не буде. За допомогою деяких витівок вдалося зменшити кількість запитів до хмари. Коробку не купували.
Настала пора з\’єднати КЦ з відділом сервісу. Безумовно, єдиний програміст зі служби підтримки, який міг допомогти, пішов у відпустку за три дні до початку робіт. Проєкт зупинився на два тижні (обов\’язково дивіться графіки відпусток ключових фахівців). Але коли людина повернулася – роботу виконали.
Настало питання, що робити з даними, які вже є в обох хмарах, щоб привести їх у відповідність між собою. До речі, там був складний маршрут контактів в залежності від того, в якому з CRM з яким статусом знайшовся контакт, тому протиріччя даних створювало для клієнтів чудовий досвід, наприклад, вічних циклів в IVR. Клієнти платили \”Ромашці\” великі гроші і були незадоволені, бо при проблемах з обладнанням у них порушувалася безперервність бізнесу. Вирішили існуючі дані \”залишити так, як є і потім очистити\”, а дані по новим клієнтам вже вести нормально. Це вдалося, але проблему, зрозуміло, не вирішило.
Майже дотримавшися термінів і (з трудом) технічних вимог, але не технічного завдання, інтегратор поставив перед собою завдання здати роботу. І ось тут виявилося, що звітність КЦ, на 100% відповідаюча ТЗ, є… непривабливою… її не люблять. Чому вона негарна і як переделасть – ніхто пояснити не зміг, є підозра, що просто не залишилося грошей на переделу. Взагалі, ще пара тижнів замовник продовжував бороться з інтегратором щодо естетичної привабливості звітності.
Було ще багато проблем, наприклад, виникли внутрішні конфлікти між керівниками відділів замовника. Але – зробили. І це працює досі.
Висновки
Мораль цієї байки дуже проста: припускайте, що речі можуть бути несумісними одна з одною. Або за своїми характеристиками (як операційна система операторських місць і софт КЦ), або в деяких умовах (під навантаженням і без неї), або за людським фактором. І на папері все зазвичай нормально, але … Завжди легше сказати, ніж зробити.[:pl]Gdybyś wiedział, gdzie upadniesz, nie tylko byś rozłożył słomę, ale też rozwinąłbyś matę. Jednak życie i praktyka sprawiają takie niespodzianki, że nawet doświadczeni specjaliści czasem się mylą. To może zepsuć wdrożenie nowego systemu sprzętowo-programowego lub realizację uruchomienia call center. Oto historia oparta na prawdziwych wydarzeniach. Dzięki zbiegowi okoliczności zakończyła się dobrze. Wdrożenie przebiegło pomyślnie, choć wszystko mogło skończyć się źle. Jeśli o coś chodzi, to my nie wdrażaliśmy, ale nie powtarzaj cudzych błędów.
Artykuł dotyczy narzędzia dla kierownika
Wstęp
Firma “Romashka” miała własne call center o pojemności 200 miejsc, które składało się z dwóch części. Nazwijmy je umownie działem sprzedaży i serwisem. Dział sprzedaży zajmował się pozyskiwaniem nowych klientów, obsługując przychodzące rozmowy i zamówienia za pośrednictwem czatów za pomocą chmurzą systemu CRM.
Usługa klienci korzystali z pomocy obsługi klienta, obsługując połączenia za pomocą Asterisk i prowadząc ich rejestrację w CRM opracowanym przez firmę (który, nawiasem mówiąc, korzystał równocześnie z czterech systemów zarządzania bazami danych: MS SQL Server, Oracle, PostgreSQL i MySQL, aby nie było nudno).
A Dział IT był oddzielną jednostką organizacyjną i nie rozbudowywał ani nie obsługiwał własnego CRM, dusicieli okresowo sami je ulepszali – \”historia się tak wytworzyła\”. Firma zajmowała się produkcją i dostawą sprzętu.
Zarząd podjął decyzję o wdrożeniu platformy Contact Center (uruchomienie call center w chmurze), aby pomóc kierownikom działów poradzić sobie z \”zoo\” systemów informacyjnych, które naturalnie synchronizowały dane, ale \”jakoś nie tak\”. Przewidywano, że centrum kontaktowe będzie zarządzało połączeniami, a CRM – kontakty, przy czym centrum kontaktowe będzie otrzymywało kontakt do przetworzenia i zwracało go z powrotem do \”prawidłowego\” CRM, tzn. mechanizm synchronizacji zakładano zaimplementować w \”wnętrzu\” centrum kontaktowego. W zasadzie, taki schemat jest możliwy w pewnych warunkach, ponieważ bezpośrednio do \”chmury\” działu sprzedaży nie można było wejść, zatem przez API.
Trudności z uruchomieniem centrum kontaktowego i jak je rozwiązano
Trudności z uruchomieniem call center pojawiły się natychmiast. Ze względów ideologicznych wybrano platformę, pojawiło się pytanie o integratora. Napisaliśmy wymagania techniczne, poprosiliśmy cztery firmy z mniej więcej równym doświadczeniem, otrzymaliśmy cztery oferty z trzykrotnym rozrzutem cen. Jak zrozumieć, komu powierzyć pracę? Wybraliśmy najtańszego dostawcę SIP i, co dziwne, zgadliśmy, chłopaki okazali się po prostu najmniej bezczelni, przy tym mając wystarczające kwalifikacje. Ale to był szczęśliwy zbieg okoliczności, ocena potencjału integratorów nie była przeprowadzona. A najgorsze w biznesie to poleganie na szczęściu.
Podpisaliśmy umowę, przystąpiliśmy. I wtedy okazało się, że ze strony klienta odpowiedzialnym działem jest IT (który gotowany był w swoim sosie i nie wiedział nic o wewnętrznym CRM, a nawet by się nie dowiedział, ponieważ dokumentacja po prostu nie istniała w naturze). Poszliśmy do działu obsługi, kierownik wyjaśnił, że po prostu nie ma wystarczającej liczby godzin programistów, aby pomóc w integracji z platformą Call Center. Po prostu nie ma. Ale jest zatwierdzony ogólny plan pracy, które są oczywiście, wszystkie z kategorii \”ważne-pilne\”.
Poszliśmy do kierownika działu sprzedaży. Odpowiedział, że jest \”za\” obiema rękami, ale nie może kierować wdrożeniem, ponieważ nie jest technikiem, a sprzedawcą i ma… swój plan. Przedstawiciele integratora z trudnością, z dużym skrzypem, nawiązując kontakt z właścicielem To fragment artykułu do strony docelowej. Piszesz to przez doświadczonego marketologa, który pracował jako kierownik działu sprzedaży w centrum kontaktowym. Używaj perswazyjnego języka, podkreślaj kluczowe punkty biznesu, pochłonęło godziny programistyczne od IT i działu serwisowego. Kierownikiem wdrożenia ze strony klienta był wtedy wyznaczony… tak… główny sprzedawca! Napisaliśmy i zatwierdziliśmy specyfikację techniczną. Na tym etapie niektórzy zrozumieli, że stanowiska operatorów mogą być po prostu niekompatybilne z platformą centrum kontaktowego z powodu wymogów dotyczących systemu operacyjnego. Udało się mimo wszystko… ale mogło nie. Należy to sprawdzić podczas przedprojektowych dyskusji, przed podpisaniem głównej umowy. Błąd popełnił menedżer ze strony integratora, które, według jego słów, na miejscach, które widział na własne oczy, system operacyjny był taki, jak powinien być. To, że mogą być miejsca, których on nie widział – to on przegapił.[:es]Si supieras dónde vas a caer, no solo pondrías paja en el suelo, sino que también extenderías una alfombra. Sin embargo, la vida y la práctica nos presentan sorpresas tales, que incluso los especialistas experimentados a veces cometen errores. Y esto puede sabotear la implementación de un nuevo sistema de hardware y software o el lanzamiento de un call-center. Aquí una historia basada en eventos reales. Gracias a una serie de circunstancias, terminó bien. La implementación fue un éxito, pero todo podría haber terminado mal. Si es que, no fuimos nosotros quienes implementamos, pero no repitan los errores ajenos.
El artículo pertenece a herramientas para el líder
Introducción
La empresa “Romashka” tenía su propio centro de contacto con capacidad para 200 posiciones, compuesto por dos partes. Condicionalmente, los llamaremos departamento de ventas y servicio al cliente. El departamento de ventas se ocupaba de atraer nuevos clientes, atendiendo llamadas entrantes y solicitudes a través de chats con ayuda de un sistema CRM.
El servicio al cliente brindaba asistencia a los clientes existentes, manejando llamadas con Asterisk, y llevaba su registro en unos CRM de desarrollo propio (que, por cierto, utilizaba simultáneamente cuatro DBMS: MS SQL Server, Oracle, PostgreSQL y MySQL para que no fuera aburrido).
El departamento de IT era una unidad organizativa separada y no desarrollaba ni mantenía su propio CRM, los técnicos de servicio periódicamente la mejoraban – así fue \”históricamente\”. La empresa se dedicaba a la fabricación y suministro de equipos.
La dirección decidió implementar la plataforma CC (lanzar un call-center en la nube), para ayudar a los líderes de servicios a lidiar con el \”zoológico\” de sistemas de información, cuyos datos, naturalmente, se sincronizaban, pero \”de alguna manera no del todo bien\”. Se suponía que el CC asumiría la gestión unificada de las llamadas, y los sistemas CRM – la gestión de contactos, mientras que el CC recibiría el contacto para su procesamiento y lo devolvería a la \”correcta\” CRM, es decir, se pretendía implementar un mecanismo de sincronización dentro de las \”entrañas\” del centro de contacto. En principio, tal esquema es posible en ciertas condiciones, porque no se podía acceder directamente al \”cloud\” del departamento de ventas, sino por API.
Dificultades en el lanzamiento del call-center, y sus soluciones
Las dificultades en el lanzamiento del call-center surgieron de inmediato. Por razones ideológicas se eligió la plataforma, y luego surgió la pregunta sobre el integrador. Se escribieron los requisitos técnicos, se solicitaron propuestas a cuatro compañías con experiencia similar, y se recibieron cuatro ofertas con una variación de precios de tres veces. ¿Cómo saber a quién confiar el trabajo? Escogieron al proveedor SIP más barato y, sorprendentemente, acertaron; los chicos resultaron ser los menos audaces, pero aun así tenían la calificación adecuada. Pero fue suerte, no se realizó una evaluación del potencial de los integradores. Y lo peor en los negocios es confiar en la suerte.
Firmaron el contrato, y comenzaron. Y entonces resultó que, por parte del cliente, el departamento asignado como responsable fue IT (que estaba aislado en su propio mundo y no sabía nada sobre el CRM interna, y no lo sabría, porque simplemente no existía documentación al respecto). Se dirigieron al servicio al cliente, la líder explicó que simplemente no tenían suficientes horas-programador para ayudar con la integración con la plataforma CC. Simplemente no. Pero tenían un plan de trabajo aprobado por la gerencia, que, por supuesto, todo era de categoría \”importante-urgente\”.
Luego fueron al líder del departamento de ventas. Respondió que estaba completamente a favor, pero no podía liderar la implementación, porque no era técnico, sino de ventas y tenía… su propio plan. De alguna manera, con mucha dificultad, los representantes del integrador, contactando al propietario del negocio, obtuvieron horas de programador de IT y del departamento de servicio. El líder de la implementación por parte del cliente fue nombrado… correcto… ¡ el principal de ventas!
Se sentaron a escribir y aprobar los requisitos. En este punto, algunos se dieron cuenta de que las estaciones de trabajo de los agentes podrían no ser compatibles con la plataforma CC debido a los requisitos del sistema operativo. Se salvaron… pero podrían no haberlo hecho. Esto debe verificarse en la discusión previa al proyecto, antes de firmar el contrato principal. El error fue cometido por el gerente por parte del integrador, quien dijo que en las estaciones que vio, el SO era el correcto. Pero pasó por alto que podría haber estaciones que no había visto.
Lo primero que intentaron fue conectar el CC con la CRM en la nube. Con cierta dificultad se conectaron mediante API y la combinación funcionó… hasta que no se probó bajo carga real. Ahí fue cuando – el número de solicitudes a la base de datos en la nube por unidad de tiempo, resulta estar limitado, y esto no estaba indicado en ninguna parte, simplemente es así. En resumen, el problema se redujo a que la nube específica no podía manejar el CC específico. Calcularon el presupuesto para una solución en sitio – se estremecieron y casi la compraron. Casi – porque esta vez el integrador hizo la pregunta correcta sobre la migración de datos de la nube a la caja. Resultó que la migración de recursos definitivamente no era una opción. De alguna manera, lograron reducir el número de solicitudes a la nube. No compraron la caja.
Llegó la hora de conectar el CC con el departamento de servicio. Por supuesto, el único programador de allí que podía ayudar, se fue de vacaciones tres días antes de comenzar el trabajo. El proyecto se detuvo durante dos semanas (verifique los horarios de vacaciones de los especialistas clave, definitivamente). Pero cuando la persona regresó, se hizo el trabajo.
Surgió la pregunta de qué hacer con los datos que ya existían en ambas nubes, para reconciliarlos entre sí. Por cierto, había un esquema complejo de enrutamiento de contactos, dependiendo de en cuál CRM y con qué estado se encontraba el contacto, por lo que la contradicción de datos creó para los clientes una experiencia asombrosa como ciclos eternos en IVR. Los clientes pagaban a \”Romashka\” mucho dinero y no estaban muy contentos, porque cuando había problemas con el equipo, se interrumpía la continuidad de su negocio. Decidieron \”dejar los datos existentes como estaban y limpiarlos después\”, y los datos de los nuevos clientes ya se manejaban correctamente. Esto funcionó, pero obviamente, el problema no se resolvió.
Casi dentro de los plazos y (con dificultad) dentro del marco de los requisitos técnicos, pero no de los requisitos, el integrador fue a entregar el trabajo. Y aquí resultó que los informes del CC, aunque cumplían 100% con los requisitos, eran… poco atractivos… no gustaban. Por qué eran poco atractivos y cómo modificarlos, nadie pudo explicar, hay sospechas de que simplemente no quedaba dinero para hacerlo. En general, el cliente discutió con el integrador durante un par de semanas más sobre la estética de los informes.
Hubo muchos más problemas, por ejemplo, surgieron conflictos internos entre los líderes de los departamentos del cliente. Pero – se hizo. Y funciona hasta hoy.
Conclusiones
La moraleja de esta fábula es muy simple: supongan que las cosas pueden ser incompatibles entre sí. Ya sea por sus características (como el sistema operativo de los puestos de operadores y el software del CC), o bajo ciertas condiciones (con carga y sin ella), o por el factor humano. Y en papel, todo suele estar bien, pero… It\’s always easier said than done.[:tr]Keşke düşeceğin yeri bilsen, sadece saman değil, bir de halı sererdin. Ancak hayat ve pratiğin getirdiği sürprizler, hatta deneyimli uzmanların bile zaman zaman hatalar yapmasına neden olur. Bu, yeni bir yazılım ve donanım kompleksi veya çağrı merkezinin lansmanının başarısız olmasına yol açabilir. İşte gerçek olaylara dayanan bir hikaye. Şans eseri iyi sonuçlandı. Yürütme başarılı oldu, ancak her şey kötü bitebilirdi. Biz yapmadık, ama başkalarının hatalarını tekrarlamayın.
Çağrı merkezi yöneticisi için araç ile ilgili bir makaledir.
Giriş
“Romashka” şirketinde 200 kişilik kendi çağrı merkezi vardı, bu iki bölümden oluşuyordu. Bunları koşullu olarak satış departmanı ve servis bölümü olarak adlandıralım. Satış departmanı yeni müşterileri çekmek, gelen çağrılara ve chat üzerinden taleplere CRM-sistem kullanarak cevap veriyordu.
Servis bölümü, Asterisk kullanarak mevcut müşterilere destek sağlıyordu ve kendi geliştirdikleri CRM\’de (bu arada, sıkıcı olmaması için tam bir set olarak MS SQL Server, Oracle, PostgreSQL ve MySQL olmak üzere tam dört RDBMS kullanıyordu) işlemlerini yönetiyordu.Ve BT departmanı ayrı bir organizasyon birimi olarak kendi CRM\’ini geliştirmedi ve desteklemedi, servis teknisyenleri zaman zaman kendileri bunu dönem dönem yeniliyorlardı – bu tarihsel olarak böyle gelişti. Şirket ekipman üretimi ve tedarikiyle ilgileniyordu.
Yönetim, yöneticilerin farklı bilgi sistemlerinin \”hayvanat bahçesi\” ile başa çıkmasına yardımcı olmak için bir ÇM (bulut çağrı merkezi lansmanı) platformu yürütmek konusunda karar aldı. Burada, verilerin doğal olarak senkronize edildiği, ancak \”bir şekilde takılmadan\” farklı bilgi sistemleri arasında karmaşıklıklar mevcuttu. ÇM\’nin tek bir çağrı yönetimi üzerinden sorumlu olması ve CRM sistemlerinin de müşteri yönetimini üstlenmesi öngörülüyordu. Dolayısıyla, ÇM, işleme için bir müşteri bilgisini alacak ve sonra onu \”doğru\” CRM sistemine geri gönderecek, yani senkronizasyon mekanizması çağrı merkezinin \”iç yapısında\” gerçekleştirilecekti. Esasen, belirli koşullar altında, bu tür bir düzenleme mümkündü, çünkü satış departmanına doğrudan API aracılığıyla erişilebilirdi.
Çağrı merkezinin başlatılmasında karşılaşılan zorluklar ve çözümleri
Çağrı merkezinin başlatılmasında hemen zorluklar ortaya çıktı. İdeolojik nedenlerle bir platform seçildikten sonra, entegratör konusu açılır. Teknik şartları yazdık, deneyimleri yaklaşık olarak aynı olan dört şirketten teklif talep ettik, fiyatları üç kat farklı olan dört teklif aldık. Kime işi vermeniz gerektiğini nasıl anlarsınız? En ucuz SIP sağlayıcısını seçtik ve garip bir şekilde, sadece en az yüzsüz olanlar olmadıkları için, aynı zamanda yeterli niteliklere de sahip olduklarını keşfettik.
Ancak bu, şans eseriydi, entegratörlerin potansiyelinin değerlendirilmesi yapılmadı. Ve iş dünyasında en kötü şey, şansa güvenmektir.Sözleşme imzalandı, işe koyulduk. Ve işte, müşteri tarafından atanan sorumlu servis BT oldu (kendi içinde kaynayan ve kendi CRM\’i hakkında hiçbir şey bilmeyen, çünkü doğada dokümantasyon yoktu). Servis bölümüne gittik, müdür entegrasyonla ilgilenmek için yeterli programcı saatine sahip olmadıklarını açıkladı. Sadece yok. Ancak genel olarak “acil-önemli” kategorisinden işler için onaylanmış bir plan var.
Satış departmanının müdürüne gittik. O, iki eliyle \”destek veriyorum\” dedi, ama yönetimi üstlenemez, çünkü o bir teknik uzman değil, bir satışçı ve onun…kendi planı var. Zor bela, işin sahibiyle iletişime geçerek, entegratör temsilcileri, BT ve servis bölümünden programcı saatleri ayırttı. Projeye müşteri tarafından atanmış yönetici olarak…doğru…baş satış görevlisi oldu!Teknik görevi yazıp onaylamak için oturduk. Bu sırada birileri, işletme istasyonları ÇM platformu ile işletim sistemleri gereksinimleri nedeniyle uyumsuz olabileceğini fark etti.
Ancak sorun yaşanmadı…ama yaşanabilirdi. Bu, ana sözleşme imzalanmadan önce, ön tasarım görüşmelerinde kontrol edilmesi gereken bir şeydi. Hata, entegratör tarafındaki yöneticiden kaynaklandı, kendi sözlerine göre, gözleriyle gördüğü çalışma istasyonlarında istenen işletim sistemi vardı. Ama göremediği istasyonların olabileceğini gözden kaçırdı.İlk iş olarak, ÇM\’i bulut CRM ile birleştirmeye çalıştılar. Biraz zorlukla API üzerinden bağlandılar ve kombinasyon oldukça iyi çalıştı…gerçek yük altında test edene kadar. Ve orada – belirli bir zaman diliminde, buluta yapılan sorgu sayısı sınırlıymış meğerse, bu hakkında hiçbir yerde hiçbir şekilde söz edilmemiş, sadece bir gerçekmiş. Genelde, sorun, belirli bir bulutun belirli bir ÇM\’i destekleyemediği gerçeğine indirgendi. Kutulu çözüm için bütçeyi hesapladılar – gözyaşlarına boğuldular ve neredeyse satın aldılar. Neredeyse – çünkü bu sefer entegratör, buluttan kutuya veri göçü hakkında doğru soruyu sordu. Çıkış olarak, kaynaklar kesinlikle göç etmeyecek. Bazı manevralarla buluta olan sorgu sayısını azaltmayı başardılar. Kutuyu satın almadılar.
Servis departmanı ile ÇM\’i bağlama saati geldi. Tabii ki, oradan yardımcı olabilecek tek programcı, işe başlamadan üç gün önce izne ayrıldı. Proje iki hafta durdu (anahtar uzmanların tatil programlarını kesinlikle kontrol edin). Ancak kişi döndüğünde, iş tamamlandı.
Her iki bulutta da zaten mevcut olan verilerle ne yapılacağı sorunu ortaya çıktı, bunları birbiriyle uyumlu hale getirmek gerekiyordu. Bu arada, hangi CRM\’de hangi durumda olursa olsun bir temasa bağlı olarak iletişim yönlendirme şeması oldukça karmaşıktı, bu yüzden veri çelişkileri müşteriler için IVR\’de ebedi döngüler gibi şaşırtıcı bir deneyim yarattı. Müşteriler \”Romashka\”ya iyi para ödüyor ve memnun değillerdi çünkü ekipmanla ilgili sorunlar olduğunda iş sürekliliği bozuluyordu. Mevcut verileri \”olduğu gibi bırak ve sonra temizle\”, yeni müşterilerin verilerini ise normal şekilde tut kararına vardılar. Bu işe yaradı, ama sorunu, elbette, çözmedi.
Neredeyse zamanında ve (zorlukla) teknik şartlara uygun olarak, ancak teknik görevi tam olarak karşılayamayarak, entegratör işi teslim etmeye gitti. Ve işte burada, %100 TZ\’ye uygun ÇM raporlarının…güzel olmadığı…hoşlanılmadığı ortaya çıktı. Neden güzel olmadığı ve nasıl düzeltileceği konusunda kimse açıklayamadı, yeniden düzenleme için basitçe para kalmamış olabilir. Genel olarak, müşteri birkaç hafta daha entegratörle raporların estetik cazibesi konusunda mücadele etti.Daha birçok sorun vardı, örneğin, müşterinin departman yöneticileri arasında iç çatışmalar ortaya çıktı. Ama – başardılar. Ve bu, bugüne kadar çalışıyor.
Sonuç
Bu masalın morali çok basit: Şeylerin birbirleriyle uyumsuz olabileceğini varsayın. İster işletim sistemleri ve ÇM yazılımı gibi kendi özellikleriyle (ister yük altında ve yük altında olmadan bazı koşullarda), ister insan faktörüyle olsun. Ve kağıt üzerinde her şey genellikle iyidir, ama … It\’s always easier said than done.[:]