Колл-центр

Из этого поста вы узнаете, зачем добавлять в интеграционный слой бизнес-логику, что случается, когда не летит Service mesh, и почему иногда костыли лучшее решение проблемы.

Привет Хабр, на связи Иван Большаков архитектор интеграционных решений, эксперт департамента разработки ПО КРОК. Я расскажу, как мы делали интеграционный слой для CRM-системы группы контакт-центров торговой сети Пятерочка.

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

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

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

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

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

Возможные решения

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

Логичный выход, который решит проблему заказчика, но не дает дополнительных преимуществ.

Другой вариант enterprise service bus. Это классический сценарий интеграции: разработать пользовательский интерфейс, подключить его к опубликованным на интеграционной шине методам и наслаждаться жизнью.

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

Мы решили использовать для интеграционного слоя микросервисы. Они позволяют реализовать дополнительную бизнес-логику и обеспечивают масштабируемость. Их проще распределить по нескольким ЦОД, по сравнению с ESB.

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

Архитектура интеграционного слоя

Опыт разработки микросервисов подсказывал нам, что не стоит требовать радикальной доработки информационных систем на стороне заказчика.

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

Мы использовали стандартный прием спроектировали интерфейсы, написали адаптеры для каждой системы и связали их с нашим ядром через законтрактованный API.

Так как в интеграционный слой попала бизнес-логика, выбор пал на событийно-ориентированную архитектуру. В ней проще следить за согласованностью данных.

Проектируя архитектуру интеграционного слоя, мы старались не переусложнять, ведь микросервисность не самоцель проекта.

Мы не разделяли по сервисам компоненты, которые будут дорабатываться или масштабироваться вместе. Если можно было разрабатывать в составе одного сервиса несколько бизнес-сущностей, мы это делали. И все равно, в итоге получилось больше 30 микросервисов.

Вся сложность во взаимодействиях

С внешними системами было просто. Мы не могли ничего менять, так что использовали те API, которые они предоставляли.

Внутри системы мы выделили два типа взаимодействий: модифицирующие и читающие. Модифицирующие воздействия реализовали при помощи обмена сообщениями через топики в Kafka. Каждому сервису присвоили топик, который начинается с его имени. Сервис отправляет туда сообщения обо всех событиях, произошедших с его объектами:

с бизнес-сущностью, которую обрабатывает сервис user, что-то произошло, вот ее новые данные

Этот топик читают другие сервисы. Они реагируют на изменения и отписываются в свои топики. Так действие пользователя по каскаду распространяется по всей системе.

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

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

Читающие взаимодействия идут по gRPC. Мы выбрали этот протокол не из-за фич типа стриминга (их пока не используем), а потому, что с его помощью удобно управлять контрактами.

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

Kafka и очереди сообщений

Мы использовали Kafka в качестве брокера сообщений, потому что купились на отказоустойчивость. Между ЦОДами, где расположены системы заказчика, небольшие задержки, так что она работает неплохо. Однако, где-то в середине проекта мы поняли, что просчитались.

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

Для последовательного чтения пришлось прикрутить некрасивый костыль, который проверяет отставание офсета в первом топике и разрешает чтение из другого. Если бы мы использовали RabbitMQ, было бы проще, но, возможно, возникли бы вопросы относительно производительности.

Взаимодействие с фронтом

Здесь обошлось без rocket science. Взаимодействие с фронтом мы выстроили при помощи WebSocket и REST. WebSocket нужен для передачи событий от бека к фронту и высоконагруженных управляющих взаимодействий, а REST для запроса данных. Правда, пришлось написать отдельный микросервис для фронтенд-разработчиков.

Ходить за несколькими сущностями в три разных сервиса, а потом собирать на фронте какую-то адекватную модель для представления не очень удобно. Куда удобнее использовать composer, который будет брать сразу несколько сущностей со связями между ними и компоновать в один JSON. Для этого отлично подошел Apache Camel. Правда, в следующий раз мы не станем заморачиваться с REST и используем graphQL.

Service mesh и безопасность

Service mesh нужен, чтобы не прописывать вручную всю логику межсервисных взаимодействий. Как правило, для соединения микросервисов мы используем Istio и в этом проекте тоже рассчитывали на эту платформу. Но в этом году все идет как-то не так, как ожидалось.

Мы столкнулись с такой версией OKD, на которую никак не получалось установить Istio. Заказчик собирался в будущем обновить систему оркестрации, но нам нужно было решение здесь и сейчас.

Дедлайн приближался, а инженеры не знали, когда мы справимся с проблемой. Пришлось минимизировать риски и сделать какое-то подобие service mesh, чтобы точно запуститься вовремя.

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

