Кейс RUTUBE Studio

Уменьшение времени обработки заявки на монетизацию, минимизация модерирования и переезд на новую ДС

Роль

Старший продуктовый дизайнер

Команда

Задача

Снизить время обработки заявки, мигрировать на новую дизайн-систему

Результаты

21 → 3 дня обработка заявки
+7 п.п. сквозной конверсии сценария (34% → 41%)
−15 п.п. отказов
UMUX: 96% (n=150, активные пользователи)

Для подключения монетизации на RUTUBE, пользователь подаёт заявку в Студии автора

Нагрузка на процесс подачи заявки резко увеличилась, время обработки выросло до 3–4 недель, угрожая расти дальше. Оунер сказала мне подумать, что предпринять для ускорения процесса, совместив с переездом на новую ДС.

Свежих исследований в архиве не было, провёл ~10 интервью с активированными авторами, обсуждая как они подавали заявку + провёл их по интерактивному прототипу текущего флоу.

Проблемы

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

Интересный инсайт

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

При этом 88% аудитории — самозанятые с уже существующими где‑то данными, но продукт заставляет их проходить ручной сценарий, создавая лишнее трение и нагрузку на модерацию.

Автоматизация данных и сокращение ручных действий — главный драйвер роста конверсии и масштабируемости

Критические шаги (например, создание кошелька) должны происходить в начале сценария, пока пользователь ещё вовлечён

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

Выбраны Госуслуги в ходе бенчмаркинга и составления сравнительной таблицы.

Перенеся создание кошелька в начало сценария, в несколько раз снизил отказы на этом шаге (по результатам интервью).

Добавил сущность черновика заявки, теперь автор может продолжать подачу заявки с того шага, где он ранее прервал сессию

Ручная подача осталась как fallback-сценарий, но преобразовалась, разбившись на шаги В будущем я масштабировал это на все типы авторов (ФЛ, СМЗ, ИП, юрлица).

По ходу работы обкатал новые процессы взаимодействия с разработкой и командой ДС по доработке новой дизайн-системы.

Финальный результат

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

Добавил корнер-кейсы решаемые раньше через поддержку: смена личных данных, их недостаточность, неактуальность, ошибочность и тд.

Результаты

+7 п.п.

34%→41% сквозной конверсии сценария подачи заявки

21→3 дня

среднее время обработки одной заявки модераторами

−15 п.п.

отказов на всем протяжении сценария, включая ручную подачу

Сценарий монетизации был узким горлышком роста: ручной ввод данных и модерация ограничивали масштабирование и замедляли активацию авторов.

Монетизация в creator-платформах — это не просто функция, а момент активации экономики платформы.

Пользователь начинает зарабатывать → становится мотивирован создавать больше контента → растёт supply → растёт удержание аудитории → растёт выручка платформы.

Мы не просто улучшили форму заявки — мы ускорили превращение пользователя в зарабатывающего автора и убрали операционные ограничения роста продукта. Стоимость обработки одной заявки уменьшилась на 30%.

Отмечу высокую оценку UMUX–96%, опрос проводился среди 150 активных авторов.

В процессе работы было создано около 40 тикетов на доработку компонентов дизайн-системы, часть локальных компонентов собирал сам.