статья · 24.10.2026
ИИ в Битрикс24 чаще продают как кнопку «сделать умно», а не как рабочий инструмент. Эффект дают несколько сценариев, где модель экономит менеджеру минуты каждый день. Ниже — что внедрять первым, а что подождёт.
Есть сценарии, где ИИ встроен в уже существующее действие и не требует нового поведения от сотрудника. Менеджер открывает карточку, пишет письмо, закрывает сделку — ИИ просто убирает часть рутины внутри этих шагов.
Черновик письма в карточке. Модель получает историю переписки, данные сделки и задачу («напомнить о счёте», «уточнить сроки») и выдаёт готовый текст. Менеджер правит и отправляет. Экономия не в скорости печати, а в том, что не нужно каждый раз вспоминать контекст.
Разбор входящей заявки. Из письма, формы с сайта или сообщения в мессенджере извлекаются тема, город, объём, срочность и бюджет, если клиент их назвал. Поля заполняются сами, заявка попадает в нужную воронку и к нужному ответственному.
Выжимка переписки. Длинный тред на сорок сообщений и запись звонка превращаются в пять строк: что просили, что обещали, что осталось. Это спасает, когда менеджер меняется или клиент возвращается через месяц.
Подсказки менеджеру. Следующий шаг, недостающие вопросы, риски вроде «клиент трижды спрашивал про сроки, ответа не было». Не приказ, а подсказка рядом с решением.
Красивая демонстрация и рабочий инструмент различаются одним: кто отвечает за результат. Если ИИ что-то сгенерировал, а проверить и применить это некому, ценность близка к нулю.
Общий признак: сценарий выглядит эффектно на презентации, но не встроен в процесс и не имеет данных. Второй признак — после внедрения никто не может сказать, стало ли лучше. Значит, не было метрики.
Как отличить по делу. Задайте два вопроса к каждой демонстрации: что станет быстрее и кто это проверит. Если ответ «менеджеру будет удобнее» — это не аргумент, а впечатление. Если ответ «черновик ответа вместо двадцати минут набора» и есть человек, который принимает результат, сценарий стоит пилота.
Второй признак пустоты — функция живёт отдельно от работы. Кнопка «сгенерировать текст» в карточке, которая никуда не подключена, не меняет ни сроки, ни качество. Красивый отчёт для руководства, собранный моделью из данных, которых в CRM нет, тоже.
Встроенный помощник Битрикс24 работает внутри интерфейса. Он видит то, что открыто на экране, и помогает с текстом. Это полезно, но границы жёсткие: он не сходит в 1С за остатками, не сверит заявку с договором и не выполнит действие по регламенту.
Агент — отдельный сервис. У него есть свои права доступа, набор инструментов (API CRM, база знаний, 1С, почта), правила и журнал. Он может собрать данные из трёх систем, проверить их между собой и вернуть результат в карточку или отправить ответ клиенту.
Разница проявляется на первом же нестандартном запросе. Встроенный помощник скажет «в карточке нет информации». Агент сходит в источник, где информация есть, и покажет, откуда он её взял. Подробнее о том, как такие агенты устроены, — в разделе ИИ-агенты для бизнеса.
Агент отвечает по фактам только тогда, когда факты у него есть. Основа — не модель, а слой данных: справочники товаров и цен, остатки, статусы заказов и оплат, история обращений.
Практически это означает обмен между системами по API или вебхукам и один общий ключ: ИНН, телефон или ID клиента. Если в CRM клиент записан как «ООО Ромашка», а в 1С — как «Ромашка, ООО», связь теряется, и никакая модель этого не исправит.
Синхронизация задаётся расписанием и правилами: что обновляется раз в час, что по событию, что вообще не покидает контур. Отдельно решается, что делать при расхождении данных. Это правило важнее любой модели. Как это устроено на практике — в разделе интеграции CRM, 1С и сайта.
У агента должен быть минимально необходимый доступ. Читать карточку — да. Писать комментарий — да. Менять сумму сделки, статус оплаты или удалять запись — нет, только через человека.
Права описываются по ролям: что агент видит, что предлагает, что делает сам. Отдельно — что он не делает никогда, независимо от формулировки запроса. Это не бюрократия: одна ошибка с ценой в письме клиенту стоит дороже, чем весь пилот.
Журнал действий отвечает на четыре вопроса: кто, что, когда и на основании каких данных. Хранится запрос, ответ, вызванные инструменты, изменённые поля и прежние значения. Без журнала нельзя ни отладить сценарий, ни объяснить клиенту, откуда взялась цифра, ни откатить неудачную правку.
Журнал нужен и бизнесу: когда сотрудник спрашивает, почему агент так написал, ответ должен быть в системе, а не в переписке с разработчиком.
Спор «стало удобнее» не заканчивается никогда. Поэтому до пилота фиксируется метрика и её текущее значение.
Четыре метрики хватает, чтобы через две недели сказать «работает» или «не работает» без вкусовщины. Если ни одна не сдвинулась, сценарий закрывается — это нормальный результат пилота, а не провал проекта.
Отдельно про деньги. Считать надо не стоимость запросов к модели, она невелика, а сэкономленные часы: если действие занимало десять минут и происходит двадцать раз в день, это больше трёх часов ежедневно на отдел. Даже частичное сокращение видно. Запросы к модели на таком объёме стоят десятки рублей в месяц, а не зарплату — подробнее про то, из чего складывается цена.
Пилот не начинается со всей компании. Берётся один отдел, один процесс и один сценарий, у которого есть владелец и измеримый результат. Например, разбор входящих заявок в отделе продаж.
Порядок работ: разобрать процесс как он есть, выбрать сценарий, собрать данные, сделать первую версию, дать её двум-трём сотрудникам, неделю смотреть журнал и правки, затем расширять. Первая рабочая версия обычно занимает от двух до четырёх недель, если доступ к API есть и решение принимает один человек, а не комитет.
Метрика считается до и после. Пример расчёта: 30 заявок в день, на разбор каждой менеджер тратит 3 минуты — это полтора часа в день на отдел. Если черновик закрывает половину работы, экономия около 45 минут в день. Цифры условные, считать нужно по своим данным.
Судить о результате раньше, чем через две-три недели работы с живыми заявками, нельзя: первые дни показывают не пользу, а ошибки настройки.
Есть ситуации, в которых ИИ не окупится, и честнее сказать об этом сразу.
Если пункты выше про вас, полезнее начать с порядка в CRM и с интеграций. Это скучнее, но именно на этом фундаменте ИИ потом работает. Обсудить свой случай можно в контактах.
Нет. Он снимает рутину: черновики писем, разбор заявок, выжимки переписки, подсказки. Решение, цену и разговор с клиентом по-прежнему ведёт человек. Сценарии, где ИИ пытаются поставить вместо менеджера, обычно заканчиваются тем, что кто-то всё равно проверяет каждое сообщение, — и экономии не возникает.
Если агент должен называть цены, наличие и статусы заказов — да, без источника этих данных он будет выдумывать. Доступ выдаётся только на чтение нужных справочников и документов. Если 1С нет или она закрыта, можно начать со сценариев на данных CRM и сайта.
Часто да. Встроенных полей, вебхуков и REST API хватает для пилота: агент читает карточку, пишет комментарий, создаёт задачу. Доработка нужна, когда процесс не помещается в стандартную воронку или требуются свои статусы и правила.
Зависит от модели. Можно работать через облачный API, можно поднять модель в своём контуре, если данные нельзя выносить. Выбор влияет на стоимость и скорость, но не отменяет правила: в модель отправляется только то, что нужно для конкретной задачи.
Первый сценарий — обычно от двух до четырёх недель, включая сбор данных и настройку прав. Дальше неделя-две наблюдения на живых заявках. Точный срок зависит от готовности интеграций и от того, как быстро принимаются решения, а не от модели.
Опишите процесс в двух предложениях — вернусь со схемой решения и оценкой сроков.