Было необходимо идентифицировать запросы от фронта к бекенду, проверять токены пользователей в каждом микросервисе и делать запросы GET, POST и так далее, в зависимости от роли в токене.

Итак, мы начали пилить собственный service mesh. В его основу легла простая идея: если нельзя (не хочется) поместить логику в код сервиса, сделаем внешний sidecar-контейнер по аналогии с Istio, использовав OpenResty и язык Lua.

Написали в контейнере код, который проверяет подпись токена. В качестве параметров к нему подкладываются правила, описывающие, какие запросы пропускать от пользователей с различным ролями.

Аудит

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

Существуют штатные библиотеки для работы с Kafka, но и с ними возникли проблемы. Все ломалось, как только для подключения к Kafka требовался SSL. Спас положение старый добрый kafka-console-producer, который лежит в каждом sidecar и вызывается с параметрами из nginx.

Получился рабочий почти-service mesh. Казалось бы, можно было расслабиться, но мы чуть не упустили еще одну важную вещь.

Балансировка gRPC

gRPC то работает на HTTP/2, а этот протокол устанавливает соединение и держит, пока оно не порвется. Возможна ситуация, когда инстанс сервиса A намертво прицепится к одному из инстансов сервиса B и будет направлять все запросы только на него. Тогда от масштабирования сервиса B не будет толка. Второй инстанс сервиса B останется не нагружен и будет впустую тратить процессорное время и память.

Мы могли сделать полноценную балансировку на клиентской стороне, но было бы неправильно тратить на это время. После внедрения полноценного service mesh эти наработки потеряют актуальность.

Поэтому мы реализовали перехват и подсчет всех вызовов gRPC на уровне кода на стороне клиента. Когда счетчики подходят к определенному значению, вызывается метод, приводящий к переустановке соединения, и балансировщик OKD задействует незагруженный инстанс сервиса B.

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

Управление версиями

Напоследок, несколько слов о том, как мы управляли версиями кода.

В проекте задействованы Spring, Maven и Java. Каждый микросервис хранится в собственном микрорепозитории. В первую очередь потому что мы передавали систему заказчику по частям, сервис за сервисом.

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

Прежде всего, мы стали собирать сервисы в образы, которые тегируются коротким хешем коммита. А внутри Maven проекта нет версионирования кода, там вместо версии мы использовали заглушку.

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

Еще один момент, который стоит упомянуть, управление версиями интеграционных контрактов между сервисами.

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

Что мы вынесли из проекта

В этом проекте мы вновь убедились в том, как важно заранее обследовать инфраструктуру. Но даже после тщательной проверки нельзя расслабляться. Некоторые проблемы, типа несовместимости конкретной версии OKD с Istio, практически невозможно предвидеть.

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

Если подвести итог, то интеграция без ESB имеет право на жизнь, особенно, когда нужно решить задачу в сжатые сроки.

Если у вас появились вопросы, или вы знаете, как красиво сделать приоритизацию сообщений в Kafka, пишите в комментариях или на почту IBolshakov@croc.ru.

Новая версия 3CX v18 Alpha выходит одновременно с дорожной картой развития этой коммуникационной платформы.



Стратегия 3CX создание и развитие коммуникационной системы для бизнеса будущего. 3CX эволюционирует в многофункциональную систему связи. Сейчас телефонный звонок уже не является приоритетным способом коммуникации с бизнесом. Клиенты задают вопросы в виджете чата на сайте, на странице компании в Facebook и через SMS. Использовать традиционные разрозненные способы связи неудобно ни клиентам, ни сотрудникам компании.

Оставаться на связи сразу по нескольким каналам довольно неудобно. А объединенная отчетность по коммуникациям с клиентом практически невозможна. Кроме того, компания должна приобретать различное ПО или оборудование для каждого канала коммуникаций.

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

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

Расскажем о новинках в 3CX v18 Alpha.

Ядро 3CX v18

Разработчики 3CX значительно улучшили ядро системы: теперь платформа оптимизирована для новой ОС, которая войдет в ISO образ 3CX. Для этого сделано несколько важных доработок, касающихся совместимости и надежности:

