Возврат билетов: один вход вместо писем в поддержку
Вместо двух разрозненных путей и ручной переписки с поддержкой я собрала возврат в единый сценарий: система проверяет условия заказа, показывает сумму и ведёт пользователя по нужному пути без лишних обращений
Контекст
На старом сайте сценарий был разорван:
- автовозврат находился в личном кабинете;
- ручной возврат был спрятан в правилах;
- форма ручного возврата была поп-апом со списком документов, которые нужно было вручную отправить на email поддержки
Возврат билетов — тревожный денежный сценарий. Пользователь хочет быстро понять: можно ли вернуть билет, сколько денег вернётся, когда они придут и что делать дальше
Точка входа в возврат билетов на старой версии сайта (через футер)
Точка входа в ручной возврат на старой версии сайта (через правила возврата)
Проблема
Из-за этого росла нагрузка на поддержку:
- пользователи не понимали, где оформить ручной возврат;
- отправляли неполные документы;
- писали повторно, чтобы узнать статус или сроки;
- один возврат часто превращался в длинную переписку.
Пользователь должен был сам понять, какой тип возврата ему нужен. Но у него нет для этого данных: правила зависят от сроков до события, штрафов организатора, причины возврата, способа оплаты и статуса заказа.
Понять, доступен ли возврат
Когда я не могу пойти на событие,
я хочу быстро понять, можно ли вернуть билеты,
чтобы не искать правила и не писать в поддержку
я хочу быстро понять, можно ли вернуть билеты,
чтобы не искать правила и не писать в поддержку
Увидеть сумму до подтверждения
Когда возврат возможен,
я хочу заранее увидеть сумму, удержания и сроки,
чтобы принять решение до отправки заявки
я хочу заранее увидеть сумму, удержания и сроки,
чтобы принять решение до отправки заявки
Оформить ручной возврат без email
Когда мой случай требует проверки,
я хочу оформить заявку внутри сервиса и понять, какие документы нужны,
чтобы не собирать всё через письма и уточнения
я хочу оформить заявку внутри сервиса и понять, какие документы нужны,
чтобы не собирать всё через письма и уточнения
Понять, что будет дальше
Когда возврат или заявка уже отправлены,
я хочу понимать статус и следующий шаг,
чтобы не обращаться в поддержку повторно
я хочу понимать статус и следующий шаг,
чтобы не обращаться в поддержку повторно
JTBD-пользователя
Цели и критерии успеха
- снизить обращения в поддержку;
- уменьшить долю неполных заявок;
- стандартизировать ручные возвраты;
- повысить доверие в денежном сценарии
Для бизнеса было важно не просто добавить ещё одну форму, а снизить хаос вокруг возвратов: меньше ручных уточнений, меньше неполных обращений и больше прозрачности для пользователя.
Принцип решения, который я предложила: пользователь не должен разбираться в типах возврата. Это должна делать система
Гипотезы
№5
Объяснение отказа и следующий шаг снизят повторные обращения в поддержку
№4
Структурированная заявка вместо email уменьшит число неполных обращений
№1
Один вход снизит количество вопросов «где оформить возврат?»
№2
Автоматическая проверка условий быстрее приведёт пользователя в правильный сценарий.
№3
Показ суммы и удержаний до подтверждения снизит тревожность и вопросы про деньги
Метрики
Для оценки решения я заложила метрики, которые показывают, стал ли возврат понятнее для пользователя и менее затратным для поддержки
Доля возвратов без обращения в поддержку
Показывает, сколько пользователей смогли пройти возврат самостоятельно
Количество обращений в поддержку по возвратам
Показывает, снизилась ли нагрузка на команду поддержки
Доля заявок с полным комплектом документов
Показывает, стала ли ручная заявка понятнее и лучше структурирована
Время до отправки заявки
Показывает, насколько быстро пользователь проходит сценарий от входа до отправки возврата или ручной заявки
Решение
Я изменила логику сценария: вместо того чтобы добавлять ещё одну форму, собрала возврат в понятный процесс с проверками, объяснениями и следующим шагом для каждого случая
Один вход в возврат
Если пользователь не авторизован или пришёл из раздела помощи, он вводит номер заказа и email. Система проверяет данные и показывает понятную ошибку, если заказ не найден.
Вместо двух разных сценариев я предложила единый старт: пользователь начинает с возврата билетов, а дальше система сама проверяет заказ и условия.
Точка входа в возврат из личного кабинета
Дополнительная точка входа в возврат в вебвью билета
Возврат билетов для неавторизованных пользователей
Система выбирает подходящий путь
Логика строится вокруг условий:
- найден ли заказ;
- подходит ли он под автоматический возврат;
- сколько времени осталось до события;
- есть ли штраф от организатора;
- какая причина возврата;
- нужен ли ручной разбор или документы;
- есть ли ограничения по оплате.
Я выяснила, что часть решений можно принять автоматически: система заранее понимает, подходит ли заказ под автоматический возврат
Алгоритм распределения заказов на ручной и автоматический возврат
Автовозврат: деньги и условия до подтверждения
На экране он:
- выбирает билеты для возврата;
- может вернуть часть билетов из заказа;
- видит сумму к возврату;
- видит, что сервисный сбор не возвращается;
- видит штраф организатора, если он применим;
- понимает срок возврата денег на карту;
- подтверждает правила и отправляет возврат
Если заказ подходит под автоматический возврат, пользователь попадает в самый короткий сценарий
Автовозврат билетов
Причина возврата в зоне штрафа
Если причина уважительная, пользователь загружает документы, а организатор может принять решение о полном или частичном возврате. Если уважительной причины нет, применяется штраф по правилам организатора
Если до события осталось мало времени, сумма возврата может зависеть от причины. В этом случае система просит пользователя выбрать причину.
Автовозврат билетов со штрафом организатора
Ручной возврат как заявка внутри сервиса
Пользователь указывает контакты, выбирает причину и загружает нужные документы:
- заявление на возврат;
- билет;
- чек;
- подтверждающие документы, если причина требует доказательств
Раньше ручной возврат был фактически письмом в поддержку. Я перевела его в структурированную заявку
Заявка на возврат по уважительной причине (без штрафа)
Сервисная логика
Возврат затрагивает не только интерфейс. В процессе участвуют пользователь, билетная система, поддержка, организатор и банк
Возврат билетов — это не просто форма, а сложный сервисный сценарий
Результаты
Так как решение находится на этапе реализации, я сформулировала ожидаемый эффект через три группы: пользователь, поддержка и операционные процессы
Для пользователя
Единый вход и понятные условия должны снизить тревожность в сценарии: пользователь быстрее понимает, можно ли вернуть билеты, сколько денег вернётся и что делать дальше
Для поддержки
Структурированная заявка должна сократить количество повторных уточнений: вместо свободного письма поддержка получает причину возврата, контакты, билеты, чек и документы в одном формате
Автоматическая проверка условий отделяет простые возвраты от сложных случаев: автовозврат проходит без ручного участия, а спорные кейсы сразу попадают в заявку с нужными данными
Для команды
Что можно улучшать дальше
Основные направления развития:
- расширять правила автоматической проверки, чтобы больше простых возвратов проходили без поддержки;
- уточнять коммуникацию в сложных и спорных случаях, где решение зависит от организатора или внешней системы;
- анализировать обращения в поддержку и находить места, где пользователю не хватило информации;
- упрощать ручной путь там, где пользователь уже дал системе достаточно данных
Дальше я бы развивала сценарий не через добавление новых экранов, а через постепенное уточнение логики: какие решения система может принимать автоматически, где нужен человек, а где пользователю важно дать больше объяснений
