23.03.2021

Можливі проблеми при запуску кол-центру

Історія про запуск кол-центру. Про складнощі, з якими довелося зіткнутися при впровадженні з Оки-Токи, і як ми їх розв’язали!

Можливі проблеми при запуску кол-центру

Якби знав, де впадеш, не тільки соломи підстилай би, але й килимок би розкатав. Однак життя та практика подають такі сюрпризи, що навіть досвідчені спеціалісти іноді помиляються. І це може зірвати впровадження нового програмно-апаратного комплексу або реалізації відкриття колл-центру. Ось історія, що ґрунтується на реальних подіях. Завдяки стеченню обставин вона закінчилась гарно. Впровадження пройшло успішно, але все могло закінчитися погано. Якщо що, ми не впроваджували, але не повторюйте чужих помилок.

Стаття стосується інструменту для керівника

Вступ

У компанії “Ромашка” був власний колл-центр місткістю 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% відповідаюча ТЗ, є… непривабливою… її не люблять. Чому вона негарна і як переделасть – ніхто пояснити не зміг, є підозра, що просто не залишилося грошей на переделу. Взагалі, ще пара тижнів замовник продовжував бороться з інтегратором щодо естетичної привабливості звітності.

Було ще багато проблем, наприклад, виникли внутрішні конфлікти між керівниками відділів замовника. Але – зробили. І це працює досі.

Висновки

Мораль цієї байки дуже проста: припускайте, що речі можуть бути несумісними одна з одною. Або за своїми характеристиками (як операційна система операторських місць і софт КЦ), або в деяких умовах (під навантаженням і без неї), або за людським фактором. І на папері все зазвичай нормально, але … Завжди легше сказати, ніж зробити.

Оцініть новину:

Читайте також

photo
Неділя Травень 5, 2019 Дайджест новин Окі-Токі за квітень 2019

Новини Окі-Токі за квітень 2019 року: оптимізація імпорту, адресна книга в новому опермісці, чорний список для вихідних дзвінків, інтеграція з AMOCRM.

Детальніше
photo
Четвер Січень 23, 2020 Автоматичний дзвінок боржникам: Як автоматизувати дзвінки боржникам?

У цій статті ми розповімо, чому краще відмовитись від ручного дзвінка боржникам і які інструменти колл-центру допоможуть автоматизувати процес.

Детальніше