Почему проиграна сделка: причина клиента, версия менеджера и отчёт без двойного счёта

Разделите исход сделки и объяснение

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

В карточке полезно сохранять два поля: основание закрытия процесса и известное объяснение решения клиента. Например: «закрыто после согласованного срока без ответа» и «причина решения клиента неизвестна». Так руководитель видит завершённую работу, не получая выдуманной информации о мотивах покупателя.

HubSpot документирует отдельные свойства Closed lost reason и Deal stage. Само наличие такого поля не подтверждает достоверность внесённого объяснения. HubSpot: стандартные свойства сделки. Правила заполнения ниже — редакционная модель для настройки процесса, а не описание обязательного поведения этой CRM.

Не объявляйте незавершённые сделки проигранными ради отчёта по причинам. Сначала согласуйте границу завершения и дату среза; работу с созревшими исходами и открытым остатком рассматривает руководство по B2B-воронке.

Слова клиента и гипотеза требуют разных меток

Храните короткое содержание объяснения, ссылку на разрешённый источник, дату и автора записи. Отдельно обозначьте происхождение: прямо сообщил клиент; подтверждено рабочими обстоятельствами; предположил сотрудник; объяснение пока неизвестно. Это не рейтинг честности людей, а способ понимать границы данных.

Фраза «не укладываемся в бюджет» подтверждает сообщённое ограничение бюджета. Она сама по себе не доказывает, что сопоставимое предложение конкурента дешевле. Сообщение «выбрали другую компанию» подтверждает выбор другого поставщика, но не раскрывает причину выбора. Не достраивайте отсутствующее объяснение по названию поля.

В Dynamics 365 при закрытии возможности создаётся отдельная запись завершения с автором, временем и другими сведениями; причины можно пояснить заметкой. Microsoft: закрытие opportunity. Это пример сохранения события и пояснения, а не гарантия независимого подтверждения причины.

Для анализа достаточно относящегося к продаже основания. Лишние персональные сведения клиента в классификаторе не нужны. Если объяснение отсутствует, разрешите честное значение «неизвестно» и назначьте проверку качества записи вместо обязательного угадывания.

Одна основная причина и несколько сопутствующих

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

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

Сопутствующие факторы образуют другой отчёт: в скольких сделках упомянута каждая тема. Одна сделка может одновременно иметь тему срока и состава услуги. Сумма таких упоминаний вправе превышать число сделок; подпись должна предупреждать о пересечениях.

Стандартный отчёт HubSpot Deal loss reasons группирует проигранные сделки по значению соответствующего свойства. HubSpot: отчёт причин проигрыша. Дополнительная модель источников и сопутствующих факторов требует отдельной настройки и проверки.

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

Все числа вымышлены. Зафиксирован набор из 20 уникальных сделок, завершённых проигрышем в выбранном периоде. У каждой есть один основной код: 6 — бюджет, 5 — неподходящий срок, 4 — неподходящий состав, 2 — выбран другой поставщик без установленного мотива, 3 — основная причина неизвестна.

Проверка: 6 + 5 + 4 + 2 + 3 = 20. Бюджет как основной код составляет 6 / 20 = 30%, неизвестная основная причина — 3 / 20 = 15%. Для этих процентов не нужны дополнительные строки на каждого участника сделки.

Затем команда отдельно размечает все упомянутые темы. Бюджет есть в 9 сделках, срок — в 8, состав — в 6, выбор другого поставщика — в 2. Получается 25 отметок на те же 20 сделок. Сумма долей по темам равна 125%; это допустимо только для отчёта с пересекающимися признаками, а не для распределения основных причин.

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

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

Проверьте классификатор до массового заполнения

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

Не делайте список ни чрезмерно общим, ни состоящим из десятков почти одинаковых вариантов. Код должен вести к разбору возможного действия: состав предложения, время исполнения, подходящий сегмент или полнота контакта. Наличие кода не устанавливает причину автоматически; подтверждение остаётся в исходной записи.

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

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

Сохраните историю при исправлении и повторном открытии

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

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

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

Границы сравнения суммы между срезами разобраны в сверке снимков воронки. Словарь причин отвечает за содержание классификации, а не заменяет эту сверку.

Приёмочные проверки и решение

1. Молчание клиента сохраняет неизвестный мотив, если других данных нет.
2. Прямое сообщение и предположение сотрудника различимы в выгрузке.
3. Один основной код на каждую из 20 сделок даёт итог 20.
4. 25 тематических отметок не превращаются в 25 проигранных сделок.
5. В сводке цены видны шесть подтверждённых клиентом случаев и три гипотезы.
6. Смена классификатора сохраняет неразделимую историческую категорию.
7. Новая информация имеет дату и не переписывает прежний срез незаметно.
8. Повторное открытие и повторное закрытие проверены на выбранной единице счёта.

Для SABSUS обсудите поля и причины результата в CRM и источники показателей. Происхождение объяснения, версии классификатора и правила пересекающихся тем нужно подтвердить в вашей конфигурации.

Прежде чем менять цену или работу команды, отделите подтверждённое объяснение от гипотезы и проверьте, что складывается в итог отчёта. Хорошая сводка оставляет неизвестное видимым и ведёт к проверке конкретных сделок, а не объявляет каждый выбранный код доказанной причиной.

Источники

• HubSpot: свойства сделки и Closed lost reason.
• HubSpot: отчёт Deal loss reasons.
• Microsoft Dynamics 365: запись завершения opportunity.

Источники проверены 11 октября 2026 года. Числа и словарь причин учебные. Описанный порядок является редакционной моделью управленческого анализа, а не результатом клиента или гарантией встроенной функции.