Как внедрение IP-телефонии вылилось в создание федерального колл-центра, работающего во всех часовых поясах России

Запрос клиента был стандартным. Всего-навсего нужно было подключить IP-телефонию, но затем случилось непредвиденное… замена телефонной станции, которая, хоть устарела, но еще бы проработала сто лет, вылилась в непростую и временами запутанную интеграция с SAP. Особую остроту “сюжет” приобрел, когда внезапно выяснилось, что немало менеджеров заказчика просто бездельничают на рабочих местах под прикрытием вечной занятости, после этого конечно же последовали кардинальные перемены в бизнесе клиента. Да такие, которые ни он, ни наша компания не могли предвидеть до начала проекта…

Начинали мы с базовых вещей, не думая о масштабе, а вышло так, что пришлось поднимать целину. Вначале нужно было просто “закрутить лампочку”: подключить IP-телефонию и установить шлюз для передачи данных из одного формата в другой, чтобы исключить потенциальный конфликт между старым оборудованием и новыми технологиями операторов связи, с чем мы легко и быстро справились, и по горячим следам нам предложили еще одну задачу по замене телефонной станции. Едва мы погрузились в процесс и вошли во вкус, как возникла авантюрная идея, почему бы нам не интегрироваться с SAP, чтобы вся работа менеджеров нашего клиента была видна ему как на ладони: запись любых звонков, контроль за работой менеджеров, длительностью и качеством разговоров.

Проще говоря, мы предложили революционные изменения в работе “продажников”, что, конечно же, не нашло у них поддержки и не вызвало никакого энтузиазма, скорее наоборот — серьезное сопротивление, с которым мы столкнулись в ходе дальнейшей работы. Зато нашу сторону принял IT-директор, он выторговал для нас необходимый бюджет и предложил показать, на что мы способны и даже заплатил за наш “пилот”, с которым мы приняли участие в конкурсе, где выиграли в напряженной борьбе у крупных и серьезных компаний.

Мы настроили маршрутизацию звонков из нескольких источников: ERP-системы, в которой велся учет клиентов и их заказов, а также из ActiveDirectory, места хранения учетных записей сотрудников, эдакое досье на каждого из них: в каком кабинете работает, к какой группе персонала относится, какой ip-телефон и т.д.). Все это напрямую влияло на обработку звонков.

После наших нововведений при обработке входящего вызова если менеджер по каким-то причинам в течение 30 секунд не отвечал на звонок, например, уже был занят разговором с клиентом, то вызов переадресовывался на его коллегу из этой же группы сотрудников, либо на руководителя или секретаря. Основным критерием для выбора того или иного варианта маршрутизации был статус собеседника.

Исходя из того, что офисы компании работали в разных часовых поясах, мы настроили маршрутизацию так, что если, например, в Москву в нерабочее время поступал звонок из Сахалина, то мы перенаправляли его в тот офис, который мог сейчас его обработать.

Но нам и этого было мало. Если уж работать за деньги, то по-настоящему. Поэтому мы реализовали уникальное решение по контролю звонков с мобильных телефонов менеджеров. После подключения услуги FMC оператора мобильной связи, которая позволила подключить корпоративную группу мобильных телефонов к IP-АТС, и необходимых настроек, все вызовы с мобильных теперь обрабатывались нашей системой. Только по-хитрому, не так, как у всех, а более продуманно.

Изначально нам предложили стандартную услугу, но она не полностью закрывала наши потребности, в связи с чем у нас возникла интересная идея. Над реализацией которой днями и ночами бились не только мы, но и наши коллеги из стана мобильного оператора. Мало того, что это новшество нужно было продвинуть среди руководства, но еще и реализовать технически. До нас в России этого никто еще не делал, поэтому это был настоящий вызов из разряда шекспировского “быть или не быть”, особенно для инженеров нашего партнера. Но чего не сделаешь ради заказчика:)

В торговом бизнесе заказчика 60% коммуникаций происходило между менеджерами и клиентами напрямую по мобильным. И мы решили, а что если настроить маршрутизацию на стороне мобильного оператора таким образом, чтобы любой звонок клиента менеджеру на мобильный, либо, наоборот, обрабатывался нашей IP-АТС, и вся статистика по звонку, в том числе и запись разговора, попадала в нашу ERP-систему. Для участников разговора все оставалось прежним: звонок как звонок, но в распоряжение заказчика попадал обработанный массив Big Data, благодаря чему он мог влиять на развитие своего бизнеса. Что и произошло довольно быстро:)

