Подготовка анонса
25 → 10 минВремя менеджера на типовой сценарий кампании
Кейс № 03 · SaaS · Gaming / CRM · 2023–24
Владелец управлял клубом вслепую: Excel, чаты и память менеджеров. CRM собрала игроков, финансы и работу в одну систему.
Кейс за минуту
Подробнее о результате ↓- Моя роль
- Единственный продуктовый дизайнер · отвечал за UX, объём работ согласовывал с продактом
- Ключевое решение
- Сделать клуб центральной сущностью и связать вокруг него роли, финансы, игроков и кампании.
- Результат
- Анонс 25→10 мин · ошибки 1,8→0,4% · пилот 100→5000+ участников.
Как читать этот кейс
Для понимания кейса не нужно разбираться в покере. Клуб здесь — это малый бизнес с базой игроков, менеджерами, деньгами и ручными операциями. Задача продукта — дать владельцу контроль над этим бизнесом: видеть состояние клуба, делегировать работу менеджерам и запускать коммуникации без Excel, чатов и постоянных сверок.
Результат — что изменилось
Владелец получил единую точку контроля по игрокам, финансам и работе клуба.
Ошибки доставки
1,8% → 0,4%После упрощения логики кампаний и единого справочника статусов
Масштаб пилота
100 → 5000+Клубы разного размера, прошедшие через первую версию
Подготовка анонса — дневники времени менеджеров + сверка по событиям продукта (measured / near-measured). Ошибки доставки — логи каналов и статусов (measured). Масштаб — фактический объём пилота (measured). Долю игроков с тегами отслеживали, но не выношу в главные метрики: она включала базовый тег Newbie.
01 Почему клубом было сложно управлять
Разрыв между данными, деньгами и коммуникациями — а не нехватка ещё одной админки.
Главная сложность была не в отсутствии админки, а в разрыве между данными, деньгами и коммуникациями. Игровые данные жили во внешней платформе, расчёты — в таблицах, а договорённости с игроками и менеджерами — в чатах.
Главным пользователем первой версии был владелец клуба: он подключал клубы, видел финансовую картину, заводил менеджеров и принимал решения. В больших клубах операционка переходила к менеджерам — коммуникация, анонсы, обратная связь.
Владельцы клубов — закрытые люди. Поэтому продукт должен был вызывать доверие с первого использования — в подключении клуба, ролях, доступах и прозрачности данных.
02 Моя роль
Единственный дизайнер: финальные UX-решения на мне, scope — с продактом.
За 4–5 месяцев до MVP я отвечал за четыре направления.
Исследование и архитектура
Интервью, разбор текущих таблиц и процессов, информационная архитектура вокруг сущностей клуба и игрока.
MVP, роли и модули
Подключение клубов, игроки, финансы, сегменты, кампании, роли и доступы.
Activation, тарифы, mobile web
Onboarding, подключение клуба, сценарий выбора тарифа и мобильное представление для менеджеров.
Процесс с командой
Проверка прототипов до и во время пилота, дизайн-ревью, работа с frontend над ключевыми сценариями.
Команда: продакт, проджект-менеджер, системный аналитик, 2 frontend-разработчика, backend-разработчик, доменный эксперт.
03 Что выяснилось на старте
Аудитория осторожная — часть инсайтов собрал наблюдением, а не вопросами.
Аудитория осторожно говорила о внутренних процессах, поэтому часть инсайтов я собирал через наблюдение: таблицы, скриншоты чатов, демонстрацию текущего процесса. После интервью с владельцами и менеджерами выделились три проблемы.
Владельцу не хватало прозрачности
Чтобы понять состояние клуба, владельцу нужно было звонить менеджеру, открывать очередную таблицу или вручную сверять данные из нескольких источников.
Игроки — неуправляемая база
Клуб понимал, что игроки разные по ценности, но не мог быстро отделять лояльных, спящих, ботов и профи. Удержание оставалось ручной работой на интуиции.
Коммуникации на ручном труде
Анонсы и приглашения запускались вручную. Это отнимало время, приводило к ошибкам доставки и создавало зависимость от конкретного менеджера.
Вывод: продукт нужно строить не как набор инструментов, а как систему управления клубом — сначала данные, финансы, роли и доверие, затем сегментация и коммуникации.
04 Логика MVP
Минимальный набор, который даёт владельцу контроль над клубом уже в первой версии.
Подключить клуб к платформе
Без интеграции продукт не получает данные о сессиях, игроках и столах. Это основание всей логики: пока данные не подтягиваются автоматически, ни аналитика, ни сегментация, ни коммуникации не работают по-настоящему.
Основа: игрок, финансы, доверие к данным
В первую версию вошли список игроков, данные по выигрышам и активности, базовые финансовые расчёты, роли и доступы. Роли — не техническая настройка: владельцу важно понимать, кто что видит, кто меняет данные и кому можно доверить коммуникацию.
Сегменты и коммуникации поверх базы
Когда база стала прозрачной, добавились сегменты, теги и кампании. Продукт перешёл от учёта к удержанию: выделять группы игроков и запускать точечные публикации и уведомления. Турниры просили почти все клубы, но в первую версию не вошли — сначала порядок в данных, финансах, ролях и сегментации.
05 Путь владельца: подключение и тариф
Activation вокруг первого рабочего клуба, а не обучения интерфейсу.
Onboarding строился вокруг активации: пользователь как можно быстрее связывает аккаунт с клубом и видит первые данные. Доверие появлялось не от объяснений, а от ощущения, что система действительно подключилась и показывает реальную картину клуба.
Onboarding и подключение
Первый вход, подключение account ID, подключение клуба — и первые реальные данные клуба на экране.
Тарифы между self-service и продажами
Пользователь видел текущий план, мог выбрать Bronze / Silver / Gold и период оплаты, но финальное изменение уходило заявкой менеджеру. Так задали продуктовую логику платных планов, не ломая существующий процесс продаж.
06 Ключевые решения
Шесть решений, которые сделали из учёта систему управления клубом.
Клуб — центр продукта, а не аккаунт
Базовой сущностью был технический аккаунт на внешней платформе. Но это не то, как владелец думает о бизнесе. Я сделал клуб главной сущностью: внутри — игроки, роли, финансы, кампании и аналитика, а один владелец управляет несколькими клубами без путаницы в аккаунтах.
Развёл владельца и менеджера по задачам
Владельцу нужен контроль: финансы, прозрачность, общая картина. Менеджеру — рабочий инструмент для коммуникаций и ежедневной операционки. Разделение ролей и доступов дало владельцу безопасно делегировать операционку, сохранив контроль над чувствительными данными.
Продукт вокруг сегментации, а не учёта
Простой список игроков не решал задачу: нужно понимать, с кем работать — кто активен, кто выпадает, кто ценен. Теги, сегменты и фильтрация связали данные об игроках с коммуникациями и превратили базу в инструмент удержания.
Отказался от таблиц на мобильных устройствах
На мобильных устройствах таблицы превращались в горизонтальный скролл с мелким текстом. Прототип показал: менеджер терял контекст строки. Сделали отдельное мобильное представление на карточках — одно из немногих мест без жалоб с первого дня.
Упростил логику модуля сообщений
Первую версию спроектировали до меня: несколько типов кампаний, ветвистые условия и сложные статусы. С аналитиком убрали лишние уровни абстракции, свели типы кампаний к минимуму и упростили статусы.
Для MVP взяли Ant Design
Важнее было быстро проверить сложные таблицы, формы и роли, чем собирать кастомную дизайн-систему. Ant Design дал готовую основу, а я адаптировал паттерны под сценарии клуба, тарифы и mobile web.
07 Что изменилось после запуска
Не новый интерфейс, а новый уровень операционного контроля.
После пилотного внедрения
- Расчёты и активность игроков перестали быть разбросаны по таблицам
- Менеджеры быстрее готовили анонсы и реже ошибались в доставке
- База игроков стала пригодной для сегментации и адресной работы
- Владелец получил единую точку, откуда видно состояние бизнеса и поведение игроков
- Подключение клуба и выбор тарифа стали понятнее и меньше зависели от ручного объяснения
Главный результат
Не то, что клубы стали быстрее делать анонсы, а то, что у владельца появилась единая система управления клубом — без звонков менеджеру и без открытия очередной таблицы.
08 Что сделал бы иначе
Уже первой версии место и доверие к данным.
Жёстче ограничил бы первую версию
Брали слишком широко — часть модулей вышла в MVP недотестированной и потребовала переработки в первые недели. Фиксация вокруг прозрачности игроков, финансов и ролей сняла бы эти итерации.
Формализовал бы критерии качества данных
Продукт опирался на внешнюю интеграцию. Несовпадающие статусы транзакций подрывали доверие в момент первого знакомства. Правила валидации до запуска решали бы это на уровне системы.
Отделил бы activation от ядра
Onboarding и тарифы в MVP конкурировали за внимание с данными, финансами и ролями. Собрал бы минимальный путь активации отдельно и проверял, где пользователь застревает до первого рабочего клуба.
