User Journeys¶

Ключевые сценарии использования платформы AqStream.

Обзор ролей¶

flowchart TB
    subgraph Platform["Платформа"]
        User["Пользователь"]
        Admin["Админ"]
    end

    subgraph Organization["Организация"]
        Owner["Владелец"]
        Moderator["Модератор"]
    end

    subgraph Group["Группа"]
        GroupMember["Участник группы"]
    end

    subgraph Event["События"]
        Public["Публичное"]
        Private["Приватное"]
    end

    User -->|"Запрос + одобрение + создание"| Owner
    Owner -->|"Приглашение"| Moderator
    Owner & Moderator -->|"Создание группы + инвайт"| GroupMember
    User -->|"Инвайт"| GroupMember

    Owner & Moderator --> Public & Private
    User -->|"Регистрация"| Public
    GroupMember -->|"Регистрация"| Private

Описание ролей¶

Роль	Описание	Основные задачи
Пользователь	Зарегистрированный на платформе	Регистрация на события, запрос на создание организации
Админ	Администратор платформы	Одобрение запросов на организации, модерация
Владелец	Создатель организации	Полный контроль, удаление, передача владения
Модератор	Член организации	Создание событий, check-in, аналитика
Участник группы	Приглашённый в группу	Доступ к приватным событиям группы

Полная ролевая модель: Role Model

Journey 1: Создание и публикация события¶

Роль: Владелец или Модератор организации

Цель: Создать событие и начать принимать регистрации

Шаги¶

flowchart LR
    A["Вход в систему"] --> B["Создание события"]
    B --> C["Настройка билетов"]
    C --> D["Предпросмотр"]
    D --> E["Публикация"]
    E --> F["Распространение ссылки"]

Детальный сценарий¶

Предусловия: - Пользователь зарегистрирован - Есть организация (для командной работы)

Основной поток:

Организатор входит в личный кабинет
Нажимает «Создать событие»
Заполняет основную информацию:
Название события
Описание (поддержка Markdown)
Дата и время начала/окончания
Место проведения (онлайн/офлайн)
Обложка события
Видимость участников (закрытая/открытая)
Настраивает типы билетов:
Название типа задаёт организатор
Для каждого: цена (бесплатно или платно), количество, период продаж
Время брони (опционально)
Предоплата (опционально)
Настраивает поля регистрационной формы (кастомные поля)
Проверяет в предпросмотре
Публикует событие
Получает ссылку для распространения

Результат: - Событие доступно для регистрации - Организатор может отслеживать регистрации

Видимость участников: - Закрытая (по умолчанию) — участник видит только свою регистрацию - Открытая — участники видят список зарегистрированных с распределением по типам билетов (для турниров, командных событий)

Метрики¶

Time to publish (от входа до публикации)
Completion rate (начали создание → опубликовали)
Количество редактирований после публикации

Journey 2: Регистрация на событие¶

Роль: Участник

Цель: Зарегистрироваться на интересное событие

Шаги¶

flowchart LR
    A["Открытие страницы"] --> B["Выбор билета"]
    B --> C["Заполнение формы"]
    C --> D["Бронирование"]
    D --> E["Оплата"]
    E --> F["Личный кабинет"]

Детальный сценарий¶

Предусловия: - Событие опубликовано - Есть доступные билеты

Основной поток:

Участник открывает страницу события
Просматривает информацию:
Описание и программа
Дата, время, место
Доступные билеты
Выбирает тип билета
Заполняет регистрационную форму (поля заданы организатором)
Завершает регистрацию (бронирует билет)
В личном кабинете появляется карточка события

Результат: - Регистрация создана (билет забронирован) - В личном кабинете — карточка события со статусом оплаты - Организатор видит новую регистрацию

Сценарии оплаты¶

Бесплатный билет: - Регистрация подтверждена сразу - Билет отправляется в Telegram

Платный билет без брони: - Оплата требуется сразу при регистрации - После оплаты билет отправляется в Telegram

Платный билет с предоплатой (без брони): - Предоплата требуется сразу при регистрации - Остаток оплачивается позже в личном кабинете

Платный билет с бронью: - Участник выбирает: оплатить сразу или позже - Отображается срок брони - В личном кабинете можно: оплатить полностью, внести предоплату, отменить

Карточка события в личном кабинете¶

Участник видит: - Информация о событии - Тип билета - Статус оплаты (если требуется) - Доступные действия: оплатить, отменить

Альтернативные сценарии¶

Билеты закончились: 1. Участник видит сообщение «Билеты распроданы» 2. Предлагается встать в лист ожидания 3. При появлении места — автоматическое уведомление

Истекла бронь: 1. Участник получает уведомление 2. Бронь аннулируется 3. Место возвращается в пул доступных

Метрики¶

Conversion rate (посетители → регистрации)
Drop-off по шагам
Время регистрации
Процент оплат в срок брони

Journey 3: Создание организации¶

Роль: Пользователь

Цель: Создать организацию для совместной работы над событиями

Шаги¶

flowchart LR
    A["Запрос на создание"] --> B["Одобрение админом"]
    B --> C["Создание организации"]
    C --> D["Приглашение команды"]
    D --> E["Создание групп"]

Детальный сценарий¶

Предусловия: - Пользователь зарегистрирован

Основной поток:

Пользователь отправляет запрос на создание организации
Админ платформы рассматривает и одобряет запрос
Пользователь создаёт организацию:
Название
URL (slug)
Описание
Логотип
Становится Владельцем организации
Приглашает членов команды через Telegram
Приглашённые становятся модераторами
Создаёт группы для приватных событий (опционально)