• 3CX ISO теперь основан на Debian 10 (Buster);
• системы v16 будут беспрепятственно обновлены на Debian 10;
• сервис 3CX Tunnel объединен с сервисом Media server: потребление памяти уменьшено примерно на 20%, улучшены качество связи, время и стабильность подключения (еще не протестировано в Alpha-версии и требует обновления приложений);
• улучшено согласование SDP (Renegotiation): установлена лучшая совместимость с различными операторами, исправлены нечастые ситуации, приводящие к односторонней слышимости, повышена точность отчетов, появилась возможность записи только внутренних / внешних вызовов;
• записи IPv6 DNS (AAAA);
• различные исправления в отчетах о вызовах;
• новый сервис Gateway Service, который будет отвечать за интеграцию со сторонними системами (и поддерживать REST API 3CX).

Установка и управление

SSO (Single Sign On) в веб-клиенте и интерфейсе управления 3CX.

Caller ID в формате E164 все Caller ID теперь могут быть преобразованы в единый формат E164.

Audit Log журналирование изменений в конфигурации системы (что, когда и кем).
Сервис DNS Helper устраняет необходимость отдельно указывать локальный и публичный IP-адреса. Это упрощает подключение к системе, поскольку не требует разной конфигурации веб-клиента и мобильных приложений для работы в локальной сети / удаленно. Одновременно этот сервис упрощает перенос системы в облако.

Удаленная установка IP-АТС или SBC на устройства Raspberry PI. Теперь можно отправить чистое устройство клиенту и инициализировать его удаленно. Также для настройки 3CX не нужны клавиатура и монитор.

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

В соответствии с тем, каким 3CX видит будущее бизнес-коммуникаций, компания прилагает много усилий, чтобы улучшить чат Live Chat для размещения на сайтах, а также интеграцию с мессенджерами.

Улучшенный виджет чата Live Chat: различные темы, оптимизация алгоритма сбора контактных данных клиента (имени и e-mail), различные режимы отображения на сайте, увеличение возможностей кастомизации виджета. Также реализована поддержка Google RCS (SMS 2.0).

Интегрированный портал Webmeeting

Портал видеоконференций Webmeeting будет объединен с системой 3CX:

• вся информация о конференциях теперь хранится локально и полностью конфиденциальна;
• унификация URL click2call и click2meet;
• в дальнейшем можно будет использовать публичные или собственные MCU;
• улучшен сервис голосового звонка в конференцию.

Встроенная техподдержка

3CX будет включать новый интерфейс техподдержки, который позволит быстро решать проблемы клиентов. Операторы смогут открывать запросы в техподдержку в процессе звонка или чата. Система может работать с e-mail службы поддержки партнера для эффективного отслеживания и решения запросов пользователей. Для обслуживания 3CX теперь не требуется отдельная хелпдеск-система партнер экономит на лицензиях и обучении.

Реализация пожеланий с Форума идей 3CX

Топ-10 пожеланий пользователей 3CX не остались без внимания!

Уже реализовано в 3CX Alpha:

• возможность пропуска приветствия голосовой почты;
• вызов сотрудника по имени или фамилии (ранее было только по фамилии);
• импорт фото сотрудников из Office 365;
• скрытие служебных номеров (IVR и пр.) из адресной книги 3CX.

Планируется в релизе или Update 1/2:

• планирование повторяющихся аудиоконференций по расписанию;
• отчет журнал количества одновременных вызовов в IP-АТС для планирования лицензии;
• планирование конференций из плагина для Outlook;
• индикация рабочих / нерабочих часов IP-АТС в приложении 3CX или расширении Chrome.

Обсуждаемые новые функции:

• несколько адресных книг для разных отделов компании;
• более детальное делегирование прав доступа к системе.

Подробный журнал изменений

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

Каждый контакт-центр (КЦ) ежедневно сталкивается с двумя сложными задачами, вытекающими из самой деятельности этих подразделений.

Первая это управление КЦ. При высокой текучке необходимость постоянно нанимать и обучать новых сотрудников отнимает очень много времени. И в 90% случаев причина проблемы кроется в большом количестве приложений, необходимых для работы оператора и содержащих информацию о клиенте (статус заказа, товары в корзине, счета и пр.). Как правило, каждое приложение имеет свой алгоритм работы (с инструкциями на бумажных распечатках и в методичках).

Вторая задача необходимость дать клиенту максимально полный сервис за максимально короткое время. Хотя зачастую время ожидания невелико от нескольких секунд до минуты простой расчет показывает, что суммарные потери времени в пересчете на весь КЦ могут быть ощутимыми.

Рассмотрим небольшой КЦ (до 50 операторов). На каждом клике оператор теряет доли секунды. Перемножив количество операторов, количество обращений, количество кликов, получим несколько человеко-дней, которые были потрачены на поиск информации и на ожидание ответа системы. За это время КЦ мог бы оказать услуги десяткам и сотням клиентов. Именно поэтому количество кликов должно быть минимальным, а скорость реакции максимальной.

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



