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

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

Начните со счёта и причины отказа

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

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

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

СостояниеЧто делает системаЧто объясняет сообщение
Повтор допустим без действий клиентаПланирует попытку по правилам биллингаКогда ожидается списание и где проверить статус
Требуется действие клиентаПредлагает безопасную страницу оплаты или обновления данныхКакой шаг нужен и до какого срока доступ сохранится
Есть обращение о спорном списанииПередаёт случай ответственному сотрудникуКто разбирает обращение; обычные напоминания приостанавливаются
Счёт уже оплачен или аннулированЗакрывает эпизодПодтверждает актуальный результат, если подтверждение необходимо

Согласуйте деньги, доступ и сообщения

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

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

Текст первого сообщения должен отвечать на четыре вопроса: какой платёж не прошёл, что произойдёт дальше, нужно ли действие клиента и куда обратиться. Если причина достоверно неизвестна, пишите «Не удалось провести оплату», а не «На вашей карте недостаточно денег». Ссылку ведите на защищённую страницу своего сервиса или платёжного провайдера с проверкой получателя.

Проверяйте состояние непосредственно перед отправкой

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

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

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

Измеряйте восстановление на одинаковом горизонте

Условный пример. Из 1 000 счетов с первой неуспешной попыткой 700 оплачены в течение 14 дней. Доля восстановления — 70%. Один счёт считается один раз независимо от числа попыток и писем. Это результат всего процесса, включая самостоятельные действия клиентов и работу платёжной системы.

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

Практическая схема CRM Lab связывает три объекта: неоплаченный счёт, допустимое следующее действие и актуальное состояние доступа. Пока эта связь не работает, увеличение числа напоминаний лишь масштабирует ошибки.

Источники

Stripe. Automate payment retries. Stripe Documentation. Проверено 23.09.2026.