CRM устроена так, что менеджер большую часть времени не продаёт, а вводит данные: заполняет карточку, пишет комментарий к звонку, ставит задачу, меняет статус. Это и есть та рутина, которую имеет смысл снимать.
Оговорка, которая определяет весь разбор: речь идёт о фиксированных операциях внутри CRM, а не о системе, которая сама решает, что делать со сделкой. Если система выбирает действия самостоятельно — это ИИ-агент, с правами, подтверждениями и другими требованиями к тестированию: «Подключение ИИ-агента к CRM».
Здесь всё проще: событие → фиксированная цепочка шагов → результат. Это обычная автоматизация процессов, и стоит она заметно меньше агентского проекта.
Что снимается хорошо
Заполнение карточки из переписки. Пришло письмо или сообщение — контакты, компания, суть запроса, продукт извлекаются и подставляются в поля. Менеджер проверяет, а не набирает.
Сводка звонка. Расшифровка разговора превращается в короткий итог: о чём говорили, что решили, что обещали. Одна из самых благодарных задач: комментарии к звонкам менеджеры пишут неохотно и коротко, а нужны они всем.
Определение следующего шага. Из содержания переписки — что нужно сделать дальше и когда. Задача создаётся автоматически, ответственный подтверждает.
Поиск дублей. «ООО Ромашка», «Ромашка ООО» и «ромашка» — один контрагент. Точное сравнение это не ловит, модель ловит хорошо.
Обогащение карточки. Определить отрасль и размер компании по названию и сайту, проставить сегмент.
Квалификация обращения. Целевое или нет, какому направлению соответствует, какой приоритет.
Контроль качества работы. Выявление сделок, где давно нет активности, где обещание клиенту не выполнено, где переписка ушла в тупик.
Подготовка черновиков писем по шаблону и контексту сделки. Отправляет человек.
Что нельзя автоматизировать
Смену статуса сделки на основании интерпретации. «Клиент вроде согласился» — не основание переводить в «оплачено». Статусы меняются по фактам из учётной системы или человеком.
Отправку клиенту без проверки. Необратимо.
Изменение суммы и условий. Только человек.
Удаление и слияние карточек без подтверждения. Дубль может оказаться не дублем, а слияние обычно необратимо.
Оценку вероятности сделки как основание для решений. Модель может предположить, руководитель решает.
Принцип тот же, что и везде: что нельзя нарушить, должно быть невозможно, а не запрещено — «Ограничение действий ИИ-агента». Права выдаются отдельной учётной записи по минимуму.
Разбор: сводки звонков и то, что из этого вышло
Задача. Отдел продаж, 12 менеджеров, около 900 звонков в месяц. Комментарии к звонкам либо не заполнялись, либо содержали «созвонились, думает».
Что сделали. Звонки записывались и раньше — их никто не слушал. Добавили распознавание речи и разбор расшифровки: модель возвращала структуру — о чём говорили, какие возражения прозвучали, что обещано менеджером, что нужно сделать дальше и в какой срок.
Результат подставлялся в карточку сделки. Менеджер проверял и правил, если нужно.
Что получилось хорошо. Комментарии стали заполняться всегда и содержательно. Руководитель впервые получил возможность видеть, что происходит в сделках, не слушая записи.
Обещания клиентам стали фиксироваться. Отдельное правило проверяло: если в разговоре прозвучало обещание со сроком, а задачи нет — напомнить менеджеру.
Что пошло не так.
Первое: качество расшифровки на плохой связи. Часть звонков с мобильных распознавалась с ошибками, и сводка получалась искажённой. Ввели порог: при низком качестве расшифровки сводка не формируется, ставится пометка «разобрать вручную». Лучше пусто, чем неверно.
Второе, серьёзнее: менеджеры начали воспринимать сводки как контроль. Формально так и было. Часть стала подстраивать разговор под то, что попадёт в сводку. Это организационная проблема, и техникой она не решается — потребовался разговор о том, зачем это и как будет использоваться.
Третье: попытались автоматически определять вероятность закрытия сделки. Отказались через месяц. Модель уверенно оценивала на основании тона разговора, оценки расходились с реальностью, а решения по ним принимались. Убрали.
Что оставили. Сводку, извлечение обещаний, создание задач с подтверждением. Убрали всё, что было похоже на оценку и прогноз.
Итог. Экономия времени менеджеров оказалась скромной — минуты на звонок. Основная ценность в другом: появились данные, которых раньше не было, и перестали теряться обещания клиентам.
Про дубли — отдельно
Задача выглядит технической, а последствия организационные.
Модель хорошо находит вероятные дубли по названию, ИНН, телефону, домену почты. Но слияние выполнять автоматически нельзя: две карточки могут оказаться разными юрлицами одной группы, филиалами или тёзками.
Рабочая схема: система находит и показывает пары с обоснованием, человек подтверждает. При большом объёме — очередь на разбор, отсортированная по уверенности.
Отдельно стоит настроить предотвращение: проверка на дубль в момент создания карточки полезнее, чем разбор накопленного.
Что нужно для начала
- Программный интерфейс CRM с нужными операциями. Проверяется до проекта: не только наличие, но и полнота и лимиты запросов.
- Отдельная учётная запись для автоматики с минимальными правами.
- Тестовый контур. Отлаживать на боевой базе клиентов нельзя.
- Понятные правила: какие поля заполняются автоматически, какие только человеком.
- Решение по записям звонков: согласие на запись, где хранится, куда уходит при распознавании.
Частые вопросы
Что в CRM можно автоматизировать с помощью ИИ?
Заполнение карточек из переписки, сводки звонков, определение следующего шага, поиск дублей, квалификацию обращений, выявление застоявшихся сделок и подготовку черновиков писем. Общий признак — на входе текст, написанный человеком, а на выходе структурированные данные для полей.
Чем это отличается от ИИ-агента в CRM?
Здесь последовательность шагов задана заранее: произошло событие — выполнилась фиксированная цепочка. Агент выбирает действия сам, и потому требует прав, подтверждений и тестирования сценариев. Для рутинных операций агент избыточен.
Может ли система сама менять статусы сделок?
На основании фактов из учётной системы — да, это обычное правило. На основании интерпретации переписки — нет: «клиент вроде согласился» не является основанием для перевода сделки. Статусы влияют на отчётность и мотивацию, и ошибка здесь дорого стоит.
Можно ли автоматически объединять дубли?
Находить — да, объединять — нет. Похожие карточки могут оказаться разными юрлицами одной группы или филиалами, а слияние обычно необратимо. Правильная схема — система предлагает пары с обоснованием, человек подтверждает.
Нужно ли согласие на запись и разбор звонков?
Да, и это вопрос, который решается до проекта, а не после. Отдельно стоит определить, где хранятся записи и расшифровки и куда уходит текст при обращении к модели — в звонках почти всегда есть персональные данные.
Сколько времени это реально экономит?
На отдельной операции — минуты. Основная ценность обычно не в экономии, а в том, что появляются данные, которых раньше не было: содержательные комментарии к звонкам, зафиксированные обещания клиентам, видимые застоявшиеся сделки. Это стоит учитывать при обосновании проекта.
Что дальше
Как обрабатывать входящие обращения до попадания в CRM — «Автоматическая обработка почты» и «Классификация обращений». Как устроить подтверждение — «Человек в контуре проверки». Если система должна принимать решения сама — «Подключение ИИ-агента к CRM».
Проектирование и внедрение таких сценариев — часть работы по автоматизации процессов.