ИИ-анализ сделок в Битрикс24: что проверить в CRM

Какую задачу поставить ИИ

Вопрос «почему упали продажи?» требует данных о периодах, составе воронки и причинах отказа. Для первой проверки проще выбрать конкретный признак: дата последней активности не позже согласованной границы либо отсутствует. Результат даст очередь карточек для ручного разбора.

Укажите воронку, ответственных и точное время с часовым поясом. В нашем примере граница равна 18 октября 2026 года, 00:00 по Москве. Дата на самой границе тоже входит в отбор. Это условие учебной задачи; подходящий интервал для вашей команды зависит от обычного цикла продажи.

Отдельно договоритесь, что значит полезный ответ: перечислить найденные ID, показать дату активности и причину попадания в список, сообщить, все ли доступные записи вернулись. Общие советы о продажах без этих данных проверить по CRM не получится.

Последняя активность и изменение карточки: разные даты

Битрикс24 обновляет последнюю активность по определённым событиям, в том числе при входящем письме или звонке. Этот показатель не охватывает все действия с клиентом. Дата изменения карточки хранится отдельно: свежее изменение полей не доказывает недавний контакт.

Поэтому используйте формулировку «сделки для проверки по дате активности». Утверждение «менеджер не работал с клиентом семь дней» потребует дополнительных сведений. Если дата отсутствует, по ней нельзя посчитать, сколько дней длится пауза.

Открыть в полном размере ↗

Как этот сценарий устроен в MCP TrueTell

В коде приложения есть инструмент bitrix_get_deals_without_activity. Он отбирает сделки в работе с датой lastActivityTime не позже заданного inactiveBefore или без этой даты. Доступны фильтры по воронкам и ответственным. Произвольный фильтр по сумме или выбранной стадии в этот инструмент не входит.

Результат содержит ID и название сделки, коды стадии и воронки, ID ответственного, даты изменения и активности. Имена сотрудников и названия стадий нужно сверять по соответствующим справочникам, а не угадывать по кодам. Суммы сделок и содержимое переписки этот результат не возвращает.

Один вызов возвращает по умолчанию до 20 записей; допустимый предел составляет 100. Вместе со списком приходят returned, totalAvailable и truncated. При truncated=true ответ охватывает только часть подходящих доступных записей. Уточните поддерживаемые фильтры; сам запрос «продолжи» не гарантирует выгрузку остатка.

В проверке общего MCP TrueTell 27 октября 2026 года в Codex ответили без ошибки 13 доступных инструментов чтения. Это не означает работу всех сценариев и клиентских порталов. Подключение в ChatGPT и Claude ещё не принято, открытая установка пока не заявлена.

Пример запроса для проверки сценария

После подтверждения подключения и доступа к нужному инструменту задачу можно сформулировать так. ID воронки и ответственных сначала сверяют с CRM:

Найди до 20 сделок в работе в согласованной воронке у выбранных ответственных. Дата последней активности не позже 18 октября 2026 года, 00:00, часовой пояс +03:00, либо отсутствует. Покажи ID, название, стадию, ответственного, даты активности и изменения. Для каждой строки укажи основание отбора. Сообщи returned, totalAvailable и truncated. Не делай вывод о причинах задержки без истории карточки. Ничего не изменяй.

Это пример задания для будущей проверки в выбранном клиенте. Он не подтверждает, что ChatGPT уже подключён к нашему приложению. Если инструмент не вызван или вернул ошибку, ответ должен сообщать об этом, сохраняя задачу незавершённой.

Учебный пример: какие сделки попадут в список

Возьмём шесть условных сделок одной воронки с согласованными ответственными. Все даты ниже относятся к октябрю 2026 года и московскому времени. Из четырёх открытых сделок условиям соответствуют 101, 102 и 104. Две закрытые сделки исключаются независимо от даты активности.

У сделки 101 поля менялись 24 октября, но дата активности осталась 10 октября. Сделка 102 попадает в отбор по включённой границе. У сделки 104 нет даты активности: основание включения нужно назвать именно так, без выдуманного срока бездействия.

Если учебный ответ вернул все три подходящие записи, его показатели равны returned=3, totalAvailable=3, truncated=false. Это ожидаемый результат нашего примера, а не замер живого портала. В реальной проверке сначала смотрят фактические значения ответа.

Как проверить ответ перед разбором продаж

Откройте сделки из ответа под тем же пользователем Битрикс24. Сравните ID, даты и текущую стадию. Видимость записей зависит от прав чтения: список сотрудника не равен всей базе компании. Если данные успели измениться после запроса, зафиксируйте время сверки и повторите чтение при необходимости.

Открыть в полном размере ↗

После сверки можно обсуждать конкретную карточку: ждём ли ответ клиента, назначено ли следующее действие, есть ли в истории договорённость о более длинной паузе. Такой контекст помогает решить, кому и когда связаться с клиентом. Одна дата активности этого решения не даёт.

Для регулярных показателей по периодам и менеджерам пригодится отдельный разбор отчётов по продажам Битрикс24. Переходы между стадиями и конверсию рассматриваем в материале о воронке продаж. Эти задачи требуют собственных правил расчёта.

Обсудить анализ сделок через MCP TrueTell

Для обсуждения достаточно назвать воронку, желаемый AI-клиент, вопрос к сделкам и способ проверки результата. Передавать содержимое CRM в первоначальной заявке не требуется. Доступ к данным и условия подключения согласовываются отдельно.

Кнопка ниже открывает форму TrueTell. В заявке можно описать задачу без клиентских данных; мы уточним возможности для вашего портала и выбранного AI-клиента.