23.03.2021

Возможные проблемы при запуске колл-центра

История о запуске колл-центра. О сложностях, с которыми пришлось столкнуться при внедрении с Оки-Токи, и как мы их решили!

Возможные проблемы при запуске колл-центра

Знал бы где упадешь, не только соломки бы подстелил, но и коврик бы раскатал. Однако жизнь и практика подбрасывают такие сюрпризы, что даже опытные специалисты порой ошибаются. И это может сорвать внедрение нового программно-аппаратного комплекса или реализации запуска колл-центра. Вот история, основанная на реальных событиях. Благодаря стечению обстоятельств она закончилось хорошо. Внедрение прошло успешно, но все могло закончиться плохо. Если что, внедряли не мы, но не повторяйте чужих ошибок.

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

Вводная

В компании “Ромашка” был собственный контакт-центр емкостью 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.

Оцените новость:

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

photo
Пятница Июль 7, 2023 Что такое FCR: Методология измерения First Call Resolution

Узнайте, что представляет собой FCR и как измерять первичное разрешение звонка с помощью этой методологии. Эффективный способ повышения качества обслуживания клиентов.

Подробнее
photo
Четверг Июнь 10, 2021 Оки-Токи: Как сделать отчет по sip звонкам

Подробная видеоинструкция, как сделать отчет по sip звонкам в сервисе Оки-Токи для внутренних и аутсорсинговых контакт-центров.

Подробнее