Роли в организации: - Владелец (Owner) — создатель, полный контроль, удаление организации - Модератор — управление событиями, check-in, аналитика

Группы: - Для приватных событий внутри организации - Участники приглашаются по уникальному инвайт-коду - Событие может быть видно только участникам группы

Результат: - Создана организация - Пользователь стал Владельцем - Команда может совместно работать

Метрики¶

Количество организаций с >1 членом
Retention организаций

Journey 4: Check-in на событии¶

Роль: Организатор / волонтёр на входе

Цель: Отметить прибытие участников

Шаги¶

flowchart LR
    A["Открытие check-in"] --> B["Сканирование QR"]
    B --> C["Подтверждение"]
    C --> D["Отметка участника"]

Детальный сценарий¶

Предусловия: - Событие в статусе «В процессе» или близко к началу - Есть регистрации

Основной поток:

Организатор открывает режим check-in
Сканирует QR-код с билета участника
Система проверяет:
Валидность билета
Не был ли уже check-in
Показывает информацию об участнике
Подтверждает check-in

Альтернативный поток (ручной поиск):

Организатор вводит имя или email
Находит участника в списке
Отмечает вручную

Результат: - Участник отмечен как прибывший - Статистика посещаемости обновлена

Метрики¶

Attendance rate (check-in / registrations)
Среднее время check-in

Journey 5: Отмена события¶

Роль: Организатор

Цель: Корректно отменить событие и уведомить участников

Шаги¶

flowchart LR
    A["Решение об отмене"] --> B["Отмена в системе"]
    B --> C["Уведомление участников"]
    C --> D["Возврат средств"]

Детальный сценарий¶

Предусловия: - Событие опубликовано - Есть регистрации

Основной поток:

Организатор открывает событие
Выбирает «Отменить событие»
Указывает причину отмены
Подтверждает действие
Система автоматически:
Меняет статус на «Отменено»
Отправляет уведомления всем участникам
Инициирует возвраты (для платных билетов)

Результат: - Событие отменено - Участники уведомлены - Средства возвращены

Метрики¶

Процент отменённых событий
Время от отмены до уведомления

Journey 6: Просмотр аналитики¶

Роль: Организатор

Цель: Понять эффективность события

Шаги¶

flowchart LR
    A["Открытие дашборда"] --> B["Анализ воронки"]
    B --> C["Просмотр метрик"]
    C --> D["Экспорт данных"]

Детальный сценарий¶

Предусловия: - Событие завершено или в процессе

Основной поток:

Организатор открывает дашборд события
Видит ключевые метрики:
Просмотры страницы
Конверсия в регистрацию
Количество регистраций по дням
Attendance rate
Анализирует воронку:
Просмотры → Регистрации → Check-in
Экспортирует данные (CSV/Excel)

Результат: - Понимание эффективности события - Данные для улучшения следующих событий

Метрики¶

Использование дашборда организаторами
Количество экспортов

Journey 7: Участник не получил билет¶

Роль: Участник (проблемная ситуация)

Цель: Получить билет после успешной регистрации

Шаги¶

flowchart LR
    A["Обнаружение проблемы"] --> B["Проверка Telegram"]
    B --> C["Запрос повторной отправки"]
    C --> D["Получение билета"]

Детальный сценарий¶

Предусловия: - Регистрация была успешной - Билет не пришёл в Telegram

Основной поток:

Участник проверяет чат с ботом в Telegram
Если не найден — входит в личный кабинет
Находит регистрацию в «Мои билеты»
Запрашивает повторную отправку
Получает билет в Telegram

Альтернатива (без связанного Telegram):

Переходит на страницу события
Использует «Найти мою регистрацию»
Вводит email
Получает ссылку для просмотра билета

Результат: - Участник получил билет - Проблема решена без обращения в поддержку

Journey 8: Одобрение запроса на организацию¶

Роль: Администратор платформы

Цель: Проверить и одобрить/отклонить запрос на создание организации

Шаги¶

flowchart LR
    A["Уведомление о запросе"] --> B["Просмотр данных"]
    B --> C["Принятие решения"]
    C --> D["Уведомление пользователя"]

Детальный сценарий¶

Предусловия: - Пользователь отправил запрос на создание организации

Основной поток:

Админ получает уведомление о новом запросе
Переходит в админ-панель → Запросы на организации
Просматривает данные запроса:
Имя пользователя
Название организации
Описание и цель
Принимает решение:
Одобрить — организация создаётся
Отклонить — указывает причину
Пользователь получает уведомление о решении

Результат (при одобрении): - Организация создана - Пользователь стал Владельцем - Может приглашать модераторов

Результат (при отклонении): - Пользователь получил уведомление с причиной - Может подать повторный запрос

Метрики¶

Время обработки запроса (SLA)
Процент одобренных запросов
Количество повторных запросов

Матрица сценариев по ролям¶

Journey	Пользователь	Владелец	Модератор	Админ
Создание события	—	✓	✓	—
Регистрация	✓	✓	✓	—
Создание организации	✓*	—	—	—
Check-in	—	✓	✓	—
Отмена события	—	✓	✓	—
Аналитика	—	✓	✓	✓
Восстановление билета	✓	✓	✓	—
Одобрение организации	—	—	—	✓

*После одобрения запроса админом

Дальнейшее чтение¶

Role Model — ролевая модель
Functional Requirements — функциональные требования
Roadmap — план развития