Причины отказов в Битрикс24: сводка потерянных сделок по менеджерам

Какие поля брать из Битрикс24

Отдельного стандартного поля «причина отказа» у сделки нет. По описанию полей сделки в документации (crm.deal.fields) есть стадия STAGE_ID, группа стадии STAGE_SEMANTIC_ID (у проигранных сделок это группа «провал»), дата закрытия CLOSEDATE, ответственный ASSIGNED_BY_ID, источник SOURCE_ID и сумма OPPORTUNITY. Причину компании хранят по-разному: несколькими стадиями провала («Дорого», «Выбрали конкурента»), пользовательским полем-списком или комментарием при закрытии. Посмотрите, как это устроено у вас, до того как строить сводку. Если причины пишут только в комментарии, сводку придётся собирать по тексту, и это тот случай, где ИИ полезнее таблицы.

Где именно сделку потеряли, показывает история смены стадий: последняя стадия перед переходом в провал. Перед сбором проверьте справочник причин, в каком бы виде он ни был. Типичная картина (условный пример): двадцать пунктов, из которых используются три, и «другое» набирает 40%. Такой справочник не годится для анализа, и его стоит сжать до 6–8 понятных причин, например: цена, выбрали конкурента, нет бюджета, не ответил, не наша задача, сроки, дубль или спам.

Ручной способ

1. Выгрузите сделки со стадией «Провал» за квартал: ID, дата создания, дата закрытия, сумма, источник, ответственный, причина, стадия, на которой потеряна (её видно в истории сделки).
2. Сделайте сводную таблицу «причина по менеджерам» в штуках и в рублях.
3. Сделайте вторую: «причина по стадиям».
4. Для каждой причины, на которую приходится больше 15% суммы, откройте 5–10 карточек и прочитайте комментарии.

Последний пункт самый ценный и самый трудоёмкий. Причина «дорого» в поле и «клиент сравнил нас по цене в первом звонке, мы не показали ценность» в комментарии это разные выводы.

Ловушки, которые искажают сводку

Причина выбрана, чтобы закрыть карточку. Менеджеры ставят первое попавшееся значение или «другое». Сопоставьте причину с последними комментариями и делами: расхождения видны сразу.

Малые выборки. У менеджера пять потерь за квартал, и две из них «дорого». Это 40%, но делать выводы рано. Показывайте число сделок рядом с процентом и не сравнивайте менеджеров, у которых меньше десяти случаев.

Разные воронки и сегменты. Сравнивать потери менеджера по крупным клиентам с потерями по входящим мелким заявкам нельзя. Режьте по воронке или по типу клиента.

Поздняя фиксация. Сделку закрывают в «Провал» через два месяца после последнего касания. Смотрите на дату последней активности, а не только на дату закрытия.

Что делает ИИ-сотрудник

Сотрудник VibeLab, подключённый к порталу, читает потерянные сделки, стадии и историю их смены, дела и комментарии таймлайна, пользователей. Причину он берёт оттуда, где она у вас хранится: из стадии провала, пользовательского поля или текста комментария. Стадию потери определяет по истории смены стадий. Он строит сводки «причина по менеджерам» и «причина по стадиям» в штуках и в рублях, подсвечивает менеджеров с высокой долей пустых причин, читает комментарии к крупным потерям и пересказывает, что в них реально происходило. Арифметику считает исполняемый код, а не модель «на глаз», так что итоги можно сверить с вашей сводной таблицей.

Отчёт приходит в Telegram или на почту: например, каждую пятницу за неделю и в первый день месяца за прошлый. Сотрудник не меняет карточки: по умолчанию у него право «Читать». С правом «Писать» и режимом «С согласованием» он может предложить задачу менеджеру уточнить причину в конкретной сделке, и выполнит её после вашего подтверждения. Переписку с клиентами при необходимости можно разбирать отдельно: см. контроль переписок.

Как читать сводку на разборе

Начинайте с денег, а не со штук: две крупные потери весят больше двадцати мелких. Посмотрите три верхние причины по сумме и для каждой задайте вопрос «что мы могли сделать на предыдущей стадии». Затем сравните менеджеров между собой только там, где выборка достаточная, и ищите не худшего, а отличие: у кого доля потерь на КП заметно ниже и что он делает иначе. Это самый дешёвый способ перенять практику внутри команды.

На разборе фиксируйте одно изменение на квартал, не пять. Тогда можно будет проверить, сработало оно или нет. Если менять сразу скрипт, цену и воронку, вы не поймёте, что именно повлияло.

Чего не обещаем

Сводка покажет, где и в каких карточках теряются деньги, но не гарантирует рост продаж: решения по скрипту, цене и дожиму принимаете вы. Честная проверка выглядит так: замерьте долю потерь по стадиям за прошлый квартал, внесите одно изменение, например разбор потерь на «КП отправлено», и через квартал сравните на тех же правилах. Цифры эффекта в чужих кейсах без методики для вас не доказательство. Для подключения по вебхуку в облаке ru нужна подписка «BitrixGPT + Маркетплейс» (по справке Битрикс24 от 09.11.2026).

Частота и формат отчёта

Для отдела до пятнадцати менеджеров хватает недельной сводки на одну страницу: потери за неделю по причинам и стадиям, топ-5 крупных потерь с короткой выжимкой комментариев, менеджеры с долей «не указано» выше нормы. Квартальный отчёт нужен для решений по скрипту, цене и воронке, недельный для дисциплины. Не смешивайте их: недельные колебания на малых выборках легко принять за тренд.

Как начать в VibeLab

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