Разбор проигранной сделки нейросеть делает быстро, если под рукой уже есть переписка и заметки в CRM: модель ищет закономерность, сравнивая сделку с несколькими похожими вместо разбора в одиночку — так видно, случайность это или системная проблема отдела.
Когда разбирать
Разбор одной проигранной сделки занимает пятнадцать-тридцать минут вместе с чтением вывода модели. Модель ищет закономерность, сравнивая несколько похожих потерь сразу вместо одной изолированной сделки, — так виден системный сбой вместо случайного совпадения.
Разбор стоит проводить регулярно — раз в одну-две недели по всем проигранным сделкам сразу, пока детали ещё свежи в переписке и памяти менеджера, вместо того чтобы копить их до конца квартала.
Небольшие сделки стоит разбирать наравне с крупными потерями, которые сразу обсуждают на планёрке, — закономерность часто виднее именно на потоке мелких и средних сделок, где менеджер редко успевает вдумчиво анализировать каждую по отдельности.
Отдельно стоит включать в разбор сделки, где клиент вернулся к конкуренту после пробного периода, — там причина потери часто отличается от причин обычного отказа на этапе переговоров и требует своей отдельной категории в общем списке.
Категории причин
| Причина | Типичный маркер в переписке | Что проверить дальше |
|---|---|---|
| Цена | Клиент сравнивает предложение с более дешёвым вариантом | Сверить с фактическим прайсом конкурента, если он назван |
| Сроки | Клиент упоминает дедлайн раньше готовности отдела | Проверить реальный запас времени в процессе согласования |
| Конкурент | Прямое упоминание названия другого поставщика | Сравнить набор аргументов конкурента с реальным УТП компании |
| Нет потребности | Переписка обрывается без явного отказа | Уточнить у менеджера, было ли обращение изначально целевым |
| Смена решающего лица | В диалоге меняется контактное лицо ближе к финалу | Проверить, успели ли донести ценность до нового человека |
Одна и та же переписка иногда несёт признаки сразу двух категорий — например, смену контактного лица и упоминание цены одновременно; модель стоит просить называть основную причину и вторичную отдельно вместо одного общего ярлыка.
Ещё одна категория, которую легко упустить в списке из пяти, — внутренняя задержка на стороне компании: сделка стоит без движения неделями из-за долгого согласования условий внутри самого отдела продаж или юридической службы, хотя формально выглядит как задержка на стороне клиента.
Список из пяти категорий стоит держать общим для всего отдела и время от времени пересматривать вместе с командой — рынок и продукт меняются, и через полгода на первое место может выйти причина, отсутствовавшая в списке ещё год назад, например конкретная новая интеграция у конкурента.
Что давать модели
- Все сообщения переписки с клиентом по сделке — от первого контакта до финального ответа.
- Запись или расшифровку звонков, если они велись.
- Историю изменений сделки в CRM — этапы, даты, кто менял стадию.
- Финальный комментарий менеджера о причине потери своими словами.
Хороший промпт для разбора называет продукт или услугу, сумму сделки, весь текст переписки целиком и прямой вопрос: какая причина потери основная, а какая вторичная, с цитатой из переписки в подтверждение каждой.
Если сделка велась в нескольких каналах сразу — почта, мессенджер, звонки — стоит сводить всё в один документ перед отправкой модели: разрозненные фрагменты по разным каналам мешают ей увидеть полную хронологию событий и точный момент, когда переговоры свернули в сторону.
Полезно также прикладывать финальное коммерческое предложение, которое видел клиент, — часто причина потери прячется именно в разнице между тем, что обсуждали устно, и тем, что в итоге оказалось на бумаге в цифрах и условиях.
Модели для разбора
Для разбора одной длинной сделки с большим объёмом переписки и звонков лучше подходят Claude или ChatGPT — они точнее удерживают контекст всего диалога и находят причину потери на основе множества разрозненных сообщений вместо одной последней реплики.
Для еженедельного разбора сразу двадцати-тридцати сделок практичнее GigaChat или YandexGPT — они быстрее и дешевле обрабатывают короткие типовые сделки, где переписки немного, а закономерность важнее глубины отдельного случая.
- Совпадает ли причина, которую назвала модель, с тем, что менеджер помнит по факту разговоров.
- Отличается ли реальная причина потери от формальной отговорки клиента, которую модель могла принять за чистую монету.
- Есть ли в выводе модели цитата из переписки, подтверждающая названную причину.
- Стоит ли переносить вывод конкретной сделки на весь сегмент клиентов или это единичный случай.
Настроить регулярный разбор проигранных сделок?
Отдельный практический приём — просить модель сравнить формулировку причины потери с формулировками по трём-четырём похожим сделкам за последний квартал: повторяющаяся причина у разных менеджеров и разных клиентов почти всегда указывает на системную проблему продукта, цены или процесса вместо случайного совпадения обстоятельств.
По прайсам сервисов на сентябрь 2026 разбор одной сделки через любую из перечисленных моделей обходится в символическую сумму по токенам — основные затраты здесь приходятся на время менеджера при сборе всей переписки в одном месте перед отправкой, а цена самой модели остаётся почти незаметной.
Граница ответственности
По нашему опыту внедрений разбор одной сделки занимает пятнадцать-тридцать минут вместе с чтением вывода модели, а еженедельный разбор всех проигранных сделок отдела — около часа при потоке в пять-семь сделок.
Вот конкретная деталь, которую легко проглядеть: модель называет причиной потери цену, хотя переговоры на самом деле зависли из-за смены контактного лица за неделю до отказа, а цена всплыла лишь как последний повод в разговоре. Отдел, поверивший выводу модели буквально, два месяца готовит скидочную программу вместо работы с реальной проблемой смены решающего лица.
Второй частый случай — разбор проводит только руководитель отдела без участия менеджера, который вёл сделку: вывод модели превращается в претензию к конкретному человеку вместо совместного поиска системной причины, и менеджер в следующий раз просто перестаёт делиться деталями честно.
Как обучить команду проверять такие выводы — в разделе про обучение сотрудников работе с ИИ.
Общий разбор пути сделки в B2B — в статье про ИИ в B2B-продажах. Где нейросети усиливают отдел продаж, а где мешают — в материале про нейросети для отдела продаж. Похожий разбор данных отдела — в статье про разбор недельного отчёта отдела.
Полезно фиксировать итог разбора коротким текстом в CRM рядом со сделкой вместо того, чтобы держать его только в голове менеджера, — через квартал накопленный набор таких заметок сам превращается в готовый материал для следующего большого разбора всего отдела.