Сценарии

Top-up failure recovery: вернуть клиента в момент сбоя

Клиент попытался пополнить счёт, платёж не прошёл. Без recovery — он попробует у конкурента или забудет. С recovery — оператор удерживает 30-50% таких случаев.

Обсудить задачу

Сценарий

Клиент в app оператора пытается пополнить счёт картой. Карта отклонена (insufficient funds, expired, 3DS timeout). Клиент видит ошибку, закрывает app.

В большинстве операторов на этом всё заканчивается. Failed payment — событие в логах биллинга, никто на него не реагирует. Через 2-3 часа клиент:

пополнит у конкурента (если сильно нужна связь),
купит ваучер в киоске (теряем comission digital канала),
забудет (теряем revenue).

При volume в десятки тысяч failed top-ups в день — это большая невидимая утечка.

Триггер

Событие в payment processor: payment.failed с reason code, amount, customer_id, channel.

Подписан consumer в decisioning слое. Не каждое failure заслуживает действия — фильтр:

amount выше пороговый (>10k UZS),
клиент с предыдущим successful top-up (не первый раз),
failure reason recoverable (не fraud, не permanent decline).

Действие

Window действий: 5-15 минут после failure.

Вариант A: instant in-app banner. «Платёж не прошёл — попробуйте другой способ». Кнопка → выбор alternative payment (другая карта, кошелёк, USSD).

Вариант B: push (если app закрыт). Лаконично: «Не получилось пополнить — есть 3 варианта».

Вариант C: SMS (если push отключен или не доставлен через 5 мин). С короткой ссылкой на recovery flow.

Channel выбирается по preference + last open + failure mode.

Alternative payment options

Часто failure mode подсказывает alternative. Card declined → предложить wallet или USSD. 3DS timeout → retry с другой картой. Insufficient funds → предложить меньшую сумму с возможностью допополнения.

Что меряется

Recovery rate — какая доля failed top-ups завершилась successful payment в течение 24 часов.

Recovery channel mix — что сработало (in-app, push, SMS, USSD).

Time to recovery — от failure до successful payment.

Customer satisfaction — короткий survey после recovery.

Что не делать

Не отправлять recovery message через 24 часа — поздно, клиент уже решил иначе.

Не предлагать только повторить ту же карту — велик шанс повторного отказа.

Не bombard клиента 5 channels одновременно — выбрать один best channel.

Не забывать про consent — recovery — это transactional, но границы с marketing размытые.

Как SamaraliSoft подключается

Sprint Recovery Use Case — 4-6 недель. Анализ current failed top-ups, дизайн trigger logic, channel orchestration, recovery UX. Pilot на 30-60 дней с измерением recovery rate.