В этом кейсе мы не показывали красивую демонстрацию на нескольких карточках. Мы создали в живом Bitrix24 синтетический бизнес-контур на пять рабочих дней, провели через него сделки, задачи, активности и документы, а затем дали ИИ задачу работать так, как должен работать ассистент руководителя: не пересказывать CRM, а находить то, что требует внимания, объяснять почему и, при разрешении, выполнять действие с последующей независимой проверкой результата.
Все данные в тесте синтетические. Реальные клиенты, телефоны, почта и платёжные данные не использовались. Работа шла через REST API существующего Bitrix24-портала. Деловая активность была смоделирована за 1–5 сентября 2026 года, итоговый live read-back выполнен 8 сентября.
Что мы создали в Bitrix24
Тестовый контур имитировал небольшую B2B-компанию с несколькими клиентами и параллельными продажами из разных источников.
В результате в Bitrix24 было создано и затем прочитано обратно:
- 7 компаний: одна основная и шесть клиентских;
- 6 синтетических контактов;
- 16 сделок;
- 8 задач после финального управленческого действия;
- 18 CRM-активностей;
- 9 комментариев в таймлайне сделок;
- товар, товарная строка в сделке, коммерческое предложение, счёт и отдельный smart process.
Сумма всех 16 сделок составила 6 575 000 ₽. Источники были намеренно перемешаны: WEB — 4 сделки, CALL — 4, EMAIL — 3, ADVERTISING — 3, PARTNER — 2.
Цель была не проверить, умеет ли API вернуть список сделок. Это базовый уровень. Нам было важно проверить цепочку целиком:
что ИИ видит → как связывает объекты → какой управленческий вывод делает → какое действие может выполнить → подтверждается ли результат повторным чтением из Bitrix24.
Первая ловушка: «активная воронка» оказалась меньше, чем выглядела
На первом проходе можно было получить цифру 5 750 000 ₽ активной воронки. Формально сделки ещё существовали в CRM, и часть из них не находилась в стадии LOSE.
Но такой расчёт был бы неправильным.
Мы отдельно прочитали справочник стадий Bitrix24 и их семантику. В этом портале стадия APOLOGY имеет SEMANTICS=F. Для управленческого анализа это означает не «ещё одна рабочая стадия», а неуспешную ветку.
После пересчёта по фактической семантике стадий получилось:
- активная воронка — 9 сделок на 4 130 000 ₽;
- успешные сделки — 3 на 575 000 ₽;
- сделки в failure-семантике — 4 на 1 870 000 ₽.
Это важный пример того, зачем руководителю нужен не просто доступ ИИ к CRM. Если система механически суммирует статусы по названиям или заранее заданной логике, она может дать красивую, но неверную управленческую цифру. ИИ должен сначала понять модель конкретного портала.
Что ИИ нашёл в активной воронке
После нормализации стадий мы задали более полезный для руководителя вопрос: какие активные сделки сейчас требуют внимания?
Для этого «следующим действием» считалась хотя бы одна открытая задача или CRM-активность, связанная со сделкой.
До вмешательства ИИ нашёл четыре активные сделки, у которых не было открытого следующего шага:
- сделка 146 — 180 000 ₽;
- сделка 148 — 185 000 ₽;
- сделка 160 — 1 250 000 ₽;
- сделка 172 — 275 000 ₽.
Всего — 1 890 000 ₽ активной воронки без следующего действия.
Главный риск был очевиден: крупнейшая из этих сделок, ID 160, стоила 1,25 млн ₽ и находилась в рабочей стадии PREPARATION, но следующего действия по ней не было.
Для руководителя это уже не отчёт «у вас 16 сделок». Это конкретный ответ: вот деньги в активной воронке, по которым процесс фактически не движется.
ИИ не только нашёл проблему, но и исправил её
Дальше мы проверили write-back.
ИИ получил разрешение создать следующий шаг для сделки 160. Через REST API была создана задача:
«AI remediation: next action for high-value deal»
Задача получила ID 20, дедлайн 9 сентября 18:00 и CRM-привязку D_160.
После создания мы не стали считать ответ API достаточным доказательством. Был выполнен отдельный read-back задачи по Bitrix24. Он подтвердил:
- задача действительно существует;
- статус остаётся открытым;
- дедлайн записан корректно;
UF_CRM_TASKсодержитD_160.
После этого в таймлайн сделки был записан синтетический комментарий о том, что ИИ обнаружил активную сделку на 1,25 млн ₽ без следующего действия и создал follow-up. Комментарий получил ID 808 и также был найден отдельным чтением таймлайна.
После write-back зона риска изменилась:
до действия ИИ: 4 сделки / 1 890 000 ₽ без следующего действия;
после действия ИИ: 3 сделки / 640 000 ₽.
То есть одним разрешённым действием ИИ снял 1 250 000 ₽ из категории «активная сделка без следующего шага».
Это и есть принцип, который мы хотим получить от ИИ-ассистента руководителя: не просто «найти проблему», а довести понятный управленческий сценарий до контролируемого действия и затем проверить, что изменение действительно появилось в системе.
Просрочки: одна сделка уже вышла за дату закрытия
Следующая проверка — сроки.
Среди девяти активных сделок нашлась сделка ID 170 на 910 000 ₽. Она оставалась в активной стадии PREPARATION, но её плановая дата закрытия была 6 сентября. Итоговый read-back проводился 8 сентября.
То есть для руководителя это отдельный сигнал: сделка всё ещё считается активной, но плановая дата уже прошла.
Одновременно в задачах было найдено четыре открытые просрочки: ID 8, 12, 16 и 18.
Особенно важно не само число «4 задачи», а их связь с деньгами. Две просроченные задачи относились к активным сделкам:
- сделка 154 — 780 000 ₽;
- сделка 170 — 910 000 ₽.
Суммарно 1 690 000 ₽ активной воронки связано с просроченными задачами.
Это уже другой управленческий срез. Руководителю не нужно листать общий список задач и отдельно вспоминать стоимость каждой сделки. ИИ может связать сроки, статус задачи и сумму сделки и вывести приоритет именно по бизнес-риску.
Ещё один сигнал: успешная сделка с суммой 0 ₽
Сделка ID 152 находилась в успешной стадии WON, но её сумма равнялась нулю.
Это не означает автоматически, что сотрудник ошибся. Возможны разные бизнес-причины: тестовая сделка, бесплатная работа, некорректно заполненная карточка, перенос суммы в другой объект.
Но для ИИ это корректный сигнал качества данных: сделка считается выигранной, а финансового результата в карточке нет — требуется проверка.
Именно здесь проходит важная граница между хорошим управленческим ассистентом и системой, которая начинает самовольно «исправлять» CRM. Найти противоречие можно автоматически. Менять сумму без подтверждения нельзя.
Проверяли не только сделки и задачи
Чтобы кейс не сводился к одному crm.deal.list, мы прошли расширенный контур Bitrix24.
Через API был создан товар ID 10 стоимостью 50 000 ₽. В сделке 150 затем независимо прочиталась товарная строка: 2 единицы по 50 000 ₽, всего 100 000 ₽.
Для той же связки были проверены другие CRM-объекты:
- коммерческое предложение ID 6, статус
DRAFT, привязка к сделке 150; - черновик счёта ID 4 на 100 000 ₽, parent deal 150;
- smart process type ID 10,
entityTypeId=1040; - smart item ID 2 на 77 777 ₽, связанный с компанией 14 и контактом 136.
Важная деталь: у коммерческого предложения ID 6 поле OPPORTUNITY равно 0. Поэтому мы не приписываем ему сумму 100 000 ₽ только потому, что рядом существует товарная строка или счёт. Для экспертного кейса такая граница принципиальна: ИИ должен опираться на фактические поля конкретного объекта, а не достраивать желаемую картину.
Платежи в тесте не инициировались.
Что в итоге может спросить руководитель
После такого подключения вопрос к CRM перестаёт выглядеть как «покажи список сделок».
Нормальные управленческие запросы уже звучат иначе:
- сколько денег реально находится в активной воронке с учётом семантики стадий;
- какие крупные сделки не имеют следующего действия;
- где плановая дата закрытия уже прошла;
- какие просроченные задачи относятся к самым дорогим активным сделкам;
- есть ли выигранные сделки с подозрительными финансовыми данными;
- из каких источников пришла текущая воронка;
- какие сделки связаны с товарами, счетами, предложениями и другими CRM-объектами;
- что можно исправить автоматически в пределах разрешённых действий;
- подтверждает ли повторное чтение, что действие действительно выполнено.
В этом тесте все эти вопросы опирались не на заранее подготовленный текст, а на реальные объекты тестового портала и повторный API read-back.
Что технически подтвердили
Для справки по возможностям и методам использовалась официальная документация Bitrix24 REST API. Описание нашей продуктовой связки вынесено на страницу интеграции ИИ-ассистента с Bitrix24.
Текущий webhook возвращает scopes crm, task, tasks. Метод methods на момент финальной проверки вернул 482 доступных метода. В рамках кейса использовалась только релевантная часть этого контура.
На практике подтверждены чтение, создание и связывание:
- компаний и контактов;
- сделок и стадий;
- задач;
- CRM-активностей;
- комментариев таймлайна;
- товаров и товарных строк;
- коммерческих предложений;
- счёта нового CRM-типа;
- smart process и его элемента.
Ключевой acceptance-паттерн для write-back был один и тот же:
прочитать исходное состояние → выполнить разрешённое действие → получить ID результата → отдельно прочитать объект → проверить нужные поля и связь с исходной сделкой.
Что этот тест доказывает, а что нет
Он доказывает, что ИИ можно подключить к реальному Bitrix24-контуру так, чтобы он работал с CRM как с управленческой системой, а не только как с источником текста.
Он может связать сумму сделки со стадией, сроком, задачами и активностями; выделить отклонение; сформулировать причину внимания; при наличии разрешения записать следующий шаг и проверить результат.
Но этот тест не означает, что ИИ должен автоматически менять всё, что считает подозрительным. У действий остаются права, границы и approval-политики. В нашем тесте мы сознательно не инициировали платежи и не исправляли автоматически финансовые поля сделки с нулевой суммой.
Также это синтетическая пятидневная модель, а не статистическое исследование эффективности отдела продаж. Цифры 1,89 млн ₽, 1,69 млн ₽ и 4,13 млн ₽ относятся именно к созданному тестовому контуру и нужны для проверки управленческой логики интеграции.
Что получает владелец бизнеса
Главный результат такого подключения — не ещё один дашборд.
Владелец получает возможность спросить: «Что сейчас требует моего внимания в продажах?» — и получить не набор карточек, а связанный управленческий ответ.
В нашем тесте этот ответ выглядел так: активная воронка составляет 4,13 млн ₽; в ней есть просроченная по плановой дате сделка на 910 тыс. ₽; две активные сделки на 1,69 млн ₽ связаны с просроченными задачами; до вмешательства 1,89 млн ₽ активных сделок не имели открытого следующего действия; крупнейшую из них на 1,25 млн ₽ ИИ сам перевёл из этой зоны риска, создав задачу и подтвердив результат повторным чтением.
Именно такой уровень работы мы считаем полезной интеграцией ИИ с Bitrix24: увидеть → понять → приоритизировать → выполнить разрешённое действие → проверить.
Подключить ИИ-ассистента к продажам
Если Bitrix24 уже используется в работе, его не нужно заменять. ИИ можно подключить поверх существующего контура: сначала дать ему чтение и управленческий анализ, затем отдельно разрешить конкретные действия с обязательной проверкой результата.
ИИ-ассистент руководителя по продажам — товарная позиция Agency для такого сценария: контроль продаж, связка данных из рабочих систем и разрешённый write-back.