Интеграция ИИ с Битрикс24 делается через REST-приложение и входящие вебхуки: модель читает лиды, сделки, звонки и переписку, а обратно пишет квалификацию, поля карточки, задачи и комментарии. ИИ-слой стоит на вашем сервере рядом с порталом — наружу не уходит ни один диалог. Сверху собираем дашборды по воронке, среднему чеку и работе менеджеров, сверенные с 1С.
Шесть сценариев, которые мы ставим чаще всего. Каждый привязан к конкретной сущности портала и к метрике, которую видно в отчётах CRM ещё до конца пилота.
Модель читает текст заявки, историю касаний и расшифровку первого звонка, ставит оценку по вашим критериям — бюджет, сроки, профиль компании, регион — и заполняет поле квалификации. Нецелевое уходит на отдельную стадию, горячие лиды поднимаются наверх очереди ответственного.
Из переписки в открытых линиях, писем и расшифровки разговора достаются номенклатура, объём, сроки поставки, контактное лицо и его должность. Поля заполняются автоматически, спорные значения помечаются и остаются на подтверждение менеджеру.
Агент сверяет сделку с регламентом продаж: что положено сделать на этой стадии, что уже сделано, где повисла пауза. В таймлайн падает комментарий вида «по сделке нет активности, отправьте расчёт по спецификации».
Как устроены ИИ-агентыКП собирается из актуального прайса, остатков и вашего шаблона: позиции, цены с учётом скидочной матрицы, сроки, условия оплаты. Файл прикрепляется к сделке, менеджер правит и отправляет. Цены модель не придумывает — берёт из справочника.
Ежедневный обход дел и задач: что просрочено, по каким сделкам нет активности, где нарушен норматив первого ответа. Ответственный получает свой список в чат портала, руководитель — сводку по отделу с фамилиями и суммами на риске.
Утренний дайджест: движение по воронке за сутки, крупные сделки без движения, отклонения от плана, причины проигрышей за неделю. Текст пишет модель, цифры подставляются из выгрузки, а не сочиняются.
Портал не умеет запускать языковую модель у себя, поэтому ИИ-слой всегда стоит рядом. Схема одинаковая и для облачного Битрикс24, и для коробочной версии.
Границы доступа фиксируются до начала работ и согласуются со службой безопасности. Ниже — типовое разграничение, от которого мы отталкиваемся.
| Сущность портала | Что читаем | Что пишем | Кто подтверждает |
|---|---|---|---|
| Лиды | Текст заявки, источник, историю касаний | Оценку квалификации, теги, ответственного | Автоматически, спорные — менеджеру |
| Сделки | Поля, стадию, товарные позиции, таймлайн | Пропущенные поля, комментарий, файл КП | Менеджер по спорным значениям |
| Дела и задачи | Сроки, ответственных, статусы, просрочку | Задачу-напоминание и комментарий | Автоматически |
| Открытые линии и почта | Переписку по сделке и контакту | Черновик ответа в карточке | Менеджер перед отправкой |
| Телефония | Записи разговоров и метаданные звонка | Расшифровку и краткое резюме в таймлайн | Автоматически |
| Диск | Прайсы, шаблоны, спецификации | Готовый файл КП в папку сделки | Менеджер перед отправкой |
| Стадия и сумма сделки | Текущие значения и историю изменений | Ничего без явного подтверждения | Только человек |
Штатные отчёты портала отвечают на вопрос «сколько» и плохо отвечают на вопрос «почему». Поэтому рядом с Битрикс24 мы поднимаем аналитический слой: копию нужных сущностей в отдельной базе, обновление по изменённым записям и событиям, BI поверх неё. Портал не нагружается тяжёлыми запросами, а история переходов по стадиям хранится столько, сколько нужно вам.
Базовый набор метрик: воронка по стадиям с конверсией каждого перехода, доля WON и LOSE с разбором причин проигрыша по тексту комментариев, средний чек в разрезе менеджера, канала и товарной группы, срок сделки от первого касания до оплаты. Отдельный блок — качество работы менеджеров: время первого ответа, доля сделок без активности, просроченные дела, соблюдение обязательных шагов регламента.
Часть показателей в CRM недостоверна по определению: сделка помечена выигранной, а отгрузки и оплаты нет. Поэтому финансовый контур сверяется с 1С — реализации, оплаты, дебиторка. Расхождения не прячем: в дашборде есть виджеты «WON без отгрузки» и «оплата есть, сделка не закрыта», с переходом к списку сделок. Как это устроено со стороны учётной системы, разобрано на странице внедрения ИИ в 1С.
Портал не запускает языковые модели. В нём нет рантайма для инференса, нет места под векторный индекс и нет способа хранить эмбеддинги в пригодном для поиска виде. Всё это живёт на отдельном сервере, а Битрикс24 остаётся тем, чем и является, — системой учёта и рабочим интерфейсом для людей.
Роботы и бизнес-процессы не рассчитаны на долгие вызовы. Генерация КП по большой спецификации или разбор часовой записи разговора не укладывается в сценарий «робот дождался ответа». Такие задачи ставятся асинхронно: робот кладёт задание в очередь, ИИ-слой обрабатывает и возвращает результат отдельным вызовом, пользователь видит статус в карточке.
REST ограничен по частоте. Точечные операции проходят свободно, а пересчёт истории по десяткам тысяч сделок через API растянется надолго. Поэтому первичная выгрузка делается один раз в аналитическую базу, дальше идут только изменения.
Сквозная картина внутри портала не собирается. Связать рекламный кабинет, звонки, сделки и отгрузки в 1С штатными средствами не выйдет: часть данных в Битрикс24 просто не попадает. Сквозной слой строится снаружи — по той же логике, что в кейсе дашбордов по рекламным кабинетам.
И честное про облако. Если портал облачный, данные CRM уже лежат на стороне вендора, и локальный ИИ-контур этого не меняет: он гарантирует, что переписка и документы не уходят в публичные ИИ-сервисы, но сам портал к вам не переносит. Когда требование жёстче, нужна коробочная версия или полностью локальный контур.
Порядок тот же, что на других внедрениях, с одной поправкой: сначала смотрим, в каком состоянии данные в CRM, и только потом обсуждаем сценарии.
Смотрим воронки, набор полей, дисциплину заполнения, подключённую телефонию и объём истории. Считаем, сколько времени менеджеры тратят на то, что можно снять.
Обычно это квалификация лидов или автозаполнение сделок. Снимаем замер «до», собираем приложение на тестовом портале, выводим на боевой, метрику берём из отчётов CRM.
Добавляем остальные сценарии, поднимаем аналитическую базу, собираем дашборды, подключаем сверку с 1С, настраиваем права, журналирование и роли.
Еженедельные релизы с ручной проверкой перед раскаткой, мониторинг очереди и лимитов REST, доработка под изменения в воронках и регламентах продаж.
Работают оба варианта: REST-приложение и вебхуки доступны и в облаке, и в коробке. Разница в том, где лежат данные CRM. В облаке они на стороне вендора, и локальный контур защищает только слой ИИ — переписка и документы не уходят в публичные модели, но сам портал остаётся облачным. Если служба безопасности требует, чтобы все данные были внутри периметра, нужна коробочная версия на вашем сервере. Такой переезд мы обсуждаем на диагностике, до начала работ и до любых обязательств.
Права выдаются точечно: приложение получает доступ только к тем сущностям, которые нужны сценарию. Всё, что модель пишет обратно, проходит валидацию — тип поля, значение из справочника, допустимый диапазон суммы. Необратимые действия отделены от обратимых: комментарий в таймлайн или задача ставятся автоматически, а смена стадии, изменение суммы и письмо клиенту требуют подтверждения человека. Каждая запись журналируется с указанием сценария и версии модели, поэтому изменение можно отследить и откатить.
Пилот на одном сценарии — 2–4 недели, включая замер «до» и вывод на боевой портал. Первый работающий контур на типовом кейсе — 4–8 недель. Дольше всего тянутся не технические работы, а порядок в данных: если у сделок половина обязательных полей пустая, воронки дублируются, а телефония не привязана к карточкам, сначала придётся навести порядок. Состояние портала видно уже на диагностике, и мы прямо говорим, сколько времени займёт подготовка.
Записи забираются из телефонии портала и расшифровываются на вашем сервере открытыми моделями для русской речи — GigaAM или T-one, выбор зависит от качества линии. Из расшифровки достаются договорённости, возражения, названные суммы и сроки, а в таймлайн сделки попадает короткое резюме со ссылкой на нужный фрагмент. Ни один файл не уходит во внешние сервисы распознавания. Про речевой стек и его ограничения написано отдельно на странице голосового ИИ.
Частично да. Отчёты по воронке и нагрузке менеджеров собираются штатными средствами портала, и если задача только в этом, внешний слой не нужен. Отдельный BI появляется там, где нужны данные, которых в CRM нет: отгрузки и оплаты из 1С, расходы из рекламных кабинетов, длинная история изменения стадий. Вторая причина — нагрузка: тяжёлые аналитические запросы лучше держать в стороне от боевого портала, чтобы не тормозить работу отдела продаж.
Начинаем с того, что есть. Переделка воронки на старте — частая причина, по которой проект вязнет: люди сопротивляются изменению привычного порядка, и эффект ИИ перестаёт быть отделим от эффекта реорганизации. В пилоте мы встраиваемся в существующие стадии и поля, а предложения по изменению структуры отдаём отдельным документом с обоснованием и оценкой трудозатрат. Решение принимает руководитель продаж. Как сценарии складываются в процесс целиком, показано на странице ИИ в продажах.
30–40 минут разбора: смотрим ваши процессы, отмечаем, что можно передать ИИ, считаем ROI-модель на ваших объёмах и сроках. Вы уходите с расчётом и картой внедрения — даже если работать дальше не будете.