Теперь разговоры “продажников” с клиентами менее 15 секунд просто-напросто не засчитывались заказчиком. Важна была именно результативность звонков, так как продажи в бизнесе нашего клиента были транзакционными, и количество выставленных счетов на оплату напрямую зависело от объема качественно обработанных вызовов.

Ну и самое главное, что теперь наша схема маршрутизации разделяла клиентов заказчика по обслуживающим их менеджерам и по формату ABC (крупные, средние, мелкие). В дополнение к ним мы еще учли неидентифицированных клиентов.

В результате все звонки оказались под контролем, их можно было без проблем передать в ERP-систему и прикрепить запись разговора к клиентской карточке.

Тем не менее менеджеры не планировали напрягаться и отчаянно сопротивлялись нашим нововведениям. То клиентов было плохо слышно, то у них ничего не работало, и они упорно продолжали звонить в обход внедренной системы. Ну и разумеется план продаж не выполнялся: то цены были высокими, то клиенты не хотели с ними общаться. И все это время менеджеры умудрялись показывать свою загруженность, бомбардируя нас жалобами. Иногда их количество доходило до сотни в день. Правда, они ничем не подтверждались.

Мы, конечно, не сдавались под нажимом “продажников” и продолжали погружаться в бизнес клиента, но в какой-то момент даже нам показалось, что проект вот-вот развалится, и мы уйдем, ограничившись IP-телефонией, как за нас вступился руководитель IT-отдела заказчика. Ему удалось убедить гендиректора в срочном “ремонте” бизнеса и коммерческую службу просто вынудили работать по-новому. Им сформировали новый план звонков и благодаря созданной нами системе легко было проконтролировать его исполнение и получить отчет по исходящим звонкам.

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

1. На две ноги хромала интеграция с ERP-системой, построенной в форме SAP.

Это был один из самых сложных этапов проекта. И его реализацией мы занимались вместе с заказчиком и его подрядчиком. Мы не могли подключиться к SAP напрямую из нашей учетной записи для получения оттуда данных, они были закрыты от нас жесткой системой безопасности.

Нам требовалась учетка с доступом к информации из SAP для маршрутизации всех звонков и в то же время эта учетка не должна была быть нашей, ведь у данного SAP не было API-интерфейса и доступ к его данным был закрыт. Казалось, что все, вот он тупик. Тем более нам требовалось не только получать оттуда данные, но и вносить в них изменения.

Тогда мы вместе с командой заказчика разработали архитектуру интеграции с промежуточным слоем, который был одновременно подключен и к SAP и к IP-телефонии. Благодаря этому можно было получать и записывать данные из SAP и в то же время подключаться через API-интерфейс к IP-телефонии. Условно говоря, мы создали мост для обмена информацией.

2. Медленная обработка данных SAP с IP-телефонии.

.Здесь мы столкнулись с весомым противоречием между SAP и IP-телефонией. Последняя работала в реальном времени, когда SAP, дискретная система, обрабатывала все задачи потоково в порядке очереди. Проблема наметилась серьезная, ведь никакой звонок не мог ждать обработки SAP запроса “Кто нам звонит?”. Была критически важна скорость. Ежедневно в компанию заказчика поступало до 10 000 входящих звонков, SAP выстраивал их в очередь, медлил с ответом, часть клиентов упорно не замечал, хотя сведения о них уже были в нашей системе, и методично выдавал ошибку.

Мы уже подозревали конфликт нашего сервиса подключения к SAP с системой его безопасности, раз данные приходили либо частично либо не доходили вовсе.

Мы разобрались с этой трудностью с помощью регулярной ночной выгрузки из SAP обезличенных данных, по которым было невозможно идентифицировать клиентов, но этой информации хватало для выполнения маршрутизации. Например, номера телефонов клиентов, номера закрепленных менеджеров и т.д.

Таким образом в SAP приходили запросы только по тем клиентам, которых не было в базе, и согласно нашим настройкам такие запросы обрабатывались приоритетно, что стало возможным благодаря резкому снижению их количества и уменьшению нагрузки на SAP.

3. Ограничения SAP по количеству одновременно открытых окон.

Мы создали карточку звонка внутри SAP со всеми данными по клиенту. Но проблема заключалась в том, что у менеджера обычно всегда было открыто несколько окон по текущей работе, и наша карточка уже не открывалась. Тогда нам пришлось создать еще одну карточку клиента, только вне SAP. Это решение далось нам большой кровью из-за сложной интеграции с SAP, на все про всё ушло около полугода. Зато теперь можно было без проблем открыть любого клиента в SAP и быстро выставить ему тот же счет.

