Техподдержка StormBPMN
Что это за процесс
Этот процесс описывает жизненный цикл обращения в техподдержку сервиса StormBPMN. Он начинается с поступления сообщения от пользователя и завершается одним из трёх исходов: консультацией по функционалу, устранением бага или записью запроса в роадмап. Схема покрывает путь от первичной классификации диалога до финального решения проблемы, включая взаимодействие с разработкой.
Как читать эту схему
В центре внимания — логика принятия решений оператором. После назначения оператора и присвоения меток происходит проверка достаточности данных. Здесь используется эксклюзивный шлюз: если данных недостаточно, процесс уходит в ветку уточнения запроса. Далее следует ключевая развилка по типу запроса. Если это вопрос по функции, оператор консультирует пользователя. Если сообщение о сбое, запускается попытка решения. При выявлении бага процесс раздваивается: создается ишью в гите и переводится диалог в тикет. Это место требует параллельного или инклюзивного шлюза, так как действия могут идти одновременно. Отдельная ветка для запросов на новые функции ведет к записи в роадмап. Также в схеме присутствует событие-таймер, контролирующий SLA на первый ответ.
Кому подойдёт
Схема полезна для команд техподдержки SaaS-продуктов, где важно разделять рутинные консультации, инциденты и фич-реквесты. Она подходит компаниям, использующим системы тикетов и трекеры задач (Git) для связи поддержки с разработкой. Также она актуальна для процессов, где требуется строгий контроль времени ответа (SLA).
Как адаптировать под свою компанию
- Замените каналы поступления сообщений на свои: email, чат, телефон или форму на сайте.
- Настройте критерии для шлюза «Достаточность данных» под специфику вашего продукта.
- Измените интеграцию с трекером задач: вместо «создать ишью в гите» укажите вашу систему (Jira, YouTrack и т.д.).
- Пересмотрите ветку «Запрос на фичу»: определите, кто и как записывает запросы в роадмап.
- Настройте таймер SLA под ваши стандарты скорости реакции на обращения.
Типичные ошибки
Частая ошибка — смешивание потоков: попытка решить баг и проконсультировать пользователя в одной ветке без четкого разделения. Вторая ошибка — игнорирование параллельности: создание тикета и уведомление пользователя часто идут одновременно, но моделируются последовательно. Третья ошибка — отсутствие явного условия возврата к уточнению данных, что приводит к «висячим» тикетам.
Какие элементы BPMN здесь использованы
Нажмите на элемент, чтобы разобраться, что он означает и когда его применяют.
Частые вопросы
Как схема обрабатывает запросы на новые функции?
Если оператор определяет, что запрос касается новой фичи, он записывает его в роадмап. Это отдельная ветка, которая не идет в разработку для исправления, а фиксируется для планирования.
Что происходит, если пользователь описал баг?
Оператор создает ишью в гите и переводит диалог в тикет на решение проблемы. Эти действия могут выполняться параллельно, чтобы не задерживать фиксацию ошибки.
Есть ли контроль времени ответа в этом процессе?
Да, в схеме предусмотрено событие-таймер для SLA на первый ответ. Это позволяет отслеживать, не превысила ли поддержка допустимое время молчания.
Что делать, если данных в обращении недостаточно?
Процесс уходит в ветку уточнения: оператор запрашивает недостающие данные или уточняет суть запроса у пользователя перед дальнейшей классификацией.
Как завершается процесс, если это просто вопрос по функции?
Оператор консультирует пользователя по функции, и процесс завершается событием «Дан ответ на запрос по функциям». В разработку такой запрос не идет.



