Как пересмотрев задачу,
я сделал ии-инстурмент
поддерживающий рост GMV
я сделал ии-инстурмент
поддерживающий рост GMV
Получайте несколько выгод с Яндекс Пэй
CPQR одно из самых перспективных
и амбициозных проектов Яндекс банка
CPQR - это QR-код, который содержит карту лояльности магазина и способ оплаты через Яндекс Пэй
Ценность для партнера
- Снижение стоимости приёма платежей — экономия на комиссии.
- Рост MAU приложения
- Рост Retention и частоты покупок
- Рост LTV
- Сокращение времени обслуживания
Ценность для компании
- Рост TPV
- Рост MAU Пэй
- Рост частоты транзакций
- Рост офлайн-покрытия
- Рост проникновения финансовых продуктов — больше пользователей подключают другие продукты экосистемы
Кратко о кейсе
Начав с задачи понятнее объяснить продукт партнёрам,
я выявил проблемы в подготовке интеграций и самостоятельно запустил решение для CPQR, Сплита и Пэй-виджета.
Одна из самых больших проблем команды, что партнеры неправильно внедряют наш продукт в своц интерфейс, отклняясь от рекомендованного флоу. Продукт заявляет,
что потеря GMV до 30% на одного партнера
я выявил проблемы в подготовке интеграций и самостоятельно запустил решение для CPQR, Сплита и Пэй-виджета.
Одна из самых больших проблем команды, что партнеры неправильно внедряют наш продукт в своц интерфейс, отклняясь от рекомендованного флоу. Продукт заявляет,
что потеря GMV до 30% на одного партнера
Бизнес-цель и исходная задача
Цель — поддержать рост GMV через качественные интеграции продукта в приложения партнёров. Отклонения от рекомендованного флоу снижают конверсию оплаты через CPQR
Команда предполагала, что более понятная демонстрация продукта, поможет партнёрам придерживаться рекомендованного флоу. Мне поручили создать интерактивный прототип
Итоговая проблема
Биздевы без участия дизайнеров делали дизайны нашего продукта напримере интерфейса партнера.
Почему это плохо:
Почему это плохо:
- Биздевы показывали варианты , которые отклонялись от рекомендованого флоу
- На одну такую задачу уходило примерно 75 минут, а если не успевали уходило в беклок
с нашей стороны
Что сделал
- Самостоятельно прошел весь путь(end to end) от постановки задачи до запуска решения
- Самостоятельно провел исследование, без содействия ресурсов компании
Результат
- Доказал проблему другим направлениям
- Снизилось количество беклогов у биздевов с 4 в месяц до двух
- Снижение времени биздева снизилась до 10 минут
- Качество CJM, которые присылают партнеры стало лучше
- Решение развернули до 3 продуктов
Почему исследование провёл я
Что требовалось проверить
- У команды не было единой и понятной воронки продаж
- Дизайн и продажи никак не взаимодействовали
(поэтому потребность биздева в макетах оставалась незаметной) - У команд были разные объяснения проблемы:
— дизайн считал, что партнёрам непонятно, как устроен пользовательский путь;
— продукт видел проблему в нехватке гайдов на этапе интеграции.
Почему подключился сам
- Хотел проверить гипотезы до того, как команда начнёт делать решение.
- Для этого нужен был контекст переговоров и реальной подготовки материалов — я напрямую поговорил с биздевами.
- Исследователь был в отпуске, а задача казалась небольшой и срочной: ожидание на две недели замедлило бы проверку гипотезы
Как менялись гипотезы во время исследования
01
Сначала предполагал, что при передаче материалов теряется смысл
Партнёрам приходилось повторно объяснять продукт. Я предположил, что материалы не сохраняют контекст при передаче между участниками.
В беседах выяснилось, что повторные объяснения — обычная часть переговоров: у участников разные интересы и вопросы. Само по себе это ещё не указывало на проблему материалов.
В беседах выяснилось, что повторные объяснения — обычная часть переговоров: у участников разные интересы и вопросы. Само по себе это ещё не указывало на проблему материалов.
02
Узнал, что материалы должны были сократить запросы на дизайн
Изначально материалы создавали, чтобы партнёры могли самостоятельно подготовить интеграцию и не обращаться к нашей команде за разработкой макетов.
Но в исследовании выяснилось: для переговоров по-прежнему нужны примеры продукта в интерфейсе конкретного партнёра. Их подготовку брали на себя биздевы.
Я стал проверять, действительно ли материалы закрыли потребность в дизайне — или эта работа просто перестала быть видна нашей команде
Но в исследовании выяснилось: для переговоров по-прежнему нужны примеры продукта в интерфейсе конкретного партнёра. Их подготовку брали на себя биздевы.
Я стал проверять, действительно ли материалы закрыли потребность в дизайне — или эта работа просто перестала быть видна нашей команде
03
Запросы исчезли,
но потребность в дизайне осталась
Биздевы собирали макеты сами: не знали, к кому обратиться, или не рассчитывали получить помощь дизайна в срок переговоров. Подготовка занимала
75 минут, и срочные задачи не всегда удавалось выполнить вовремя. Задачи уходили в бэклог,
а переговоры переносились.
Я пришёл к новому предположению: материалы не устранили потребность в индивидуальных решениях — работа перешла к биздевам, стала менее заметна для дизайна и не всегда укладывалась в темп переговоров
75 минут, и срочные задачи не всегда удавалось выполнить вовремя. Задачи уходили в бэклог,
а переговоры переносились.
Я пришёл к новому предположению: материалы не устранили потребность в индивидуальных решениях — работа перешла к биздевам, стала менее заметна для дизайна и не всегда укладывалась в темп переговоров
04
Самостоятельные макеты могли влиять на будущую интеграцию
Биздевы показывали свои примеры партнёрам ещё до подключения дизайнеров. Эти макеты могли закреплять ожидания, даже если расходились с рекомендованным пользовательским сценарием.
Так сформировалась новая гипотеза: если дать биздевам быстрый способ готовить примеры по рекомендованному сценарию, это поможет раньше согласовывать качественную интеграцию и сократит необходимость пересматривать решения позже
Так сформировалась новая гипотеза: если дать биздевам быстрый способ готовить примеры по рекомендованному сценарию, это поможет раньше согласовывать качественную интеграцию и сократит необходимость пересматривать решения позже
Итоговые выводы исследования:
Существующие материалы не нужно полностью перерабатывать.
Они закрывают типовые вопросы части партнеров. Проблема возникает там, где нужно показать продукт напримере интерфейса партнера
Они закрывают типовые вопросы части партнеров. Проблема возникает там, где нужно показать продукт напримере интерфейса партнера
Продакт запретил делать дизайны биздевам, но проблема в течении года сохранилась
Причина почему биздевы продолжают делать дизайн является запросы самих клиентов, т.к. это объясняет наглядно продукт и позволяет его быстрее двигать
Первый пример влияет
на будущую интеграцию
Макет, который биздев показывает партнеру, формирует ожидания от продукта еще до подключения продукта или дизайнера, Если он отклоняется от рекомендованного флоу, это усложняет дальнейшее согласование и создает риск качества
Даже сложные задачи
можно делать с интересом
За серьёзным результатом всё равно остаются живые моменты: созвоны,
обсуждение проблем, и просто локальные мемы
обсуждение проблем, и просто локальные мемы
Каким должно было быть решение
Требования выдвинуты на основе ограничений
Не требовать ресурса команды дизайна
Не требовать навыков Figma
Масштабироваться вместе
с числом партнёров
с числом партнёров
Требовать минимум действий
от биздева
от биздева
Какое решение я придумал
01
Биздев загружает три экрана интерфейса в ChatGPT
Благодаря материалу, где рассказывается какие точки входа нам нужны, биздев быстро ориентируется, какие экраны ему нужно выбрать
02
Благодаря MCP, который я сделал. ChatGPT строго делает по инструкции. При этом сотруднику ничего не нужно делать
Спустя 20 минут генерации изображений, он выдает 8 или 6 макетов в зависимости от интерфейса партнера
03
При необходимости, ChatGPT делает пользовательский путь, чтобы рассказать клиенту, как встраивается фича
Ожидание занимает около 20-30 минут, так как анализируется путь клиента и точки, где должны разместиться изображения
04
Затем ИИ строит прототип, как работает наша фича, чтобы можно было на демонстрации продукта интерактивно потыкать
Биздевы отмечают, что прототип, помогает легче объяснить фичу, особенно тем, что плохо понимает в формате картинок
Какие проблемы решает инструмент
Проблема:
Не хватает примеров для конкретного партнёра
Генерирует варианты встраивания CPQR
в интерфейс партнёра — без ручной сборки макета
в интерфейс партнёра — без ручной сборки макета
Проблема:
Подготовка материалов задерживает переговоры
Сокращает активное участие биздева: вместо 75 минут на макет — около10 минутна запуск генерации и проверку результата.
Проблема:
Примеры могут увести интеграцию
от рекомендованного сценария
Использует заранее заданные правила и сценарий, поэтому помогает обсуждать интеграцию в поддерживаемых форматах уже на этапе переговоров
Стив Джобс
Предприниматель, основатель Apple
«Простое может быть сложнее, чем сложное.
Нужно много работать, чтобы очистить мышление
и сделать его простым».
Объяснить смысл экранов интерфейса партнера
Собрал правила рекомендованного сценария:
46 требований к качеству генерации и 12 инструкций для каждого макета.
Объяснил ИИ, какие точки входа показывать, как адаптировать экран партнёра и какие ограничения соблюдать при встраивании виджета.
46 требований к качеству генерации и 12 инструкций для каждого макета.
Объяснил ИИ, какие точки входа показывать, как адаптировать экран партнёра и какие ограничения соблюдать при встраивании виджета.
Научить ИИ понимать наш CJM
Задал правила, по которым ИИ определяет смысл экранов и выбирает подходящее место для продукта.
Он учитывает, какие элементы можно заменить, где разместить баннер и в каком порядке собрать результат
Он учитывает, какие элементы можно заменить, где разместить баннер и в каком порядке собрать результат
Объяснить смысл экранов интерфейса партнера
Настроил ИИ так, чтобы он не просто создавал отдельные макеты, а выстраивал последовательность экранов по пути покупателя.
Из неё биздев получает готовый материал для PDF или интерактивного прототипа, чтобы объяснить партнёру будущую интеграцию
Из неё биздев получает готовый материал для PDF или интерактивного прототипа, чтобы объяснить партнёру будущую интеграцию
Сравним результат инструмента и биздева
Что сделал биздев
Потраченное время 1 час 15 минут
Биздев самостоятельно собрал макеты для переговоров. В примере обнаружились три отклонения от рекомендаций
Размещение в небольшой карусели
Баннер конкурирует с соседними карточками, опыт показал, что партнеры убирают нашу рекламу в конец карусели. . Это создаёт риск, что покупатель не заметит возможность оплаты.
Нестандартные размеры компонента
Макет задаёт партнёру ожидание формата, который отличается от поддерживаемого. Такой вариант потребует дополнительной адаптации и поддержки либо пересогласования со стандартным компонентом, что удается крайне редко
Иллюстрация без нужной айдентики
Изображение не соответствует требованиям к фирменным материалам продукта. Это ослабляет его узнаваемость и потребует замены перед реализацией, если сможем договорится
Что сделал ИИ
Потраченное время: 10 минут
Выносит баннер в отдельный блок
В показанном варианте предложение оплаты находится вне карусели и не скрывается за соседними карточками. Это делает точку входа в продукт заметнее
Ориентируется на стандартные размеры компонента
Заданные ограничения помогают готовить вариант в рамках поддерживаемых форматов и сокращать необходимость индивидуальной адаптации. Соответствие размеров проверяется перед использованием
Использует айдентику продукта
Баннер конкурирует с соседними карточками, опыт показал, что партнеры убирают нашу рекламу в конец карусели. . Это создаёт риск, что покупатель не заметит возможность оплаты.
Результаты: меньше ручной работы, больше подготовленных решений для партнёров
Сократил участие биздева до 10 минут в подготовке материалов
Тем самым сотрудник тратит время на продажу продукта,
а не разработку дизайна. Потенциально влияет на скорость переговоров
а не разработку дизайна. Потенциально влияет на скорость переговоров
Ускорение процесса переговоров
на стадии дизайна
По обратной связи биздевов, партнёры быстрее переходили к обсуждению конкретной интеграции. Примеры, собранные по рекомендованному сценарию, снижали число вопросов и уточнений на старте переговоров
0 задач в беклоге спустя 1 месяц
Сравнение показало, что задачи по CPQR, Pay wighet, сплит с июня по июль, сравнили сентября с октябрем показали, что беклог с нашей стороны стремится к нулю. Что биздевы стали готовится заранее материалы, так как они не требуют времени
Расширил решение
до 3 продуктов
После пилота для CPQR адаптировал инструмент для Сплита и Пэй-виджета. Решение оказалось применимо к нескольким продуктовым командам и сценариям партнёрских интеграций
Вклад в бизнес-цели
Проект поддержал цели команды по масштабированию CP QR и ускорению качественных интеграций: помог быстрее готовить персонализированные примеры и учитывать рекомендации дизайна уже на этапе переговоров
Более качественные интеграции будут поддерживать рост GMV
Более качественные интеграции будут поддерживать рост GMV