Как сравнить две CRM-механики с разной скоростью отдачи

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

Для сопоставления нужны одинаковая задача, общая временная ось и затраты в сопоставимом составе. Дисконтирование переводит будущие денежные поступления и выплаты в стоимость на одну дату. NPV, или чистая приведённая стоимость, — сумма таких потоков с учётом первоначальных вложений. OpenStax объясняет, почему этот показатель дополняет простой срок окупаемости.

Начните с общего основания

Укажите, для какой аудитории доступны оба варианта. Если одна механика работает на миллионной базе, а другая — на тысяче новых клиентов, одной доходности на человека для выбора портфеля недостаточно. Нужны и удельный результат, и достижимый общий масштаб.

Зафиксируйте срок наблюдения, полный состав переменных расходов и затраты запуска. Расходы на уже существующую платформу могут быть общими для обоих вариантов, а новая интеграция — возникать только в одном. Для выбора следующего действия важна именно эта разница.

Покажите временную траекторию

Условный пример. Две механики требуют по 100 000 рублей запуска. Ниже — предполагаемые дополнительные денежные потоки после переменных расходов на одной и той же аудитории. Поступления считаются в конце месяца.

При условной ставке 1% в месяц NPV А составит около 28 700 рублей, Б — около 56 500. У Б больше расчётная ценность, но позже окупаемость и выше зависимость от ещё не подтверждённых поступлений.

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

Сравнивайте одинаковую степень зрелости

У быстрой механики результат может уже наблюдаться, а у медленной — быть целиком прогнозным. Разместите факт и прогноз раздельно. Не складывайте их под заголовком «заработали».

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

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

Учтите ограничения команды и клиентского пути

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

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

Как принять решение

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

Решение может состоять в совместном запуске ограниченных пилотов, если аудитории и ресурсы позволяют корректное сравнение. Главное — заранее установить, какие данные подтвердят или изменят выбор, а не продлевать горизонт каждый раз, когда ожидаемая польза не появилась.

Источники

OpenStax. Net Present Value (NPV) Method. Principles of Finance, раздел 16.2. 2022.