Регламент обработки обратной связи

Обновлено: 2026-07-18 процесс обратная связь поддержка SFHD триаж SLA

Регламент обработки обратной связи (SFHD)

Как обращения пользователей проходят путь от получения до выпуска фикса.
Цель — заложить дисциплину продуктовой команды уже в Pre-Alpha: обращения
не теряются, у каждого прозрачный статус, понятные ориентиры по срокам реакции,
единый путь от получения до релиза.

Адаптировано под нашу реальность:

  • Источник правды — YouTrack, проект SFHD (Skyforge Help Desk).
  • Команда = основатель (Product Owner + Support + триаж) + ИИ-агенты
    (разработка + автотесты как QA). Агенты работают 24/7, поэтому мелкие баги
    часто чинятся быстро — но жёстких публичных обязательств по срокам мы не
    даём     (см. SLA).
  • Уведомления автоматические — автор узнаёт о приёме и о решении без ручных
    действий команды.

Технический разбор интеграции (модули, коллекции, джобы) — на странице
Обратная связь → YouTrack. Здесь — процесс.

1. Каналы → единый бэклог SFHD

Все обращения, из какого бы канала ни пришли, сводятся в один бэклог — issue в
проекте SFHD. Единый вход исключает «потерянные» каналы и даёт одну доску
для триажа.

Канал Статус Тикет
Виджет «Обратная связь» на портале основной, работает AD-671
Внутренние обращения (сам основатель) работает —
Email поддержки план AD-609
Telegram / Discord план —
GitHub Issues план —

Правило: новый канал не заводит свой бэклог — он тоже конвертируется в issue
SFHD (механика создания issue — AD-672).

2. Регистрация (автоматически)

Обращение фиксируется без участия команды (виджет AD-671 → создание issue
AD-672). Что попадает в карточку:

  • ID — issue в SFHD (плюс внутренний feedback_id обращения);
  • дата/время получения;
  • пользователь (user_id, если вошёл) + email (из формы для гостя или
    email вошедшего — по нему замыкается петля к автору);
  • версия продукта;
  • браузер / ОС (User-Agent);
  • текст обращения;
  • авто-контекст: URL страницы, User-Agent; логи/скриншот — если приложены.

Стартовый статус — New. Пользователю сразу уходит авто-подтверждение
получения. Это обязательно, даже если фикс не планируется в ближайшее время:
человек должен видеть, что обращение принято.

3. Классификация (тег issue)

При триаже обращению проставляется категория (тег issue в SFHD):

Тег Что это
Bug Дефект: работает не так, как задумано
Feature Request Запрос новой возможности
UX Юзабилити / понятность, без явной поломки
Documentation Пробел или ошибка в документации
Question Вопрос по использованию
Invalid Не воспроизводится / не по адресу / спам

Реализация на сегодня (AD-672): при создании issue автоматически ставится
грубый тег (bug / idea) по типу обращения из виджета. Финальную категорию
из таблицы уточняет основатель при триаже в YouTrack.

4. Severity → поле Priority YouTrack

Серьёзность обращения задаётся через штатное поле Priority issue. Маппинг:

Severity Priority (YouTrack) Когда
S1 — Critical Show-stopper / Critical Сервис не работает, потеря данных, нет входа
S2 — High Major Основная функция работает криво
S3 — Medium Normal Есть обходной путь
S4 — Low Minor Косметика
S5 — Enhancement (без severity) Тег Feature Request, приоритет не задаём

Severity проставляет основатель на триаже. S5 (пожелания/улучшения) severity не
получают — они живут своим циклом Feature Request (см. ниже).

5. Жизненный цикл обращения

Компактный набор состояний доски SFHD:

