Если несколько сообщений относятся к одному сбою, добавляйте их к одной открытой задаче, сохраняя время и результат каждой проверки. Новую задачу создавайте, когда появился другой адрес, другое поведение или ошибка вернулась после исправления.
Это ручной порядок команды. Он сокращает дублирующую работу, но не обещает уменьшить число сообщений от reChecker. Необязательно выключать уведомления, чтобы перестать заводить по задаче на каждый повтор.
Сначала найдите уже начатую работу
Назначьте человека, который первым проверяет событие и отмечает, куда оно передано. Иначе два сотрудника создадут одинаковые задачи или оба будут ждать друг друга. Способ назначения описан в памятке о получателях.
Перед новым поручением посмотрите точный адрес, время события и текущий результат. Похожее название недостаточно для объединения. Ошибки каталога сегодня и формы неделю назад могут быть независимыми.
Если связь ясна, добавьте факт к существующей задаче. Если неясна, сохраните отдельно и попросите исполнителя сравнить. Человек, который читает уведомление, не обязан сразу доказывать единую техническую причину.
На одном примере отделите повтор от нового случая
Допустим, каталог не открывался утром. Команда уже передала проблему разработчику:
| Что пришло | Что сделать со списком задач |
|---|---|
| 10:05, ошибка /catalog | Начать проверку и создать задачу |
| 10:10, тот же адрес и ответ | Добавить результат к открытой задаче |
| 10:20, адрес снова отвечает | Проверить восстановление и добавить итог |
| 11:00, не отправляется форма /contacts | Проверить отдельно; не скрывать под каталогом |
| Через неделю /catalog снова выдаёт ошибку | Записать новый случай со ссылкой на прежнее исправление |
Пример учебный. Он показывает, почему восстановление и повтор имеют разные действия. У первой задачи есть начало и проверенный итог; возврат ошибки после закрытия нужно исследовать заново.
Не выбрасывайте промежуточные ответы. Они помогут сравнить время с журналами сервера. В одной задаче сохраняйте последовательность, а не только последнее зелёное состояние.
Срочность определяйте по проблеме, а не по числу сообщений
Пять сообщений о старом замечании не обязательно важнее одного подтверждённого отказа отправки заявки. Посмотрите, что мешает посетителю сейчас и на каких страницах это повторяется.
Текущую недоступность начните с ручной проверки адреса. Техническое замечание, которое не блокирует действие посетителя, можно разобрать в ближайший рабочий период. Дата события важна: сообщение могло прийти или быть прочитано после восстановления.
В «Контроле сайта» смотрите фактические данные и настройки каналов. Ваши правила срочности не становятся встроенным автоматическим распределением задач. Для каждого существенного случая запишите исполнителя и следующий срок ответа.
Проверьте, почему одна группа возвращается снова
Раз в месяц возьмите часто повторяющийся случай. Причина может быть в незавершённой работе, новом варианте страницы или неудачном выборе обязательного текста. Не меняйте настройку только ради исчезновения сообщений.
Например, в контрольный текст попала дата акции. Редактор планово изменил её, и прежний фрагмент исчез. Сначала решите, какой стабильный текст отражает нужную страницу; затем осмысленно обновите настройку. Подбор описан в статье о важной странице.
Для группы оставьте короткое пояснение: «один адрес, одинаковый отказ утром, задача разработчика №12». Попросите другого участника восстановить историю по записи. Если он не видит время, адрес или новый симптом, верните недостающие строки. Сокращение переписки должно помогать разбору, а не скрывать различия.