Часть 1. Разработка MVP

Цель

Зафиксировать что готово, что нужно дописать и где риски при адаптации TourQual под MAG AI.

Что нужно сделать

• Просмотреть код tourqual/ (ai/, billing/, web/, connectors/, db/)
• По каждому модулю поставить оценку готовности (%) под задачи MAG AI
• Выписать что нужно дописать и сколько это займёт
• Зафиксировать технические риски

Результат

Файл 01_аудит_готовности.md — готов. См. таблицу выше.

Брендинг

• Название: MAG AI (как надстройка к MAG.Travel)
• Домен: mag-ai.ru (регистрирует Антон)
• Цвета: зелёный #5f9b1f + лайм #9bc54a (как у MAG.Travel)
• Логотип: заказывает Галич (текстовый, минимализм)

Модули и цены (помесячно)

Длительность подписки

Технические изменения

• billing/yukassa.py: переменная PLAN_PRICES берётся из product.config['pricing']
• config.py: добавить настройки бренда
• web/templates/: переменные {{ brand_name }}, {{ brand_colors }}
• nginx/: server-блок для mag-ai.ru
• widget/: шапка виджета подгружает цвета из тенанта

Промпты разрабатываются как отдельные файлы в tourqual/prompts/mag_ai/ и подгружаются по product_code тенанта.

Список промптов (3 рабочих + 2 базы знаний)

Принципы

• Промпт = инструкция роли + контекст агентства + база знаний + JSON-схема ответа
• JSON-ответ всегда содержит: текст для клиента, классификация запроса, рекомендуемый следующий шаг
• Тон — от лица "Анны" (виртуальный менеджер), но без обмана клиента (мы не скрываем что это ИИ)

Текущий tourqual/connectors/crm/mag.py умеет только создавать сделку. Для MAG AI нужно расширить.

Новые методы

Webhook

Эндпоинт POST /webhook/mag/{tenant_id} в web/app.py для получения событий MAG.Travel в реальном времени:

• Новый клиент
• Новая сделка
• Новое сообщение в сделке
• Смена этапа сделки

Документация API: 2015.mag.travel/tourclient/dev/help

Зачем

Чтобы в М3 принять GO/NO GO решение нужны цифры: пользуются ли пилоты продуктом, какие фичи в топе, что им нравится.

Метрики продукта

• DAU — сколько пилотов заходило в кабинет хотя бы 1 раз в день
• AI-запросы / агентство / день — сколько генераций сделал каждый
• Использование модулей — какой модуль популярнее (помощник vs реактивация)
• Время до первой генерации — насколько быстрый онбординг

Технически

• Модель AIUsageLog в БД: tenant_id, user_id, module, tokens_in, tokens_out, latency_ms, ts
• Модель NPSResponse: tenant_id, score (0–10), comment, ts
• Дашборд админа в /admin/metrics — графики DAU, разбивка по модулям

NPS-форма

• Модальное окно в кабинете на 14-й и 30-й день после онбординга
• Шкала 0–10 + комментарий
• Цель: NPS ≥ 30 как порог "продукт нравится"

Бизнес-метрики GO/NO GO

• Конверсия "пилот → платный" (целевой ≥ 50%)
• Среднее количество ответов AI принятых менеджером
• NPS на 30-й день
• Готовность платить (по словам в кастдеве)

Цель

Пилот должен получить ценность за 1 день. Если онбординг — это 3-часовая инструкция, никто не дойдёт до конца.

4 шага онбординга

1. Подключение CRM (MAG.Travel) — токен из MAG, проверка коннекта
2. Подключение мессенджера — WhatsApp / Telegram (через Wazzup24 / Telethon)
3. Первый AI-диалог — пользователь видит как AI генерирует ответ на демо-сообщение
4. Видео-инструкция — 5-минутный screencast по основным фичам (снимает Антон)

Поддержка

• Чат поддержки в Telegram (ответ ≤ 4 часов рабочего времени)
• Скрипт ответов на типовые вопросы у Шевелевой
• 1-час видео-звонок при подключении (Шевелева или Галич)

Метрика

≥ 80% пилотов проходят все 4 шага в 1 день.