В один день CRM-команда получает три запроса: остановить ошибочный промокод, подготовить письмо к завтрашнему событию и срочно выгрузить отчёт для руководителя. Во всех сообщениях стоит слово «срочно». Если работать по громкости запроса, команда может начать с отчёта, пока промокод продолжает создавать расходы.

Приоритет определяет порядок выполнения задач. Критичность описывает тяжесть текущего или возможного последствия, а срочность — сколько времени остаётся до существенного изменения ситуации. Эти свойства связаны, но не совпадают. Задача с близким сроком не всегда опаснее уже работающей ошибки.

Сначала отделите инцидент от новой возможности

Инцидент нарушает действующий процесс: неправильная аудитория, неработающая отписка, двойное начисление или недоступный обязательный сервис. Новая кампания создаёт потенциальную пользу. Пропущенная возможность может быть дорогой, но её нужно сравнивать на собственных основаниях, а не автоматически объявлять аварией.

Atlassian в описании incident management различает тяжесть инцидента и приоритет реакции; собственные уровни компания связывает с влиянием на пользователей и сервис. Это пример операционной практики, а не универсальная шкала для CRM. Матрицу ниже CRM Lab предлагает настроить под реальные полномочия и последствия бизнеса.

На входе задайте вопросы: что происходит сейчас, кого затрагивает, растёт ли ущерб, когда закрывается возможность решения, есть ли безопасный обход и кто подтверждает последствия. Если ответ неизвестен, короткая диагностика может иметь более высокий приоритет, чем полное выполнение исходного запроса.

Используйте понятные классы работы

КлассПримерПорядок действий
Продолжающийся существенный ущербМассовая отправка с неверными персональными даннымиНемедленная остановка и координация реакции
Подтверждённое обязательство с близким срокомСервисное сообщение о переносе назначенного событияВыполнение до срока с необходимой проверкой
Возможность с ограниченным срокомКампания к событию, которое состоится завтраОценка дополнительной пользы и вытесняемой работы
Плановое улучшениеНовый вариант шаблона или регулярного отчётаОбщая очередь по ценности и трудозатратам

Не назначайте одинаковое время реакции всем случаям одного класса без учёта бизнеса. Внутренний регламент должен назвать ответственных, каналы эскалации и часы доступности. Если команда работает только днём, нельзя незаметно пообещать круглосуточный аварийный сервис.

Считайте цену задержки без завышения

Цена задержки — последствия переноса задачи на определённое время. Для неисправного промокода это могут быть дополнительные потери до остановки. Для кампании — упущенная дополнительная прибыль, а не вся плановая выручка получателей. Если CRM обычно присваивает покупки по клику, эта атрибуция ещё не даёт оценки причинного прироста.

Условный пример. Ошибка скидки затрагивает около 60 заказов в час, избыточная скидка — 300 рублей на заказ. При сохранении темпа прямой перерасход составляет примерно 18 000 рублей в час. Это предварительная оценка, которую следует уточнить по фактически применённым скидкам.

Одновременно новая кампания обещает 500 000 рублей выручки. Но её дополнительный вклад с учётом самостоятельных покупок и расходов пока оценивается лишь диапазоном 10 000–30 000 рублей. Сравнивать 500 000 рублей с 18 000 рублей некорректно: первое число не является прибылью от срочного действия. Короткая остановка ошибочной механики в этой ситуации имеет ясное обоснование.

Для решений с риском для данных или обязательств денежная оценка не всегда уместна или достаточна. Не используйте арифметическую формулу приоритета как способ игнорировать последствия, которые трудно быстро оценить.

Покажите последствия для текущего плана

Любая срочная задача использует ограниченное время. В запросе на внеплановый запуск укажите, какая работа переносится, как меняется срок и кто согласовал компромисс. Иначе очередь будет выглядеть неизменной, а невыполнение плана — личной проблемой исполнителя.

Резерв для внеплановых задач планируется по фактической истории. Он не должен молча превращаться в ещё один список обязательных кампаний. Разбор инцидента должен превращать повторяющуюся аварию в задачу с владельцем. Если аварии систематически занимают больше резерва, разберите их источники: возможно, команде выгоднее исправить данные или процесс выпуска, чем увеличивать скорость обработки обращений.

Ограничьте число одновременно открытых срочных задач. Когда всё выполняется параллельно, ни у одной работы нет предсказуемого завершения. Назначенный координатор должен объединять дублирующие запросы по одному инциденту и давать бизнесу общий статус.

Дайте бизнесу быстрый ответ даже при отказе

Ответ на запрос может быть конкретным: «Остановим ошибочную скидку сейчас. Для новой кампании можем выпустить проверенный вариант завтра к 14:00; расширение аудитории потребует ещё одного дня». Такое сообщение содержит решение и условия, а не только ссылку на загруженность.

Если срочность появилась из-за поздней постановки задачи, сначала решите текущую ситуацию, затем измените процесс. Наказание заказчика отказом не улучшает результат. Но постоянный обход очереди без разбора создаёт стимул всегда приходить в последний момент.

Для типовых запросов задайте необходимый минимум данных: цель, аудитория, условия, срок, владелец и критерий результата. Ускоренный маршрут должен сокращать ожидание, а не исключать проверку согласий, ссылок и коммерческих условий.

Проверьте качество приоритетов

Смотрите на долю внеплановой работы, число повторных аварий, выполненные обязательства и фактическую цену переноса. Отдельно анализируйте задачи, объявленные критичными, последствия которых впоследствии не подтвердились.

Полезная система приоритетов позволяет бизнесу быстро получить помощь там, где промедление дорого, и понимать судьбу остальных задач. Она работает, когда порядок объясняется последствиями и доступными ресурсами, а не должностью человека, который последним написал в чат.

Источники

Atlassian. Understanding incident severity levels. Atlassian Incident Management. Проверено 23.09.2026.