Когда в CRM каждый день приходит несколько десятков или сотен обращений, ручное распределение лидов довольно быстро превращается в отдельную должность. Нужно открыть письмо, понять, что хочет клиент, определить направление, вспомнить, кто занимается этим типом оборудования или услуги, проверить, не спам ли это, и назначить ответственного. Кажется, что задача буквально создана для автоматизации.
И здесь возникает самый опасный соблазн: сразу сделать робота, который сам будет назначать менеджеров.
Еще лучше — добавить к нему ИИ. Ведь сейчас принято считать, что достаточно подключить большую языковую модель, показать ей регламент и написать: «Определи ответственного».
На практике именно с этого часто начинаются проблемы.
Мы недавно решали такую задачу для компании, работающей в Битрикс24. Поток входящих лидов большой, ассортимент сложный, направлений много, есть сервисный отдел, оборудование разных категорий, расходные материалы, каталожные товары и значительная доля писем, которые вообще не являются запросами клиентов.
Задача выглядела просто: помочь автоматически определять, кому передать очередной лид.
Но мы сознательно не стали начинать с автоназначения. Сначала появился робот-советник. И это оказалось намного важнее, чем выбор конкретной AI-модели.
Главная ошибка — сразу отдавать роботу право принимать решение
Представим обычную ситуацию. Вы формализовали часть правил распределения, добавили несколько словарей, возможно подключили ИИ и получили точность, условно, 90%. Звучит неплохо.
Но если через CRM проходит 300 лидов в день, оставшиеся 10% — это уже 30 потенциально неправильно распределенных обращений. Один запрос уйдет в сервис вместо отдела продаж. Другой попадет менеджеру, который не работает с этим направлением. Третий пролежит без ответа, пока сотрудники будут разбираться, откуда он вообще появился.
После нескольких таких случаев возникает предсказуемая реакция отдела продаж: «Робот опять что-то неправильно сделал». Доверие к автоматизации теряется намного быстрее, чем потом восстанавливается. Поэтому безопасная схема внедрения выглядит иначе.
Этап 1. Робот ничего не решает
На первом этапе робот анализирует лид, но не меняет ответственного.
Он просто пишет комментарий:
Рекомендуем передать в отдел сервиса.
Причина: обнаружен запрос на ремонт оборудования.
Или:
Рекомендуемый ответственный: направление расходных материалов.
Причина: найдены маркеры расходника и название категории оборудования.
Человек, который раньше полностью анализировал лид вручную, остается в процессе. Но теперь вместо нескольких минут ему часто достаточно нескольких секунд: проверить подсказку и назначить ответственного. Это уже дает экономию времени, но почти не создает бизнес-рисков.
Этап 2. Сравниваем робота с человеком
Следующий шаг еще важнее. Для каждого лида система сохраняет:
- кого рекомендовал робот;
- почему он дал такую рекомендацию;
- кому в итоге назначил лид человек;
- совпали решения или нет.
Так начинает формироваться объективная статистика. Не «нам кажется, робот работает неплохо», а конкретные цифры.
Например:
- рекомендаций: 500;
- совпадений: 462;
- расхождений: 24;
- ручных кейсов: 14.
Причем сами расхождения зачастую оказываются ценнее совпадений. Именно они показывают, где регламент неполный, где словарь построен неправильно, где обнаружилась новая формулировка клиента, а где ошибся уже не робот, а человек.
Этап 3. Автопилот только для доказанных маршрутов
Когда на живом потоке появляется достаточная статистика, часть маршрутов можно переводить в автоматический режим. Например, система может сама закрывать очевидный спам или автоматически назначать лиды определенного типа конкретному отделу. А неоднозначные случаи продолжает передавать человеку.
В результате сотрудник не исчезает из процесса. Он просто перестает заниматься рутиной и концентрируется на исключениях.
Именно такую автоматизацию мы считаем нормальной: не «ИИ заменил распределителя», а система постепенно доказала, какие решения ей уже можно доверять.
Хорошая маршрутизация начинается не с ИИ, а с регламента
До автоматизации у бизнеса должен появиться понятный ответ на простой вопрос: как лиды должны распределяться вообще? Не «обычно Иван смотрит письмо и знает». А формализованный регламент.
Например:
- Сначала определяем сервисные запросы.
- Затем профильные направления.
- Затем оборудование определенных категорий или производителей.
- Затем расходные материалы.
- Все, что не удалось однозначно определить, отправляем на ручную классификацию.
К этому добавляется матрица: тип товара / категория / направление → ответственный сотрудник или отдел. Когда такой регламент появляется, довольно быстро выясняется любопытная вещь: для значительной части лидов никакой генеративный ИИ вообще не нужен.
80% задачи часто решают обычные правила
Если клиент прямо пишет название категории, типа оборудования или другой однозначный маркер, зачем отправлять его текст в LLM? Гораздо надежнее проверить словарь.
Например:
- встретили определенное название оборудования — предложили соответствующее направление;
- увидели «ремонт», «не включается», «ошибка», «диагностика» — проверили сервисный сценарий;
- нашли маркер расходного материала — посмотрели соответствующий каталог;
- обнаружили название товарной группы — использовали матрицу маршрутизации.
У такого подхода есть сразу несколько преимуществ.
- Быстро. Проверка занимает миллисекунды.
- Бесплатно. Нет внешних API и оплаты токенов.
- Предсказуемо. Один и тот же текст при одинаковой конфигурации всегда даст одинаковый результат.
- Объяснимо. В комментарии можно прямо написать, какие маркеры сработали.
Маленькая техническая деталь, которая потом экономит много времени
При автоматизации важно не привязывать маршрутизацию к названиям сотрудников и отделов. Сегодня отдел называется «Отдел 1», а через полгода его переименуют в «Отдел 2». Сегодня лиды получает один менеджер, завтра другой. Если логика построена на текстовых названиях, изменение организационной структуры может неожиданно сломать маршрутизацию.
Поэтому в конфигурации лучше использовать внутренние ID пользователей, подразделений и других сущностей CRM. Названия меняются. ID — значительно реже. Мелочь, но именно из таких мелочей потом складывается разница между временным скриптом и системой, которую можно поддерживать годами.
Где ИИ действительно оказался полезен
Отказ от идеи «давайте отправлять в GPT каждый лид» не означает, что ИИ здесь не нужен. Наоборот, некоторые задачи он решает очень хорошо. Причем часть AI-функций уже может работать внутри самой CRM. В нашем проекте использовался Битрикс24 с BitrixGPT. CRM уже формировала для входящих сообщений текстовые аннотации.
Например:
- «рекламная рассылка»;
- «первичный запрос без уточнения характеристик»;
- «текст не содержит информации о заказе»;
- описание содержания письма.
Получается интересная архитектура. ИИ уже один раз проанализировал сообщение внутри CRM. Зачем повторно отправлять тот же текст во внешнюю модель, если результат этого анализа можно использовать как один из входных сигналов? Мы начали читать AI-аннотации программно и накладывать на них обычные правила. Так появился довольно эффективный спам-фильтр.
Половина лидов оказалась вообще не лидами
Для данного проекта это была важная проблема. Во входящий поток постоянно попадали:
- рекламные рассылки;
- приглашения на выставки;
- предложения поставщиков;
- автоматические уведомления;
- различные информационные письма.
Человеку приходилось открывать их просто для того, чтобы понять: продавать здесь нечего. Мы начали использовать сочетание аннотаций BitrixGPT и собственных словарей. На тестовой выборке примерно из 200 обращений система дала 57 рекомендаций отправить сообщение в спам. Все 57 оказались корректными. Ни одного рабочего обращения фильтр на этой выборке ошибочно не отправил в мусор.
Это хороший пример маршрута, который потенциально можно автоматизировать одним из первых. Почему? Потому что здесь одновременно выполняются два условия:
- высокая измеренная точность;
- максимальная бессмысленность ручной работы.
Но «пустой лид» и спам — не одно и то же
Очень быстро обнаружился другой интересный случай.
ИИ может написать:
Содержательный текст отсутствует.
Первое желание — тоже отправить лид в мусор. Но это опасно. В одном из реальных обращений в теме было буквально одно слово, а текст письма оказался пустым. По содержанию — почти идеальный кандидат на удаление. Но проверка дублей по email показала, что письмо пришло от постоянного клиента. И это был реальный заказ.
Поэтому в нашей логике появилась отдельная категория.
Не:
Спам.
А:
Недостаточно данных. Проверьте вложения и историю клиента.
Это важный принцип всей системы. Когда информации недостаточно, робот не должен изображать уверенность. Хорошая автоматизация умеет сказать: «Я не знаю, нужен ручной разбор». Иногда это намного полезнее еще одного «умного» предположения.
Где начинается зона внешней LLM
Есть обращения, которые не удается нормально классифицировать ни по маркерам, ни по готовой AI-аннотации.
Например:
- клиент описывает задачу свободным текстом;
- в одном письме смешано несколько запросов;
- продукт напрямую не назван;
- нужное направление можно определить только по смыслу.
Таких лидов обычно намного меньше общего потока. Вот здесь уже имеет смысл подключать внешнюю LLM.
В промпт можно передать:
- текст обращения;
- действующий регламент;
- матрицу направлений;
- ограничения;
- результаты предыдущих проверок.
А от модели потребовать строго структурированный ответ:
- рекомендуемый маршрут;
- уровень уверенности;
- краткое обоснование.
Если уверенность низкая — автоматического назначения не происходит. Получаем обычный fallback: словари → встроенные AI-сигналы → внешняя LLM → человек. Так ИИ используется именно там, где его способность понимать свободный язык действительно дает дополнительную ценность. А не там, где достаточно обычного if.
Большая часть «ошибок ИИ» вообще не имеет отношения к ИИ
В процессе тестирования мы получили несколько показательных кейсов. И почти каждый исправлялся за 5-15 минут изменением конфигурации.
Кейс 1. Кодировка съела бренд
В одном обращении название содержало амперсанд. После сохранения текста в CRM он оказался представлен в HTML-кодировке: & Словарь ожидал другую строку и не нашел маркер. Можно долго обсуждать качество классификатора. А можно просто перед анализом декодировать HTML entities. Дополнительно мы добавили устойчивый алиас по уникальной части названия. В результате исправили не один конкретный лид, а целый класс потенциальных будущих ошибок.
Кейс 2. «Два ключевых слова рядом»
Система увидела слово «ключевое слово1» и предложила специалиста по данному оборудованию. Формально маркер найден. Но клиент хотел купить продукцию другой категории (ключевое слово 2). Появилось дополнительное правило: анализировать не только наличие слова, но и контекст. Такие простые лингвистические правила часто дают больше пользы, чем попытка заменить весь классификатор большой языковой моделью.
Кейс 3. Новая формулировка выставочной рассылки
Очередное письмо приглашало:
встретиться на стенде.
Существующий фильтр его пропустил. При этом AI-аннотация содержала формулировки вроде «место проведения» и «период проведения». В словаре был другой вариант — «дата проведения». Добавили новые маркеры, прогнали измененное правило по исторической выборке и убедились, что ложных срабатываний не появилось. Готово. Никакого переобучения модели.
Настоящее сердце системы — не классификатор, а мэтчинг
Самая полезная часть такой автоматизации находится не там, где робот пытается угадать ответственного. Она начинается после его решения. Каждая рекомендация попадает в лог. Когда сотрудник вручную распределяет лид, система проверяет результат.
Получается один из вариантов:
- совпало;
- разошлось;
- спам подтвержден;
- потребовался ручной разбор.
Причем совпадение не обязательно означает одного конкретного сотрудника.
Например, робот рекомендует:
отдел сервиса.
А распределитель выбирает любого сотрудника внутри этого отдела. Для бизнеса решение правильное. Поэтому мэтчинг лучше строить не только по пользователям, но и по организационной структуре.
Почему расхождения особенно полезны
Каждое расхождение — это готовый вопрос владельцу процесса: кто здесь был прав? Если робот ошибся — корректируем правило. Если человек распределил лид вопреки действующему регламенту — проблема уже не в автоматизации. Таким образом система начинает выполнять еще одну неожиданную функцию. Она проверяет не только робота. Она помогает контролировать соблюдение самого регламента.
Документ с правилами перестает лежать где-то в корпоративной папке. Он превращается в исполняемую и измеримую бизнес-логику.
Точность должна считаться по категориям
Среднее значение вроде «95% правильных рекомендаций» выглядит красиво, но само по себе мало о чем говорит.
Намного полезнее считать отдельно:
- спам;
- сервис;
- конкретные продуктовые направления;
- расходные материалы;
- неопределенные запросы.
Тогда становится видно, что, например:
- спам определяется почти безошибочно;
- сервис тоже работает стабильно;
- одна продуктовая категория пока дает слишком много расхождений;
- смешанные запросы чаще требуют ручного решения.
И переводить на автопилот можно не всю систему одновременно. Сначала автоматизируем категорию с максимальной точностью. Потом следующую. И так постепенно увеличиваем долю лидов, для которых участие распределителя больше не требуется.
Черный ящик в CRM долго не живет
Есть еще одна проблема, которую легко недооценить. Допустим, вы сделали прекрасный алгоритм. Он запускается по расписанию и что-то делает. А потом однажды перестает. Почему? Неизвестно.
Когда последний раз запускался? Неизвестно. Какие лиды обработал? Неизвестно. На каком этапе произошла ошибка? Тоже неизвестно.
Такие системы обычно заканчивают одинаково: сотрудники перестают им доверять и возвращаются к ручной работе. Поэтому вместе с роботом мы сделали отдельную защищенную веб-страницу мониторинга.
На ней можно посмотреть:
- последние прогоны;
- обработанные лиды;
- рекомендации;
- фактические назначения;
- результаты мэтчинга;
- ошибки;
- фильтр по датам;
- технические логи.
Это не самый эффектный элемент проекта. На презентации значительно интереснее показать «ИИ, который понимает запрос клиента». Но в реальной эксплуатации страница состояния часто оказывается важнее.
Ошибка одного лида не должна останавливать остальных
Каждый этап обработки мы стараемся изолировать. Например, если система не смогла оставить комментарий в конкретном лиде, это не должно останавливать обработку еще пятидесяти следующих. Такой лид просто не помечается завершенным, и робот сможет вернуться к нему в следующем цикле.
Но есть и другой класс ошибок. Если CRM API целиком недоступен, продолжать прогон бессмысленно. В этом случае выполнение прекращается, а причина фиксируется в журнале.
Из таких деталей складывается нормальная production-система:
- защита от параллельного запуска нескольких копий робота;
- идемпотентность — один лид не получает одну и ту же рекомендацию несколько раз;
- повторная обработка после временных сбоев;
- ротация логов;
- хранение секретов вне доступной из веба директории;
- понятная диагностика каждого этапа.
Это не ИИ. Но именно это определяет, будет автоматизация реально работать через полгода после запуска или останется красивым демо.
Сколько времени занимает первая версия
Если регламент уже существует хотя бы в каком-то виде, первая полезная версия такого робота — это скорее дни, чем месяцы.
В нее можно включить:
- получение новых лидов;
- нормализацию входящего текста;
- базовые словари;
- приоритеты маршрутизации;
- анализ AI-аннотаций CRM;
- рекомендации в комментариях;
- логирование;
- мэтчинг решений;
- страницу мониторинга.
После этого начинается самая важная часть — работа на реальном потоке. Появился новый кейс. Посмотрели. Изменили конфигурацию. Прогнали историческую выборку. Проверили, не сломали ли предыдущие сценарии. Развернули изменение. Следующий кейс.
Поэтому для подобных систем скорость итераций намного важнее идеи «сразу сделать идеальный искусственный интеллект». Идеальной классификации входящих запросов с первого дня не будет. А вот систему, которая быстро учится на собственных расхождениях, построить вполне реально.
Сколько стоит ИИ в такой архитектуре
Еще один плюс гибридного подхода — экономика. Детерминированные правила практически ничего не стоят. AI-аннотации уже могут быть частью используемой CRM. Внешняя LLM нужна только тем запросам, которые прошли предыдущие уровни и остались неопределенными. Вместо того чтобы отправлять условные 500 лидов в языковую модель, мы можем отправлять туда несколько сложных кейсов в день.
То есть расходы на сам AI становятся практически незаметными. Но главное даже не стоимость токенов. Мы уменьшаем количество компонентов, от которых зависит результат. Если простой запрос можно правильно распределить обычным правилом, делать его зависимым от внешней AI-модели просто нет смысла.
Что в итоге получает бизнес
Правильно построенная система автоматического распределения решает намного больше задач, чем кажется в начале.
- Во-первых, рекомендация появляется быстрее, чем сотрудник успевает открыть новый лид.
- Во-вторых, ручной распределитель перестает каждый раз заново вспоминать структуру ассортимента.
- В-третьих, появляется статистика качества распределения.
- В-четвертых, сам регламент начинает проверяться на реальном потоке.
- В-пятых, типовые маршруты постепенно переводятся на автоматический режим.
И только после этого можно говорить о настоящем автопилоте. Не потому, что «мы подключили ИИ», а потому, что система доказала свою точность данными.
Как понять, что автораспределение лидов вам делают правильно
Если вы планируете автоматизацию CRM, проверьте проект по нескольким пунктам.
1. Сначала формализуют правила бизнеса.
До написания алгоритма должна появиться понятная схема маршрутизации и приоритетов.
2. Система начинает с рекомендаций.
Робот сначала советует, а не самовольно меняет ответственных.
3. Решения сравниваются с действиями человека.
Без мэтчинга невозможно объективно понять реальную точность.
4. Каждая рекомендация объяснима.
Должно быть видно, почему выбран конкретный маршрут.
5. ИИ используется только там, где он действительно нужен.
Для слова «ремонт» не требуется GPT. Для сложного свободного описания задачи — возможно, требуется.
6. Неуверенность является допустимым результатом.
«Нужен ручной разбор» лучше, чем уверенное неправильное решение.
7. Есть мониторинг и логи.
Вы должны понимать, что робот делает прямо сейчас и почему он что-то не сделал.
8. Систему можно быстро изменять.
Новые товарные группы, сотрудники и формулировки клиентов не должны требовать переписывания половины проекта.
9. Автопилот включается по статистике.
Не потому, что прошло две недели и «вроде нормально», а потому, что накоплена достаточная выборка и измерена точность конкретного маршрута.
Вместо вывода
ИИ действительно может серьезно помочь в распределении входящих лидов. Но зрелая автоматизация выглядит не так: «Отправляем все в GPT и верим ответу».
Она выглядит так:
регламент → быстрые правила → AI-сигналы → сложные кейсы в LLM → человек для исключений → мэтчинг → статистика → постепенный автопилот.
Мы в NJ Soft строим такие системы для Битрикс24 и других CRM: от формализации действующего регламента и первой версии робота-советника до автоматического распределения проверенных категорий лидов.
Если у вас уже есть стабильный поток входящих обращений и человек регулярно тратит время на их ручное распределение — приходите с текущим процессом и примерами лидов.
Разберем маршрутизацию, определим, что можно надежно автоматизировать правилами, где действительно нужен ИИ, и соберем первую рабочую версию советника за несколько дней — без риска сразу отдавать роботу управление продажами.