New → Triage → (Invalid / Duplicate — выход)
             → Accepted → In Progress → In Review/Testing
             → Done (вошло в релиз) → авто-уведомление автору → Closed
  • New — только что получено, ждёт триажа.
  • Triage — основатель классифицирует: тег, severity → Priority, дубль/валидность.
  • Invalid / Duplicate — терминальный выход из потока (дубль линкуется к
    оригиналу, автор всё равно получает ответ).
  • Accepted — принято в работу.
  • In Progress — агент реализует фикс.
  • In Review / Testing — код-ревью + автотесты (QA-роль агентов).
  • Done — фикс вошёл в релиз. Переход в решённое триггерит
    авто-уведомление автору     (петля AD-672 → доставка AD-662/665).
  • Closed — цикл закрыт.

Feature Request — отдельная ветка

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

  • Запланировано — берём в roadmap;
  • На рассмотрении — идея принята к обдумыванию, сроков нет;
  • Отклонено — не вписывается в продукт (с причиной автору).

Ключевое для системы: переход issue в «решено/Done» автоматически
уведомляет автора. Состояния доски настраиваются в проекте SFHD.

6. SLA — ориентиры Pre-Alpha {#sla-orientiry-pre-alpha}

Это best-effort ориентиры, а не публичные обязательства. Команда = один
основатель + ИИ-агенты 24/7. Агенты работают ночью, поэтому мелкие баги нередко
чинятся быстро — но жёстких сроков перед пользователем мы не гарантируем.

Этап Ориентир
Авто-подтверждение получения мгновенно (система)
Триаж S1 в тот же день
Триаж S2–S4 несколько дней (best-effort)
Триаж S5 при ревизии бэклога
Исправление S1 приоритетно
Исправление S2 ближайшие релизы
Исправление S3 по возможности
Исправление S4 / S5 по roadmap
Информирование автора авто, в момент перехода в «решено»

Ужесточаем по мере роста команды. Целевой ориентир при штате — таблица из
оригинального регламента (напр., S1: первичный ответ 2 часа и т.д.). Пока —
внутренние ориентиры, а не контракт с пользователем.

7. Правила Pre-Alpha

Обязательные к соблюдению даже при минимальной команде:

  1. Каждое обращение получает авто-подтверждение и обязательно проходит
    триаж     — даже если фикс не планируется.
  2. Feature Request — без фиксированного SLA на реализацию; после триажа:
    Запланировано / На рассмотрении / Отклонено.
  3. Перед каждым релизом основатель делает ревизию открытого бэклога
    SFHD     и формирует список вошедших фиксов → в changelog и в текст
    уведомления автору («войдёт в версию X»).

8. Лёгкие KPI (ежемесячно)

Метрики держим простыми; автоматизируем позже.

  • % обращений, прошедших триаж в срок (по ориентирам выше);
  • 100% обращений имеют категорию + приоритет;
  • S1 быстро получает владельца;
  • FRT — среднее время первого ответа;
  • MTTR — среднее время до решения;
  • Reopen Rate ≤ 5% — доля переоткрытых после «решено»;
  • Топ-10 частых проблем;
  • Число обращений по релизам.

9. Как это ложится на код

Регламент опирается на уже смердженную механику эпика AD-673. Соответствие
шагов процесса и реализации:

Шаг процесса Реализация Тикет
Захват контекста (версия / браузер / URL / логи), авто-подтверждение Виджет и POST /api/feedback, коллекция feedback AD-671
Обращение → issue SFHD, тег-классификация, петля к автору при «решено» feedback_youtrack_sync (хук feedback_store.on_created + джоб sync_once) AD-672
Доставка уведомлений автору (авто-ack / «решено») In-app уведомления (SSE) + колокольчик AD-662 / AD-665
Статусы в «Мои обращения», настройка интеграции, ревизия бэклога /feedback/mine; раздел /admin/integrations (URL / проект / токен) AD-672 / AD-674

Приоритет конфигурации YouTrack: админ-конфиг (/admin/integrations, AD-674)
→ env → вшитый дефолт. Проект по умолчанию — SFHD, URL —
https://aagafonov.youtrack.cloud; на проде основателю достаточно ввести один
токен. Подробности — Обратная связь → YouTrack.

Связи

Часть эпика AD-673; опирается на AD-671 / AD-672 / AD-674, AD-662 /
AD-665, AD-609; перекликается с методологией ревью (AD-634).
Процессный документ (AD-675).