Как снизить RTO при наложенном платеже: практичные UI и backend правила, OTP и WhatsApp подтверждение, валидация адреса и фильтры риска без просадки конверсии.
RTO (returns to origin) - это когда посылку не выкупают, и она едет обратно на склад или отправителю. При наложенном платеже RTO обычно выше: у клиента нет финансового обязательства до момента получения. Отказ обходится дешево - можно передумать, не взять трубку или просто не прийти в пункт выдачи.
Причины у наложенного платежа часто смешиваются, но удобнее разделять их по типам. Бывает фрод (заказы ради вреда магазину, тестирования доставки или с чужими данными), бывают импульсные покупки, ошибки в контактах и адресе, недоступность клиента, а также завышенные ожидания (сроки и стоимость доставки оказались не такими, как человек думал).
Дальше возникает конфликт целей. Чтобы снизить RTO, хочется добавить проверки и подтверждения. Но каждый лишний шаг в чекауте снижает конверсию.
Практичный компромисс: для всех оставить мягкие улучшения (очистка телефона, подсказки адреса, понятные сроки), а жесткие проверки включать только для рискованных заказов. Например, при дорогой корзине, подозрительных повторах, частых отказах или явных несовпадениях данных.
Сначала договоритесь о единой воронке и правилах подсчета. Иначе вы внедрите OTP или подтверждение в мессенджере, а потом будете спорить, стало ли лучше.
Зафиксируйте события по каждому заказу. Минимально достаточно цепочки: заказ создан - заказ подтвержден (каким способом и с какой попытки) - передан в доставку - попытка вручения (успех или неуспех и причина) - возврат на склад/в магазин (RTO).
Дальше сравнивайте метрики на одинаковых периодах (например, 2 недели до и 2 недели после, без крупных распродаж). Основные показатели: доля RTO, подтверждаемость (сколько заказов дошло до статуса "подтвержден"), доля подозрительных заказов по вашим правилам и конверсия чекаута (созданные заказы / начавшие оформление).
Чтобы случайно не "улучшить" RTO ценой потери продаж, сегментируйте отчеты. Обычно хватает разрезов по новым и постоянным покупателям, по городам (крупные и регионы), по стоимости корзины и по категориям товаров (дорогие, хрупкие, популярные).
Пороги и целевые значения задайте заранее. Например: для новых клиентов с дорогой корзиной подтверждение обязательно; для повторных клиентов с низким RTO контроль минимальный; для городов или ПВЗ с высоким RTO проверки усиливаются. Если после изменений растут отказы в чекауте больше чем на 1-2 п.п., шаг стоит откатить или упростить. Если подтверждаемость ниже ожиданий, обычно помогает настройка текста, тайминга и канала, а не попытка "дожимать" силой.
Так вы увидите не только снижение RTO, но и цену этого снижения в конверсии.
Задача простая: снизить возвраты, не превращая чекаут в препятствие для всех. Контроль включается только там, где он реально отсекает фрод и снижает RTO.
Начните с простого скоринга, который легко объяснить и поддерживать. Обычно хватает 4-5 сигналов: первый заказ или нет подтвержденной истории; сумма заметно выше среднего чека (например, x2); частые отмены или недозвоны в прошлом; подозрительные адреса (много заказов на один подъезд, "квартира 0", странные комментарии); несоответствия в данных (город и индекс, имя и телефон, повторяющиеся номера на разные имена).
Дальше назначьте действия по уровню риска и повышайте "трение" ступенчато.
Чтобы не скатиться в дискриминацию, делайте правила "про поведение, а не про человека". Не используйте чувствительные признаки и избегайте необъяснимых "черных списков". Клиенту лучше показывать нейтральную причину: "Нужно быстро подтвердить заказ, чтобы мы успели передать его в доставку". И обязательно оставляйте быстрый способ подтверждения: один код или одна кнопка.
Чем раньше вы объясните, зачем нужно подтверждение, тем меньше отказов. В чекауте и так хватает напряжения (цена, доставка, оплата), поэтому подтверждение должно выглядеть как помощь, а не как проверка.
Начните с телефона. Маска ввода +7 и автоподстановка кода страны снижают ошибки. Сразу проверяйте длину и формат, но показывайте нормальную подсказку, а не "красный крест": "Нужен номер для курьера и подтверждения, чтобы заказ не задержался".
Микротекст рядом с выбором канала решает половину проблем: "Подтвердим заказ сообщением за 10 секунд. Это ускорит отправку и снижает риск возврата". Слово "антифрод" в интерфейсе обычно только пугает.
По моменту часто меньше трения, если просить подтверждение сразу после нажатия "Оформить заказ" - отдельным коротким шагом с таймером и кнопкой "Отправить код еще раз". Если требовать подтверждение до выбора доставки, часть людей отвалится раньше.
Не делайте тупик, если человеку неудобен один канал. Обычно достаточно 2-3 вариантов: WhatsApp, SMS с кодом и короткий звонок-бот. Email лучше оставлять только для низкого риска.
Пример: покупатель выбирает наложенный платеж и доставку курьером. После оформления появляется шаг "Подтвердите номер, чтобы курьер смог связаться". Клиент подтверждает в WhatsApp одной кнопкой, и заказ уходит в сборку.
OTP (код из SMS) лучше включать не для всех, а там, где риск выше. Тогда вы снижаете RTO и не режете конверсию.
Когда делать OTP обязательным: первый заказ на номер; сумма выше вашего порога; частые отмены по этому телефону; много попыток оформить на похожие адреса; несостыковки в данных (например, регион и индекс не совпадают). Для постоянных клиентов без проблем OTP лучше пропускать.
Короткий шаг после ввода телефона работает лучше всего: "Подтвердите номер, чтобы курьер смог связаться". После успешного кода зафиксируйте два факта: номер подтвержден и клиент согласился с условиями получения (например, что выдача происходит при оплате и предъявлении телефона). Это помогает в спорных ситуациях.
На бэкенде держите простые ограничения: TTL кода 2-5 минут, до 3 попыток ввода; повторная отправка через 30-60 секунд (и тоже с лимитом); защита от перебора (блок на 15-30 минут при серии ошибок); привязка OTP к сессии и корзине; логирование причины, почему OTP был показан (чтобы настраивать правила по данным).
Не оставляйте клиента в тупике. Дайте "подтвердить позже" (заказ уходит в статус "ожидает подтверждения") и запасные каналы: звонок оператором или короткий диалог в мессенджере. Если SMS доставляется плохо, часто выручает сообщение с просьбой ответить "Да, подтверждаю" и быстрой сверкой адреса перед передачей в доставку.
Звонки по наложенному платежу часто игнорируют, а оператор тратит время. WhatsApp обычно работает лучше: человек видит текст, отвечает когда удобно, а у вас остается понятный след согласия.
Сообщение должно быть коротким и сводиться к одному действию. Хороший формат - две кнопки: "Да, подтверждаю" и "Изменить".
Пример шаблона: "Ваш заказ №1234: 2 товара, сумма 3 490 ₽, оплата при получении. Доставка: ул. Ленина 10, кв. 45, завтра 18:00-21:00. Подтвердите: Да / Изменить". Если клиент выбирает "Изменить", задайте один вопрос: "Что поправить - адрес или время?"
Подтверждать стоит то, что чаще всего приводит к возвратам: состав (чтобы не было сюрпризов), адрес (включая квартиру/офис), интервал доставки и факт "оплата при получении". Для адресных ошибок удобно сразу попросить детали: подъезд, этаж, домофон. Для частного сектора и новых ЖК - ориентир или геометка.
Важно не только получить "Да", но и нормально зафиксировать результат в системе. Для поддержки и курьеров обычно хватает: статуса (подтверждено/на уточнении/нет ответа), времени и канала, текста последнего сообщения, кто подтвердил (номер, имя из профиля, оператор или бот), что было изменено.
Если ответа нет, задайте понятный тайминг: напоминание через 15 минут, затем перевод на звонок или автоотмену по правилам риска.
Много RTO происходит не из-за фрода, а из-за банальных ошибок: "ул. Ленина" без дома, перепутанный корпус, мусор в поле, адрес одной строкой, который курьер читает на ходу. Адресная валидация снижает возвраты и почти не бьет по конверсии, если делать ее мягко.
Начните с автоподсказок и нормализации. Дайте человеку вводить адрес привычно, но храните его структурированно: город, улица, дом, корпус, квартира. Показывайте пример формата прямо в поле и подсказывайте, чего не хватает.
В форме достаточно простых правил: обязательные город, улица и дом (квартира по ситуации); минимальная длина, чтобы отсечь "-" и "нет"; запрет явного мусора (одни пробелы, повторяющиеся символы); подсказки вместо грубых ошибок; нормализация сокращений ("к" -> "корпус", "д" -> "дом") без придирок к регистру.
Отдельно ловите аномалии на бэкенде: слишком общие адреса ("частный дом", "напротив ТЦ"), строка без цифр, одинаковые шаблоны в десятках заказов, несоответствие города выбранному региону доставки.
Если адрес сомнительный, не тормозите всех подряд. Вынесите такие заказы в поток уточнения до отгрузки: один короткий вопрос, 2-3 быстрых варианта (дом, корпус, подъезд) и понятный срок ожидания.
Пример: клиент пишет "Казань, рядом с парком Горького". Форма пропускает, но бэкенд отмечает адрес как слишком общий и просит уточнить дом и подъезд. Заказ подтверждается за 2 минуты, а не возвращается через неделю.
Самый заметный эффект обычно дает не один фильтр, а набор простых проверок до передачи заказа в доставку.
Начните с лимитов на повторные COD-заказы. Если телефон еще не подтвержден (OTP, WhatsApp или звонок), держите потолок на количество активных заказов и попыток оформления за короткое время. Это режет массовые фейковые заявки и почти не трогает нормальных покупателей.
Вторая опора - дедупликация. Смотрите не только на телефон, но и на совпадения по адресу, получателю, составу корзины и времени. Типичный сигнал: одинаковая корзина оформляется 3-5 раз за 10 минут, меняется только комментарий или квартира. Такие заказы лучше отправлять на подтверждение, а не блокировать сразу.
Полезный минимум проверок: частота заказов по телефону и устройству (хотя бы user-agent + cookies); совпадения адреса и получателя с уже отмененными или "невыкупленными" заказами; повторяющиеся шаблоны (разные имена, но один и тот же пункт/улица); "серые" признаки вроде частых правок адреса после оформления или разных телефонов на один адрес.
Если используете списки, разделяйте их по смыслу. Черный - для явного фрода и прямой блокировки. Серый - для отправки в подтверждение, где может потребоваться депозит или ручная проверка.
И обязательно ведите логи. Храните причину решения (какое правило сработало), сырой и нормализованный адрес, историю статусов, попытки подтверждения и итог (выкуп или возврат). Тогда спорные случаи разбираются спокойно, а правила улучшаются на фактах.
Предоплата помогает, когда риск действительно высокий: дорогая доставка, тяжелый товар, удаленный регион, частые отказы по направлению или явные признаки подозрительного поведения. Но если требовать деньги со всех, вы получите меньше заказов и больше брошенных корзин.
Чаще всего лучше работает мягкий депозит. Он отсекает случайные заказы, но меньше пугает нормальных покупателей.
Варианты депозита могут быть разными: символическая сумма для подтверждения намерения; оплата доставки заранее, а товар - при получении; депозит с вычетом из суммы при выдаче; предоплата только для товаров с дорогой обратной логистикой; предоплата только для новых клиентов с высоким риском.
Объяснение должно быть честным и коротким: "Чтобы закрепить доставку на этот адрес, просим оплатить доставку заранее. Остальное - при получении". Если обещаете возврат оплаты при несостоявшейся доставке по вашей вине, это условие должно быть реальным и одинаковым для поддержки.
Если клиент не готов, не закрывайте ему дверь. Вместо тупика предложите альтернативу: другой способ доставки, самовывоз или подтверждение через мессенджер/звонок. Иногда достаточно убрать дорогие опции (экспресс, дальние зоны) и попросить перепроверить адрес и телефон.
Даже хорошие правила не дадут эффекта без понятного процесса: что считается подтверждением, сколько вы ждете, когда прекращаете попытки. Это должно одинаково пониматься и поддержкой, и логистикой.
Сделайте простую лестницу статусов и зафиксируйте сроки. Например: "Новый (ожидает подтверждения)" - 30-60 минут на первое касание; "Подтвержден" - можно передавать в сборку и доставку; "Требует уточнения" (адрес/время) - до 24 часов, иначе отмена или перенос; "Не подтвержден" (таймаут) - автоотмена или перевод на предоплату по правилам риска; дальше финальные исходы: "В доставке", "Доставлен", "RTO".
В наложенном платеже обычно выгоднее быстрее закрывать неподтвержденные заказы, чем кормить ими склад и курьеров.
Повторные попытки делайте по одному сценарию, чтобы не спамить и не терять клиентов. Пример: сразу WhatsApp с кнопками "Да, жду" / "Изменить"; через 30-60 минут SMS; через 3-6 часов звонок только для дорогих или высокорисковых заказов; на следующее утро финальное сообщение, затем автодействие.
Курьеру и диспетчеру отдавайте минимум: подтверждено (да/нет), комментарий по адресу (подъезд, домофон, ориентир), окно доставки. Если заказ не подтвержден, не отправляйте его "на авось".
После RTO фиксируйте причину понятными кодами (не вышли на связь, неверный адрес, отказ при получении, перенос клиентом). Раз в неделю смотрите топ причин и корректируйте правила: где добавить уточнение адреса, где сократить тайминги, а где убрать лишний контроль.
Самая частая ошибка - включить жесткое подтверждение для всех. Если требовать OTP на чекауте у каждого клиента, вы защититесь от части фрода, но получите падение конверсии, особенно у новых пользователей.
Вторая ошибка - проверять молча. Когда человек не понимает, зачем ему код или подтверждение в WhatsApp, он воспринимает это как подозрение или бюрократию и закрывает страницу. Одна короткая фраза вроде "это нужно, чтобы курьер быстрее нашел вас и мы не отправляли заказ зря" часто снимает напряжение.
Третья ошибка - проверки есть, но у них нет нормальной жизни в системе: код отправили, клиент ввел, оператор написал, но статусы не фиксируются. Поддержка не понимает, можно ли отдавать заказ в отгрузку, и либо делает лишние звонки, либо пропускает риск.
Четвертая ошибка - нет сценария исправления. Пользователь ошибся в номере, не получил SMS, указал адрес без квартиры и видит только "ошибка". Правильнее дать понятный путь: исправить данные, выбрать другой канал, получить помощь.
Перед выкладкой на весь трафик проверьте базу: статусы заказа и доставки должны быть однозначными; OTP включается только там, где снижает риск; адресные проверки ловят ошибки до передачи в доставку; сценарий WhatsApp короткий и понятный.
Перед релизом полезно пройтись по списку: таймауты и лимиты (сколько ждать подтверждение, сколько попыток OTP, когда прекращать попытки); дедупликация (не отправлять два OTP или два сообщения при обновлении страницы); логирование причин (почему заказ ушел в проверку, почему отменен); сценарии по типам клиентов (новый, постоянный, высокий чек, сомнительный адрес); план A/B (что сравниваете: RTO, отмены до отгрузки, конверсию в выкуп, время до подтверждения и какой порог считаете успехом).
Новый покупатель оформляет заказ с наложенным платежом. Корзина обычная, но в адресе ошибка: вместо "корпус 2" написано "корп. 22". Если отправить заказ сразу, курьер упрется в неверный дом, и посылка почти гарантированно уедет обратно.
После оформления срабатывает мягкое правило: для новых клиентов на наложенном платеже включается короткое подтверждение. Покупатель получает сообщение в WhatsApp с простым запросом: "Проверьте адрес доставки: улица, дом, корпус, подъезд". Он отвечает: "Корпус 2, а не 22". Оператор (или бот) обновляет адрес, фиксирует уточнение и просит подтвердить готовность принять доставку.
Дальше, перед передачей в службу доставки, отправляется OTP. Покупатель вводит код, заказ получает статус "подтвержден", и риск RTO резко падает.
Чтобы это работало стабильно, сохраните в заказе несколько полей: риск-метку (например, new_cod + address_fix), причину уточнения (корпус/подъезд/домофон), кто и когда изменил адрес, итог подтверждения (WhatsApp ok, OTP ok), финальный статус доставки (доставлено/RTO).
Начните с карты процесса: какие каналы подтверждения вам реально нужны (SMS OTP, WhatsApp, звонок как запасной вариант) и какие статусы должны жить в заказе, чтобы команда понимала, что делать дальше.
Соберите минимальный набор статусов, который виден и в админке, и в логах: "Ожидает подтверждения", "Подтвержден", "Не подтвержден" (таймаут), "Требует уточнения" (адрес, время, получатель), "Передан в доставку".
Дальше включайте контроль только там, где он окупается. На первом этапе оставьте обычный чекаут для низкорисковых заказов (постоянные клиенты, небольшая сумма, знакомый район), а подтверждение включите для сегментов риска: первый заказ, высокая сумма, подозрительные совпадения телефона и адреса, частые отмены.
Всегда держите рядом две метрики: RTO и конверсию в выкуп. Если RTO падает, но конверсия заметно проседает, ослабьте триггеры или упростите шаг (например, WhatsApp вместо звонка, меньше полей, понятнее текст).
Пересматривайте правила по данным раз в 1-2 недели и меняйте по одному параметру за раз (порог суммы, таймаут подтверждения), чтобы понимать, что именно дало эффект.
Если нужно быстро собрать такой поток без долгой разработки, прототип UI и бэкенд-логику можно собрать в TakProsto (takprosto.ai) через чат, обкатать на части трафика, а затем при необходимости экспортировать исходники и перенести в основной контур.
Лучший способ понять возможности ТакПросто — попробовать самому.
