Хорошо сделаный колл центр приносит пользу: подтверждает заказы, напоминает о конференциях и доставке готовой еды. У нас в Voximplant есть модуль ACD и концепция очередей, с их помощью на платформе можно за пару часов собрать простое решение для распределения звонков. Почему “простое”? Действительно сложные решения сильно отличаются друг от друга, невозможно сделать модуль, который бы подошел “всем и сразу из коробки”. Однако есть проверенная в бою схема, по которой клиенты реализуют логику очередей на своем бэкенде, а наше облако помогает с маршрутизацией входящих звонков и аналитикой. Под катом небольшая пошаговая инструкция: как и зачем делать колл центры на сотню операторв «под себя». “Схема рабочая, инфа 100%” (с)
Тандем здорового человека: бэкенд + веб-клиент
Строгих требований к бэкенду нет, можно использовать условный Digital Ocean (правда, на момент написания статьи уже были проблемы с доступом к DO, но не будем о грустном) с node.js на борту. Веб-клиент (либо приложение оператора) может быть с одной кнопкой ready и должен держать связь с бэкендом через вебсокет или HTTP-запросы. Как это будет работать?
Облако — центр телефонии
- Вы создаете облачный JS-сценарий Voximplant, который принимает входящие звонки. Каждый звонок вызывает событие Started, у которого есть свойство accessURL. Поле содержит URL для общения с JS-сессией идущего звонка.
- Помимо события Started, входящий звонок также вызывает событие CallAlerting, в котором есть информация о звонке: номер звонящего, набираемый номер и другие нужные штуки.
- Облачная JS-сессия делает запрос к вашему бэкенду с помощью httpRequestAsync. В запросе передаем информацию о звонке и accessURL. Пока идет запрос и бэкенд “пережевывает” его, можно проиграть музыку для клиента, задать вопрос с помощью синтеза речи, включить mp3 с оповещением/рекламой и всячески не давать звонящему скучать.
- Бэкенд получает запрос и ищет свободного оператора, т.е. тех, кто в своем клиенте нажал на кнопку ready и сейчас ни с кем не разговаривает. Когда оператор нашелся (возможно, через пять минут), бэкенд делает запрос на accessURL, а в запрос помещает контакты оператора: user id (если оператор подключен по WebSDK или Mobile SDK), SIP URI или номер сотового телефона.
- Облачная JS-сессия получает событие HttpRequest с именем/номером оператора, звонит оператору и соединяет его с клиентом.
- Всю информация о взаимодействии с оператором сценарий шлет на бэкенд: удалось/не удалось дозвониться до оператора, кто повесил трубку после разговора – оператор или клиент, все что может пригодиться для анализа работы колл центра и определения доступности операторов. Бэкенд получает эти данные и на их основе постоянно “помечает” операторов: насколько быстро отвечают, кто не отвечает, кого и на сколько банить за неактивность. Эти пометки постоянно обновляются, поэтому бэкенд всегда знает, что происходит с операторами.
Сделать все с нуля можно за пару-тройку часов, при этом у вас будет полный контроль над очередями звонков, с нужной логикой и вашим требованиями. Разумеется, это каркас решения, про нюансы мы уже говорили, что они у каждого бизнеса свои. Взяв за основу такой подход, можно реализовать интересные решения. Например:
«Свой менеджер»
Хорошая фишка сложного колл-центра – это когда клиента переключают на “своего” менеджера, который с самого начала ведет клиента. Это удобно, потому что клиенту не надо каждый раз с нуля объяснять какие-то тонкости и прочее, личный менеджер наверняка уже все знает, плюс этот менеджер в курсе, как работать с клиентом максимально эффективно.
Так как событие CallAlerting содержит информацию кто звонит в колл-центр, то бэкенд может проверить, есть ли у входящего номера назначенный менеджер и если да, то связывать с ним. В случае отпуска/болезни/увольнения менеджера, можно синтезировать короткое объяснение и соединить звонок с другим менеджером/оператором. Если входящий номер пока не соответствует ни одному менеджеру, то после разговора с оператором можно задать клиенту вопрос “Хотите ли вы, чтобы на звонки всегда отвечал этот менеджер?”, затем распознать ответ (“да”/”нет”) и передать значение на бэкенд, который “запомнит” выбор клиента.
“Свой менеджер” хорошо работает на лояльность пользователей, а если процесс прикрепления еще и автоматизирован, то это исключает ошибку ручного назначения не того специалиста.
Нужно больше операторов
Бывает, что в пиковые часы нагрузки операторы не справляются с потоком входящих: клиенты в таком случае либо не дозваниваются, либо долго ждут ответа. Оба варианта – так себе. Проблему можно решить организационно: нанять больше операторов и надеяться, что затраты на новых сотрудников окупятся лояльностью клиентов. Но можно зайти и с другой стороны: во время нагрузки на колл-центр направлять звонки так же в техподдержку и другим специалистам. Получается ситуационное “расширение” колл-центра.
Для этого на бэкенд кладутся телефоны “запасных” сотрудников и выставляется пороговое время ответа, например, 1 минута. Если бэкенд в течение 1 минуты не нашел ни одного свободного оператора, то звонок идет на один из запасных номеров. Сколько запасных номеров можно одновременно использовать, в какие часы на них нельзя переводить звонки, ограничивать ли количество звонков на запасной номер и прочий тюнинг опять-таки можно задать на бэкенде; наше облако в любом случае сделает свою работу под руководством вашего JavaScript кода.
Еще парочку?
Колл-центры становятся сложными, потому что они меняются со временем: рынок предъявляет всё новые требования к общению, меняется законодательство, идет конкурентная борьба и постоянно случается всякое разное-интересное. Разныех колл-центров на рынке много, и это хорошо! Гибкость технологий облегчает жизнь бизнесам и радует клиентов. Если у вас есть вопросы и комментарий по гипотетическим/реальным примерам колл-центров, смело пишите в комменты – обсудим. Оставайтесь на связи и не бойтесь витать в облаках ;)
Автор: nvpushkarskiy2
