Риск не видно в отчёте, пока он не стал просрочкой.

Кейс: в агентстве 14 проектов, срыв по срокам рос 3 месяца подряд. Причина оказалась не в команде, а в метриках контроля.

Что отслеживали:
— % задач, ушедших за SLA;
— среднее отклонение от плана по неделе;
— долю задач без владельца;
— число возвратов на доработку;
— возраст задач в статусе «в работе» > 5 дней.

Порог срабатывания:
— SLA breach > 12%;
— tasks without owner > 0;
— rework rate > 18%;
— 2 недели подряд рост drift по плану.

Когда эти цифры свели в один дашборд, риск стал виден за 7–10 дней до срыва. 📊

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

SLA не ставят “на глаз”. Его собирают из 3 входов: объем, риск, цена задержки.

Кейс: агентство ведет лидогенерацию для B2B-клиента. До SLA было: “отвечаем быстро”. Итог — спорные ожидания, просрочки, хаос в чатах.

Чек-лист фиксации SLA:
1. Описать типы запросов: лид, правка, инцидент, согласование.
2. Для каждого типа задать время реакции и время решения.
3. Отдельно прописать рабочие часы и что считается паузой клиента.
4. Назначить владельца SLA: кто отвечает за контроль.
5. Добавить эскалацию: через сколько минут/часов подключается тимлид.
6. Зафиксировать формат подтверждения: чат, таск-трекер, письмо.
7. Привязать штраф/компенсацию только к тем SLA, которые можно измерить 📌

Если SLA нельзя проверить по логам — это не SLA, а обещание.