У нас было 2 телефонии от разных вендоров, одна речевая аналитика и 300 тысяч звонков в месяц. И задача: сделать сквозную аналитику по звонкам сотрудников.
Привет! Я Никита, инженер системного проектирования в компании Передовые Платежные Решения. Расскажу, как мы использовали единый идентификатор через службу каталогов Active Directory (AD), и стали точно определять, кому из сотрудников принадлежит звонок. Независимо от того, из какой телефонии он исходит.
Наш опыт может быть полезен архитекторам, инженерам и техническим лидерам команд, которым предстоит интеграция разнородных систем телефонии.
Наш контекст перед стартом
В начале 2024 года мы внедряли сервис речевой аналитики.
На тот момент в сервисе и продажах у нас были 2 независимые системы телефонии: Naumen для кол-центра (стационарные звонки), облачный Мегафон (для звонков с мобильных телефонов).
Несколько телефоний - это снижение рисков, потому что одна телефония - потенциально одна точка отказа. Более устойчива система, когда есть телефония, через которую идет основная масса звонков и запасная, через которую могут проводиться эксперименты или переход в случае аварии.
Один и тот же менеджер в разных системах телефонии мог называться по-разному: «Иванов Иван», «Иван Иванов», «Иванов И. И.». Для речевой аналитики это три разных человека.
Нам важно было собрать сквозную аналитику по конкретному сотруднику. В текущей системе работы оценка качества усложнялась, т.к. отчёты приходилось сверять вручную. А бизнес хотел быстрее оценивать объективную картину продаж и работы кол-центра. Поэтому важно было определить, кто звонил на самом деле.
Нашей задачей было дать бизнесу видеть единую картину по сотруднику - вне зависимости от того, с какого телефона и в какой системе тот совершил звонок.
В перспективе мы планировали анализировать не только звонки, но и чаты, которых у нас в несколько раз больше. Поэтому мы сразу пытались решать задачу множества источников данных.
Выбор возможных решений
Прежде чем прийти к финальному решению, мы перебрали несколько вариантов. Все они были рабочими, но каждый - со своими нюансами.
Вариант А: синхронизировать все системы.
Это было первым вариантом, который приходил в голову. Но мы быстро поняли, что написать коннекторы между разными телефониями, сервисом речевой аналитики и Active Directory - это тройная работа: потом придется это поддерживать, чинить рассинхронизацию, ловить баги.
Вариант Б: сделать систему-сшиватель.
Был вариант создать отдельный сервис, который по набору полей (ФИО + email + логин) пытался бы угадать, что «Иванов Иван» и «Иван Иванов» - это один человек.
Но при этом мы не получали бы единого источника правды. Зато добавили бы ещё одну сущность, которая может ошибаться. Получили бы риск потерять данные или «склеить» данные двух разных сотрудников.
Вариант В: создать свой уникальный идентификатор (UUID).
Правильный, но ресурсоемкий путь - сгенерировать UUID для каждого сотрудника и протащить его через все системы. Мы даже всерьёз его рассматривали, но поняли, что на это нужно время и бюджет, которых у нас не было.
Вариант, на котором мы остановились - использовать существующий табельный номер в Active Directory.
Почему табельный номер
Мы выбрали табельный номер (табельник) как уникальный идентификатор.
Плюсами табельного номера было то, что он:
уже существует (а значит, использовать его - быстрее и дешевле, чем создавать новый);
уникален в рамках компании;
содержит актуальные данные о сотрудниках, их группах и статусах;
используется в кадровых процессах.
Минусы, конечно, есть:
Возможны изменения табельного номера. Например, когда сотрудник переходит с ГПХ на трудовой договор, или меняет юрлицо внутри группы компаний. В этом случае его исторические звонки «повисают» на старом номере, и связать их с новым можно только через ручной маппинг (сопоставление).
В некоторых табельниках встречаются буквы, но не все системы (особенно старые или западные) дружат с кириллицей в полях-идентификаторах.
Персональные данные. Формально табельный номер - это часть персональных данных. Пришлось идти в службу информационной безопасности (ИБ), описывать схему и получать разрешение. Риск есть, но мы его приняли и обосновали.
При всех минусах, любое другое решение требовало в несколько раз больше ресурсов и времени. Табельник существовал здесь и сейчас, а подход «сделать идеально, но через год» нас не устраивал.
Архитектура решения и как это работает
Источник правды - это AD. Только там хранится актуальная связка «Табельный номер → ФИО → Группа (отдел)».
Наши коллеги из ИБ написали простое API. Ручка принимает табельный номер, дергает AD и отдаёт json с актуальными ФИО и группой сотрудника.
Мы настроили сервис речевой аналитики на работу с этим API. В системе есть штатный функционал «получения тегов из CRM». Мы просто подсунули ему наше внутреннее API вместо CRM.
Что происходит в момент обработки звонка:
Звонок приходит в любую из телефоний (Naumen или Мегафон).
В атрибутах звонка обязательно проставлен табельный номер сотрудника (как мы этого добились - расскажу ниже).
Сервис речевой аналитики забирает звонок, видит поле с табельным номером и идёт в наше API.
API возвращает из AD актуальные ФИО и группу.
Звонок складывается в хранилище с правильными тегами, привязанный к конкретному сотруднику.
Таким образом, даже если в телефонии у сотрудника написано «Ivanov I.», в отчётах мы видим «Иванов Иван Иванович» и его актуальный отдел.
AD для нас единый доступный источник данных. За качество данных в AD отвечает ИБ. Обновление происходит автоматически, исключением была разовая проблема с разным регистром букв.
Сценарии ошибок тоже предусмотрены. Например, может случится так, что звонок пришел, а табельный номер в телефонии не проставлен (забыли, новый сотрудник, сбой). Звонок в любом случае попадёт в речевую аналитику, и мы его не потеряем.
Для отслеживания таких сбоев у нас формируются ежедневные отчеты. По ним мы можем понять, что N звонков создались без табельных номеров, или с неправильной группой, или ещё с какой-то проблемой. У нас есть механизмы обновления, чтобы отчеты были точными.
Дьявол в деталях: как прокинуть табельный номер в каждую систему
Самое сложное началось, когда мы пошли внедрять это решение. Пути для разных телефоний оказались разными.
Телефонией Мегафона на тот момент под одним аккаунтом пользовалось 200+ сотрудников. Для начала мы выделили всем личные логины и пароли, настроили группы и права доступа (супервайзеры с полным доступом, рядовые сотрудники в режиме «только для чтения»).
Дальше встал вопрос: куда записывать табельный номер? Отдельного поля «Табельный номер» в Мегафоне не было. Мы нашли единственное текстовое поле - «Должность» (Position), и договорились писать табельный номер туда.
После этого попросили вендора сервиса речевой аналитики доработать их стандартный загрузчик для Мегафона. Вендор добавил 2 важные вещи: фильтрацию по группам (чтобы не тянуть звонки от всех подряд) и маппинг полей (возможность вставить в поле «ID сотрудника» значение из поля «Должность» внутри речевой аналитики).
С Naumen было сложнее - у нас стоит старая, сильно кастомизированная (адаптированная под наши потребности) версия. При этом через нее проходят 75% всех наших звонков. Прямую интеграцию или доработку со стороны вендора пришлось бы ждать долго, а стоила бы она дорого.
Поэтому мы позвали на помощь команду RPA (роботизированной автоматизации процесса), и ребята написали скрипт. Робот каждые 15 минут заходит в Naumen, забирает новые звонки, сопоставляет нужные поля (в том числе и тот самый табельный номер, который мы туда прописали) и передаёт их в сервис речевой аналитики через API.
Последней мы подключали третью телефонию - Voximplant. И снова в интерфейсе не было поля для табельного номера. Технически было поле «дополнительная информация», куда можно что-то записать. Но прочитать эти данные можно только через API, и в браузере супервайзер их не увидит. Коллеги из ИБ реализовали сервис vox_account: он заполняет информацию о табельном номере при входе сотрудника в виджет VoxImplant в CRM.
Процессы, которые внедрили по ходу
Техническая реализация - это только полдела. Важно было сделать так, чтобы система не сломалась при появлении нового сотрудника.
Теперь, когда новый сотрудник приходит в компанию, администраторы Naumen и Мегафон вносят его табельный номер при создании учетной записи в телефонии.
А еще, если у сотрудника меняется табельный номер (смена юрлица или формы договора), отдел кадров пишет нам письмо, и мы пока вручную меняем номер в телефонии. Кейсы не массовые, поэтому не создают значительной операционной нагрузки. Особенно в сравнении с количеством проблем до внедрения этого решения.
Итог и результаты
Наше решение внедрено и работает уже год.
Теперь мы имеем сквозную аналитику - видим все звонки конкретного сотрудника, независимо от того, в какой телефонии и с какого аппарата он звонил. Данные обновляются практически в режиме реального времени. Если сотрудник сменил группу (отдел) в AD сегодня - завтра все его новые звонки в речевой аналитике уже будут тегироваться (помечаться) новой группой. Нам не нужно ничего подгружать или перенастраивать.
Это позволяет нам загружать в аналитику только нужные группы, отсеивая служебные и технические звонки.
Теперь мы получаем нужную нам звонковую аналитику, и ее возможности расширились. Ранее из двух телефоний мы собирали только звонковый КПЭ (ключевые показатели эффективности). Речевая аналитика предыдущего вендора имела минимальный функционал и сводилась к выгрузке данных в Excel и построению сводных таблиц.
Трудозатраты на создание отчетов сократились в 2 раза. А использование отчетов стало удобнее. Руководители могут в режиме реального времени следить за метриками своих команд, настраивая фильтры и условия отчета за любой период.
В логику нашего решения мы можем интегрировать новую телефонию или анализ чатов с клиентами. При этом интеграция новых систем займет у нас уже в 2 раза меньше времени, потому что формат данных понятен, а инструментарий уже работает.
Было бы неправильно умолчать о теневых сторонах.
Смена табельника - дополнительные трудозатраты. При переходе сотрудника в другое юрлицо мы не теряем связку его старых звонков с новым профилем. Но меняется его группа, и поэтому приходится вручную менять данные в телефониях и речевой аналитике. Мы пока не пришли к решению, как это автоматизировать. Это не критично для операционной деятельности, но для анализа вдолгую - неприятно.
Кириллица в идентификаторе. У нас есть табельные номера с буквами. Пока все системы переваривают, но мы начеку.
Поля-заменители. В Мегафоне мы пишем табельник в поле «Должность». Это костыль, который может отвалиться при обновлении системы или изменении логики с нашей стороны.
Надеюсь, наш опыт сможет помочь вам сэкономить вам время и нервы в подобных проектах. Удачи в интеграциях!