Как PDP сохраняет удалённые сделки для аналитики отказов

Для PDP сделали мягкое удаление сделок: менеджер выбирает одну из 13 причин отказа, а продажа уходит из рабочей воронки, оставаясь в аналитике.

Со стороны пользователя это выглядит как обычное действие в CRM. Сделка больше не актуальна: клиент передумал, срок истёк, объект не подходит, ипотека не проходит по условиям. Менеджер нажимает удаление, но система не даёт закрыть окно пустым кликом. Нужно указать причину.

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

Удалить из работы, но не из истории

Физическое удаление сделки здесь ломало бы сразу две вещи: историю продаж и аналитику отказов. Поэтому сделали soft delete.

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

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

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

Почему причина обязательная

Главное решение было не в самой кнопке удаления. Кнопку добавить проще, чем договориться о данных, которые потом не придётся чистить руками.

Мы зафиксировали обязательность причины при soft delete. Без выбранного варианта сделка не закрывается. Да, это добавляет один шаг для менеджера. Зато аналитика не превращается в набор пустых значений.

Живая деталь проекта: больше всего вопросов вызвал не список из 13 причин, а граница между «истёк срок» и отказом клиента. На экране для пользователя это одна минута работы, а в отчётах это разные причины потери: процессная и коммерческая. Поэтому варианты оставили предопределёнными, без поля «напишите как-нибудь сами».

Компромисс простой: справочник закрывает основные причины, которые нужны для разрезов по воронке. Если бизнес-процесс поменяется, список можно расширять осознанно, а не вытаскивать смысл из произвольных комментариев.

Как это связано с циклом сделки

В PDP сделка проходит понятный маршрут: создание → выставление счёта → ожидание → подтверждение → истечение. Soft delete пришлось вписать в этот цикл так, чтобы удаление не маскировало состояние.

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

Поэтому soft delete не заменяет статусы жизненного цикла. Он дополняет их признаком закрытия и причиной отказа. Так можно отделять техническое состояние сделки от бизнес-причины, по которой она перестала двигаться дальше.

На практике это даёт базу для вопросов, которые раньше обычно разбирают по ощущениям:

• на каком этапе чаще всего теряются сделки;
• какие причины отказов повторяются;
• какие причины связаны с условиями продукта, а какие — с процессом продаж;
• где нужна доработка сценария: счёт, ожидание, подтверждение или обработка истечения.

Удалённая сделка теперь не пропадает из системы. Она перестаёт шуметь в операционной работе и остаётся пригодной для разбора воронки.