ИИ поверх CRM: от расшифровки звонка до контроля процесса

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

Поэтому полезный ИИ в CRM — не отдельное окно, в котором можно задать любой вопрос. Это слой анализа над рабочими данными компании. Он должен понимать, к какому обращению относится звонок, видеть последующие события и уметь показать, на каких фактах основан ответ. Если система говорит, что клиенту не перезвонили, руководитель должен увидеть не только формулировку модели, но и карточку обращения, время входящего звонка, ответственного и историю контактов.

Такой подход подробнее раскрывает смысл ИИ для бизнеса (/ii-dlya-biznesa/): модель не заменяет CRM и не создаёт параллельную версию происходящего. Она помогает разбирать накопившиеся факты, находить связи между ними и обращать внимание человека на места, которые стоит проверить.

CRM хранит события, но не всегда отвечает на управленческий вопрос

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

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

Здесь ИИ полезен не потому, что умеет красиво пересказывать разговор. Он может соединить разные виды данных в одну проверяемую историю. Но для этого сначала нужна сама история: связанные сущности, корректное время событий, понятные статусы и ответственные. CRM или ERP, построенная вокруг процессов компании (/crm-erp/), даёт для такого анализа более надёжную основу, чем набор несвязанных таблиц и интеграций.

Из каких данных складывается ответ

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

Источник Что он подтверждает Чего он не доказывает сам по себе
——————— ————————————————————— ————————————————
Телефония Факт звонка, направление, время, длительность, запись Что вопрос клиента решён
Расшифровка Содержание разговора с учётом качества распознавания Что обещанное действие действительно выполнено
CRM Клиента, обращение, ответственного, этап и историю изменений Что все поля заполнены верно и вовремя
Задачи и календарь Назначенное действие, срок и отметку о выполнении Что выполнение дало нужный результат
Документы и оплаты Создание, отправку, согласование и статус операции Что клиент правильно понял условия

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

Как звонок превращается в часть процесса

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

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

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

Контроль процесса — не рейтинг людей

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

Полезнее формулировать конкретные проверяемые вопросы:

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

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

Факт, правило и вывод модели нельзя смешивать

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

Уровень Пример Как проверяется
————— —————————————————————————— —————————————————————
Факт После входящего звонка в истории нет исходящего контакта По журналу телефонии и сообщений
Правило Обращение без ответа до установленного компанией срока требует внимания По утверждённой логике процесса
Вывод модели В разговоре сотрудник, вероятно, обещал перезвонить после уточнения наличия По фрагменту расшифровки и ручной проверке при необходимости

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

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

Три уровня полномочий ИИ

Способность прочитать данные и право изменить их — разные полномочия. Их нужно выдавать раздельно.

Аналитик: читает и показывает

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

Помощник: готовит, человек подтверждает

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

Агент: действует в заданных границах

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

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

Ответ должен вести к источнику

Фраза «обнаружено несколько проблемных разговоров» бесполезна, если нельзя открыть каждый из них. В результате анализа нужны ссылки или идентификаторы исходных объектов: звонок, обращение, задача, документ. Рядом стоит показывать время, участника, используемое правило и короткий фрагмент, повлиявший на вывод.

Для спорных выводов полезно обозначать неопределённость. Причиной может быть шумная запись, неправильное разделение реплик или неоднозначная формулировка. Система должна уметь сказать «недостаточно данных», а не заполнять пробел правдоподобным предположением.

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

Доступ к данным проверяется до обращения к модели

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

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

Это одна из причин, почему корпоративный помощник лучше встраивать в существующий контур, а не подключать напрямую к общей выгрузке. Система знает текущего пользователя, его роль и доступные компании. ИИ получает не «всю CRM», а минимальный контекст для разрешённого вопроса.

Российские персональные данные и записи разговоров: что проверить заранее

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

Универсальной формулы для всех разговоров и отраслей нет. До запуска стоит вместе с профильным специалистом по персональным данным и трудовому праву проверить:

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

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

Как провести пилот и не потеряться в возможностях

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

1. Описать событие начала, ожидаемое действие, срок и исключения.
2. Определить источники: телефония, карточка обращения, задачи и сообщения.
3. Составить небольшой список вопросов, на которые должен отвечать анализ.
4. Разделить вопросы на факты, правила и выводы модели.
5. Собрать набор реальных примеров с ручной разметкой, включая неоднозначные и ошибочные записи.
6. Запустить режим только для чтения и сравнить ответы с проверенной картиной.
7. Зафиксировать ошибки: неверная связь клиента, плохая расшифровка, пропущенное событие, неправильная интерпретация.
8. После стабилизации добавить сводку и только затем — безопасные действия с подтверждением.

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

Когда ИИ уже уместен, а когда лучше начать с порядка в CRM

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

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

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

Документация по теме

— NIST AI Risk Management Framework Core: Govern, Map, Measure, Manage (https://airc.nist.gov/airmf-resources/airmf/5-sec-core/)
— OWASP Top 10 for Large Language Model Applications (https://owasp.org/www-project-top-10-for-large-language-model-applications/)
— OWASP RAG Security Cheat Sheet (https://cheatsheetseries.owasp.org/cheatsheets/RAG_Security_Cheat_Sheet.html)
— Yandex Cloud: работа с AI-ассистентом в SpeechSense (https://yandex.cloud/ru/docs/tutorials/ml-ai/speechsense/ai-assistant)
— Федеральный закон № 152-ФЗ «О персональных данных» (https://www.kremlin.ru/acts/bank/24154/print)
— Федеральный закон № 23-ФЗ об изменениях в правилах обработки персональных данных (https://www.kremlin.ru/acts/bank/51683/print)
— Гострудинспекция Татарстана: оформление видеонаблюдения и записи телефонных разговоров (https://git16.rostrud.gov.ru/news/1150709.html)