Этапы работы с обращением
R001 остановил подборку, но может отдельно задать вопрос редакции. Это не возобновляет подписку. CRM в нашем учебном проекте учитывает обращения, их состояние и следующее действие. В этом уроке создадим CASE-01 для сообщения о неясном источнике адреса. Результатом станет небольшая карта этапов с владельцем и основанием ответа.
Обращение синтетическое, не получено по почте или через форму. Папка lesson-12 архива серии содержит карточку и журнал ожидаемых переходов. Никаких уведомлений исполнителю не отправляем. Контакт и учебная редакция остаются локальными объектами.
Обращение отдельно от подписки
Контакт R001 имеет unsubscribed для lesson_updates. Его вопрос относится к цели support_reply: объяснить конкретное затруднение, которое он сам указал в учебном сценарии. Модель не даёт права включить его в новую рекламную кампанию. Для настоящей коммуникации допустимость и применимые условия нужно рассмотреть отдельно; здесь мы только показываем различие назначений данных.
Карточка обращения хранит ID CASE-01, предмет, материал, ожидаемый результат, наблюдение, владельца и состояние. Не копируем всю историю подписки в текст вопроса. Подписка участвует только там, где нужно избежать нежелательного возобновления рассылки. Причина обращения: «неясно, какое правило определяет итоговый путь после назначения адреса». Это достаточно для первичной классификации.
| Этап | Смысл | Следующее действие |
|---|---|---|
| new | Получен предмет | Классифицировать |
| triaged | Понятны тип и граница | Назначить владельца |
| assigned | Ответственный принят | Разобрать условие |
| waiting_reader | Требуется уточнение | Ожидать нужные данные |
| resolved | Дано предметное решение | Сохранить основание |
Таблица не является обязательной структурой любой CRM. Это выбранная модель маленькой редакции. Отдельные состояния оправданы, потому что меняется ответственный или допустимое следующее действие. Множество оттенков «почти готово» не добавит смысла. Если один этап ничего не меняет, его лучше представить подзадачей, а не отдельным статусом.
Классификация и граница
Сначала Ольга определяет тип: вопрос по объяснению, не авария хостинга и не коммерческий заказ. Материал связан с PUB-04, техническая среда неизвестна. Поэтому готовый диагноз отсутствует. Следующее действие — уточнить инструмент и состояние результата, либо объяснить общую связь, если вопрос о понятии. Такое решение локализует работу без обещания решить любой внешний проект.
Для нового сообщения важна минимальная информация. Если пользователь присылает секреты, их не следует копировать в карточку и приложение. Учебный случай данных не содержит. В настоящем процессе применяются правила содержания и отдельный порядок защиты. CRM не должна становиться хранилищем всего, что пришло, только потому, что интерфейс позволяет большой комментарий.
Назначение владельца требует его принятия. Поле «Максим» само по себе не доказывает, что рецензент увидел задачу и согласился выполнить. В модели сначала triaged, затем ожидаемая передача в assigned после явного принятия. Следующий урок подробно разберёт передачу. Это особенно важно при нескольких участниках, когда ответственность легко растворяется между статусами.
Результат обращения должен быть предметным. «Пользователю ответили» слишком общо. Для CASE-01 решение может быть: пояснили различие источника адреса и состояния сборки, запросили конкретное правило среды или создали задачу обновления урока. Разные решения требуют разных оснований. Карточка связывает ответ с вопросом, а не только считает завершённые сообщения.
Ожидание и закрытие
Если требуется уточнение, состояние становится waiting_reader. Не используем ожидание как скрытый способ объявить обращение решённым. В карточке записаны конкретный вопрос и причина. В синтетической модели это «каким правилом определяется путь результата?» Никакое письмо Роману или R001 не отправляется. Текст хранится как локальный образец будущего ответа.
Срок ожидания — проектная политика. Его нельзя объявить универсальным стандартом поддержки. В нашей модели срок пока не задан и поле остаётся неизвестным. Если будущая редакция решит закрывать неуточнённые обращения через определённое окно, состояние должно означать «закрыто без данных», а не «техническая проблема исправлена». Это различие важно для отчёта.
resolved требует ответа или решения, соответствующего предмету. Если выяснилось, что объяснение неполно, создаём связанную редакционную задачу BR-04, не возобновляя подписку. Если причина в другой среде, сохраняем ограничение ответа. Если вопрос оказался дублем, указываем конкретный материал и почему он подходит. Каждый вариант должен быть восстановим по карточке.
Обращение может открыться снова при новых данных. Для этого нужен журнал, а не стирание прежнего результата. Например, человек уточнил среду и выявилось другое правило маршрута. Карточка возвращается на предметный этап с новой версией. Старый ответ остаётся историей, потому что был дан при другом наборе условий. Так CRM сохраняет причинный контекст.
Локальная карта
В after.json добавлен CASE-01 со статусом triaged, владельцем следующего шага Ольгой и кандидатом исполнителя Максимом. Подписка R001 остаётся остановленной. Поле notification_sent ложное. Это ожидаемое редакционное состояние, не запись в настоящем кабинете CRM и не полученное обращение клиента.
В artifact.md есть все поля карточки и допустимые переходы. По ним можно объяснить, что нужно для назначения и что означает завершение. Техническая реализация, права доступа и хранение данных не созданы. Если будущий проект подключит CRM, потребуется сопоставить её статусы и права с этим процессом, а не просто импортировать названия этапов.
Отчёт по обращениям должен сохранить различие причины ожидания. waiting_reader означает, что нужен ответ участника; ожидание исполнителя относится к внутренней передаче. Если объединить оба случая в одну метку «ждём», редактор не поймёт, кому принадлежит следующий шаг. В нашем CASE-01 данных среды пока не хватает, но задача ещё не передана Максиму, поэтому текущий статус triaged и владелец Ольга. Она решает, какое уточнение требуется и кому его готовить. Нельзя заранее считать задержку виной читателя. Такой разбор делает карту этапов практичной: она указывает действие, которое команда может выполнить сейчас, и не прячет внутреннюю неопределённость за внешним ожиданием. После принятия передачи владелец изменится явно, с новой записью в журнале.
Проверьте изменённый случай: R002 просит предложить рекламу в рассылке. Это другой тип обращения и не становится задачей технического рецензента. Редактор либо направляет его к отдельному процессу, либо обозначает отсутствие такой услуги. Состояния могут оставаться похожими, но предмет и критерий результата различаются. Такая модель позволяет расширять работу с обращениями, сохраняя понятные границы коммуникации.