С карточкой клиента раньше тоже была полная неразбериха. Клиенты звонили с разных телефонов, но не все их номера были внесены в систему, поэтому многие вызовы она ошибочно определяла как неидентифицированные, хотя информация о звонивших уже была в базе данных.

Мы рассудили так, что если хоть однажды клиент поработал с нашим заказчиком, значит уже известен его ИНН, по которому можно найти номера телефонов во внешних базах данных и добавить их в ERP-систему.

Вдобавок к этому мы настроили автоматический сбор информации в клиентскую карточку из той же ERP-системы и внешних баз данных, таких как “Контур-Фокус”, СБИС, “2ГИС” и т.д. Клиент вам еще не позвонил, а вы уже все о нем знаете.

Коммерческая служба, уцепившись за неработающую карточку клиента, отчаянно воевала с IT-отделом. Во время тестов с ней было все хорошо, карточка открывалась, все работало, мы уже с облегчением выдохнули, как ее запуск в рабочем режиме провалился. Во время тестирования мы не имитировали реальные условия работы менеджера, и, когда запустили этот функционал с текущими клиентами заказчика, карточка перестала открываться из-за лимита SAP по открытым окнам, данные по клиенту не передавались в SAP, и ее приходилось заполнять заново. Весь проект был на грани провала, менеджеры по продажам довольно потирали ладошки и работали по-старинке, пока мы в авральном режиме занимались доработкой карточки. На это у нас ушло целых полгода и все это время отношения с заказчиком были напряженными: мы делали все быстро, поэтому ошибки были неизбежными и мы исправляли их по горячим следам. Тем не менее проблема с карточкой была решена.

На изменения клиентской карточки, борьбу с неразворотливым SAP и сопротивлением менеджеров заказчика у нас ушло полгода. Только тогда наш проект заработал полномасштабно, и у гендиректора заказчика, к несчастью для его менеджеров, появилась возможность познакомиться с цифрами. Довольно быстро стало понятно, что бизнес мог бы развиваться гораздо быстрее, и столько менеджеров не нужно, поэтому “лишних” сразу уволили.

Для оставшихся менеджеров изменили систему мотивации, сделав упор на количество и качество звонков. В торговом бизнесе заказчика каждый звонок был потенциальной продажей. Условно говоря, не сделал менеджер в течение суток 100 звонков, значит ничего не продал и не выполнил план.

Еще мы учли, что крупные клиенты практически никогда не звонят сами, и им нужно продавать по исходящим звонкам. С мелкими и неидентифицированными клиентами напротив мы предложили упростить работу и вести ее через колл-центр, чтобы не отвлекать менеджеров на решение типовых вопросов, например, выставление счетов. Наша статистика показала, что на этих клиентов (физические лица и малый бизнес) приходится большая часть всех звонков и наименьшая доля выручки по сравнению с остальными группами.

Правда, заказчик упорно не соглашался на колл-центр, тем не менее мы не сдавались, убеждали его и по итогу договорились на компромиссный вариант: сформировали группу из 8-10 секретарей, которые работали в разных часовых поясах и перераспределили на них звонки из этих групп. В случае необходимости всегда можно было переадресовать звонок на менеджера. Объем этих звонков был таков, что секретари с ним не справлялись…

Тогда заказчик дрогнул и все же согласился на колл-центр, который был открыт в Екатеринбурге и работал круглосуточно.

Теперь туда сыпались все заявки по таким типовым вопросам, как выставление счетов, консультации по логистике, товару и т.д., зато менеджеры освободились для работы с более крупными клиентами, и компания одним махом сумела убить двух зайцев: крупные клиенты платят больше остальных, соответственно, и менеджеры могут заработать больше. Клиенты были довольны и выручка сильно увеличилась.

Что еще нужно для счастья?) Так мы и размотали этот клубок ценой своих нервов и невероятных усилий и благодаря поддержке IT-директора заказчика, который неоднократно убеждал своего шефа в необходимости финансирования нашего проекта.

После реализации нашего проекта заказчик, используя Big Data и IT-инструменты управления и контроля смог в разы ускорить обработку вызовов, обслуживать больше клиентов и существенно увеличить выручку за то же время, что и раньше. Мы же добавили в свою копилку интересный кейс, успешно справились с нестандартными задачами, проявили себя как надежный деловой партнер и, конечно же, хорошо заработали. Самое главное, что все счастливы и довольны, система работает, проблемы решены, и в бизнесе клиента теперь все разложено по полочкам.

#жил_был_проект #omniline

Больше информации о технологиях, клиентском сервисе, автоматизации вы найдете на нашем сайте, в Telegram-канале и на нашей странице в Facebook