Как это сделать?

Единый сервис-деск должен обеспечивать три основных параметра:

• функциональность;
• безопасность;
• юзабилити.

Функциональность

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

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

В этом случае задействованы:

• данные клиента;
• информация о статусе заказа;
• каталог.

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

Что делать?

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

Все полученные данные формируют единое рабочее место оператора. Оно может также содержать элементы скриптов, чек-лист диалога и пр.

Юзабилити и безопасность

Когда собран весь функционал и разработана архитектура интеграции систем, можно переходить к юзабилити и безопасности.

Юзабилити это критически важный фактор в работе сервис-десков КЦ. Минимум кликов должен обеспечивать максимальный результат, а интерфейс должен быть интуитивно понятен.

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

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

Далее безопасность. Вопрос безопасности возникает неизбежно, так как работа с персональными данными требует соблюдения законодательства.

Основное требование службы безопасности запретить хранение важной информации в фронтовых системах, к которым оператор имеет конечный доступ.

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

Когда оператор заканчивает работу по обращению, в системе не остается никаких лишних данных, кроме информации о самом звонке, о типе обращения, о затраченном времени. Это позволяет компании собирать аналитические данные о работе КЦ для дальнейшей оптимизации бизнес-процессов.



Перечисленные положения и требования к организации рабочих мест операторов справедливы для любых CRM-систем и сервис-деск-платформ, которые используются в КЦ. При этом со стороны организации телефонной связи может использоваться также любая платформа, отвечающая требованиям КЦ и имеющая возможности для интеграции с CRM. Например, мы компания АйПиМатика поставляем программную коммуникационную платформу 3СХ от кипрских разработчиков.

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

Что такое голосовая аналитика?

Голосовая аналитика комплексное решение анализа речи. Нейросети переводят разговоры из голоса в текст, затем текст анализируется по нескольким параметрам. В частности, инструмент умеет анализировать:

• скорость разговора,
• перебивание,
• молчание,
• искать ключевые слова,
• выставлять сводную оценку каждому разговору.

Кому пригодится?

Тем у кого больше одного сотрудника, кто разговаривает по телефону (продажи/поддержка/опросы что угодно).
Слушать все разговоры невозможно. Благодаря автоматическому скорингу, все плохие(или наоборот) разговоры вы сразу же можете прочитать или прослушать в интерфейсе личного кабинета.

Словари и ключевые слова

Инструмент речевой аналитики Zadarma прошел этап альфа-тестирования и мы можем сказать, что чаще всего клиенты используют словари и ключевые слова. В разговоре были употреблены слова из дефолтного словаря (например, использование слов-паразитов оператором), либо из созданного словаря. Руководитель узнает об этом, сможет прочитать расшифрованный текст или прослушать разговор.

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

Слова оператора
Неуверенная работа оператора не знаю, не уверен, не могу помочь
Скрипты покупка совершена, ваш заказ принят в обработку, спасибо за покупку

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

Слова оператора и клиента
Упоминание конкурентов Кола, пепси, спрайт, миринда, вятский квас
Ошибки, баги сбой, не работает, техническая ошибка, неполадки, зависло

Также система может строить отчеты по дополнительным параметрам: молчание, перебивание (в % эквиваленте), скорость речи, соотношение речи оператора и клиента.
Пример такого отчета:

Сколько стоит и как попробовать?

Сам инструмент речевой аналитики абсолютно бесплатный. Это не первый наш бесплатный инструмент (например бесплатная АТС, коллтрекинг, CRM, виджеты). Платить нужно только за минуты распознавания речи.
Инструмент умеет работать с 50+ языками, и стоимость зависит от языка.
Стоимость распознавания популярных языков, в том числе и русского 90 копеек за минуту разговора.



До 15 января 2021 года мы добавили подарочные минуты для трех тарифов:

• Стандарт 100 минут бесплатного распознавания (действует только до 15 января)
• Офис 500 минут бесплатного распознавания (после акции 100 минут)
• Корпорация 1000 минут бесплатного распознавания (после акции 200 минут)

Для того, чтобы протестировать речевую аналитику:

1. зарегистрируйтесь в сервисе
2. подключите бесплатную АТС и виртуальный номер
3. активируйте распознавание всех разговоров на одном или нескольких внутренних номерах АТС.
4. далее создайте параметры отчета разговора в разделе Распознавание речи.

P.S. Все должно совершенствоваться. Так как мы предложили голосовую аналитику лишь несколько дней назад, то активно наращиваем ее функционал. Все пожелания по развитию голосовой аналитики с радостью ждем в комментариях.