SLA против «всё горит, всё P1»: как мы строим договор с клиентом

Декабрь 2025-го. Клиент — юрфирма, 38 рабочих мест. Их коммерческий директор взял привычку лепить «P1, срочно!» на всё подряд — на любую задачу, которую хотел получить «ещё вчера». За одну неделю мы получили 23 P1-обращения. Реально критичными оказались два. Два из двадцати трёх. Команда пахала по выходным, один из наших инженеров написал заявление на увольнение, владелец компании звонил мне каждые три часа. Вот в этой статье я разберу нашу SLA-матрицу P1–P4 с реальными таймерами, 14 шаблонами отказа, которые не разрушают отношения с клиентом, и алгоритмом на 4 минуты звонка — тот самый, что переводит «всё горит» в нормальный рабочий приоритет. Именно эта модель остановила тот хаос за 7 дней.

Откуда берётся давление и почему отвечать на него простым «нет» не работает

Я скажу прямо: в аутсорсинговом сервисе есть ровно два сценария. Либо ты сам держишь руку на пульсе приоритетов — и работаешь спокойно. Либо приоритеты начинают диктовать тебе клиенты — и тогда команда выгорит месяцев за шесть, не больше. Третьего не существует. Клиентское давление — не исключение и не признак «сложного клиента». Это обыденность, с которой сталкивается любой аутсорсер. Весь вопрос в одном: насколько хорошо выстроены твои процессы, чтобы это давление шло в нормальное рабочее русло, а не превращалось в ночные звонки и панику.

Откуда вообще берётся эта эпидемия «всё P1»? За 15 лет работы с МСБ я насчитал четыре источника. Первый — коммерческие сотрудники, которые искренне убеждены: их задача важнее всех остальных. Кстати, бухгалтерия думает ровно так же. И юристы тоже. Второй источник — владелец бизнеса, который пугается каждой проблемы и рефлекторно переводит её на максимальный уровень. Третий — руководители отделов, привыкшие управлять подчинёнными через нагнетание: создал иллюзию срочности — получил результат быстрее. Четвёртый — клиенты с травмой от предыдущего аутсорсера, после которого они ждут мгновенной реакции буквально на любой чих.

Просто сказать «это не срочно» — плохая идея. Причин три, и все рабочие. Первая: клиент слышит подтверждение своего худшего опасения — его не слушают. Вторая: вместо разговора получаем конфликт. Третья, и самая важная: это не лечит корень проблемы. На нашей практике реальная причина «всё горит» почти никогда не в технической задаче — она в эмоциях человека по ту сторону телефона. Поэтому работает не фраза «ваша задача не P1», а другая: «давайте разберёмся, что именно у вас сейчас идёт не по плану».

Наша SLA-матрица P1-P4 с конкретными признаками

Во всех наших договорах с клиентами — одна и та же матрица. Мы специально не адаптируем её под каждого. Почему? Потому что инженер должен работать предсказуемо, а не каждый раз вспоминать, у какого клиента какие правила. Матрица — четыре уровня. У каждого есть чёткие критерии классификации и таймеры реакции.

P1 — критический инцидент

P1 — это когда встал весь ключевой бизнес-процесс. Не замедлился, не частично деградировал — именно встал. Конкретные примеры: почта не работает ни у кого, 1С не открывается на всех машинах, основной сервер недоступен снаружи, ransomware-инцидент в инфраструктуре, утечка данных. Инженер реагирует за 15 минут в рабочее время и за 60 минут ночью. Приступает к работе — через 30 минут днём и через 90 ночью. Работаем без перерыва до полного восстановления, каждый час отправляем отчёт владельцу компании.

Что НЕ является P1, даже если клиент уверен в обратном:

• «У меня одного не открывается Outlook» — классический P3. Затронут один пользователь, и есть обходное решение: веб-версия почты работает без проблем.
• «У бухгалтерии не идёт обмен с банком» — это P2. Встал целый отдел, но выход есть: ручной импорт выписки закрывает задачу до устранения причины.
• «Принтер этажа не печатает» — P2. Отдел без печати, однако соседний принтер доступен. Работа не останавливается полностью.
• «Не могу подключиться по VPN из дома» — при условии, что в офисе все работают нормально, это P3. Проблема локальная, не системная.

P2 — высокий приоритет

P2 — мир не рухнул, но затронута группа пользователей или один сервер просел без полного падения инфраструктуры. Реагируем за 30 минут, приступаем через 2 часа, цель — восстановление за 4 рабочих часа. Один инженер, без привлечения старших коллег.

P3 — средний приоритет

P3 — затронут один пользователь, либо есть временное решение, с которым можно нормально работать. Реагируем за 2 часа, начинаем до конца текущего рабочего дня, восстанавливаем в течение 1 рабочего дня. Это львиная доля helpdesk-задач: настроить новое рабочее место, сбросить пароль, поставить ПО, разобраться с Outlook у одного конкретного сотрудника.

P4 — низкий приоритет / проект

P4 — запросы на изменения, проектные задачи, обучение, оптимизация. Всё, что не горит. Реагируем в течение 1 рабочего дня, к работе приступаем по утверждённому плану и смете. В нашей OTRS такие задачи сразу падают в отдельную очередь «Проекты» — чтобы не смешивать с текущей операционкой.

Как выглядит SLA-договор у нас: 11 пунктов, которые в нём обязательно есть

Когда-то наш SLA умещался на двух страницах. Сейчас это 11 пунктов на 9 страницах. Каждый пункт появился не из головы — за каждым стоит реальная ситуация с клиентом, где мы нашли лазейку или обнаружили дыру в договоре. Пройдусь по ним:

1. Матрица P1-P4 с критериями. Те самые признаки, по которым определяется приоритет. Не «P1 — это срочно», а «P1 — это остановка вот этих конкретных процессов».
2. SLA-таймеры по реакции и началу работы. Без обещаний «закроем за час» — только реакция и начало.
3. Право ITfresh переклассифицировать приоритет. Если автор тикета поставил P1, а признаки не соответствуют, мы переводим в реальный класс с уведомлением.
4. Маршрут эскалации. Engineer → team-lead → Семёнов. На каждом уровне свои сроки и полномочия.
5. Точки контакта с обеих сторон. Кто имеет право ставить P1 (обычно — гендиректор, главбух, IT-лидер), а кто только P2 и ниже.
6. Часы работы и дежурство. 9-19 пн-пт стандартное, ночное/выходное дежурство — отдельный пакет (15-25 тыс ₽/мес).
7. Список систем под SLA. Конкретные сервисы, которые покрыты — почта, 1С, AD, файловый сервер, конкретный список.
8. Что НЕ под SLA. Принципиально: «обновление BIOS на старом железе», «восстановление случайно удалённого письма годовой давности», «работа со специфическим ПО клиента, на которое у нас нет компетенции».
9. Метрики качества и ежемесячный отчёт. SLA-комплаенс, среднее время реакции, количество P1/P2/P3/P4, индекс удовлетворённости.
10. Штрафы и компенсации. За нарушение SLA реакции — частичный возврат месячной оплаты по формуле.
11. Условия пересмотра матрицы. Раз в полгода по совместному решению, если профиль нагрузки клиента изменился.

Маршрут эскалации: engineer → team-lead → Семёнов

Уровень 1: инженер на смене

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

Уровень 2: team-lead

Старший инженер автоматически подключается: по P1 — через 1 час без прогресса, по P2 — через 4 часа, по P3 — через 16 часов. Полномочия шире: меняет приоритет в обе стороны, подключает двух инженеров к одной задаче, напрямую выходит на владельца клиента и — да — может временно поставить другие тикеты на паузу ради самой острой проблемы.

Уровень 3: Семёнов лично

Я подключаюсь лично, если по P1 прошло 4 часа, а восстановления нет. Также вхожу в спорные случаи переклассификации, в жалобы от клиентов и в любые ситуации, где наши SLA расходятся с ожиданиями клиента. Мой звонок — это уже не про технику. Это разговор про управление: садимся и договариваемся, как работаем дальше.

14 формулировок отказа без потери лица клиента

Самое сложное под давлением — не отказать, а сформулировать отказ так, чтобы отношения остались целыми. Мы разработали 14 типовых фраз, которые наши инженеры используют и в звонках, и в переписке. Все они строятся на одном принципе: дать клиенту понять, что его слышат, назвать конкретные сроки и оставить живой выход — что-то вроде «если совсем критично — звоните мне напрямую».

# 14 шаблонов отказа от P1 без конфликта
# ITfresh, версия 2026.05, для внутреннего обучения

# 1. Когда клиент говорит «срочно!»:
"Слышу, что нужно быстро. По нашей матрице это P2 — реакция 30 минут,
 начало работы 2 часа. Если действительно P1 — назовите процесс,
 который остановлен полностью."

# 2. Когда клиент кричит про «деньги горят»:
"Понимаю. Скажите сумму потерь в час — это поможет мне правильно
 квалифицировать инцидент. Если больше 50 000 ₽/час — это P1."

# 3. Когда «звонит сам гендиректор»:
"Передам Семёнову лично через 2 минуты. До этого момента, чтобы
 не потерять время, скажите конкретно что не работает."

# 4. Когда «всё горит уже три дня»:
"Если три дня — значит, не критично остановлено. Это P2 или P3.
 Беремся сейчас плотно — в течение 4 часов решим."

# 5. Когда «у нас бухгалтер плачет»:
"Понимаю. Дайте бухгалтеру обходное решение на час — мы пока
 разберемся с основной проблемой. Через час сверим."

# 6. Когда «вы должны были предупредить»:
"Мы оповестили на этой неделе в стандартной рассылке (ссылка).
 Это плановое окно. Сейчас сосредоточимся на минимизации последствий."

# 7. Когда «у вас другой клиент важнее»:
"Все клиенты для нас одного класса. Сейчас в работе 2 параллельных
 P1. Ваш — третий, начнём в течение 30 минут."

# 8. Когда «другой админ сделал бы быстрее»:
"Возможно. Мы делаем по нашим стандартам. Если нужно срочнее —
 могу подключить второго инженера за дополнительную оплату."

# 9. Когда «давайте сейчас!» при низком приоритете:
"Сейчас в очереди 4 более срочных. Если пропустим вашу вперёд,
 у них поедут сроки. Готовы взять на себя ответственность за это?"

# 10. Когда «вы что, не можете 5 минут?»:
"5 минут — могу. Но переключение между задачами съест 20 минут
 на возврат к текущему P1. Это даст замедление ему. Подождём 25 минут?"

# 11. Когда «я плачу деньги»:
"Спасибо, что напомнили. Деньги вы платите за стабильность,
 не за ломку приоритетов. Стабильность сейчас обеспечивается
 тем, что мы держим план."

# 12. Когда «обычно вы делали быстро»:
"Раньше у нас была свободная ёмкость, сейчас вышли в плановую
 загрузку. Если нужно вернуться к прежней скорости — давайте
 пересмотрим ёмкость и SLA на следующий месяц."

# 13. Когда «всё, я звоню директору ITfresh»:
"Хорошо, Семёнов на связи всегда. Его номер — +7 903 729-62-41.
 Он сейчас в режиме доступа, но решение по приоритету
 примет на тех же основаниях, что я."

# 14. Когда клиент молчит после отказа:
"Если что-то непонятно или хотите эскалировать — скажите,
 я выведу на team-lead за 2 минуты. Если устроило — закрою тикет
 после решения и пришлю отчёт."

4-минутный алгоритм перевода «всё горит» в нормальный приоритет

Когда инженер берёт трубку и слышит «всё горит, всё P1, всё пропало» — в голове должен щёлкнуть конкретный алгоритм. Я называю его «4-минутный диалог». За эти четыре минуты инженер либо подтверждает P1 и открывает инцидент, либо переводит обращение в нормальную классификацию. Прогонял его на курсах с реальными инженерами — не меньше 30 раз. Работает.

Минута 1: выслушать без перебивания

Первое правило — не перебивать. Дайте клиенту выговориться до конца. Звучит просто, но именно это снимает примерно половину эмоционального напряжения ещё до того, как вы успели что-то сказать. Пока клиент говорит — короткие реплики: «слышу вас», «понимаю», «записываю». И никаких «давайте успокоимся», «не нервничайте», «это не катастрофа» — такие фразы не успокаивают, они злят. Проверено.

Минута 2: один уточняющий вопрос

Один вопрос. Не три, не два — один: «Что именно сейчас не работает у конкретного пользователя?». Пусть клиент назовёт конкретный процесс. На нашей практике после этого вопроса около 30% обращений переквалифицируются сами собой — человек вдруг слышит себя со стороны и понимает, что его «всё» — это на самом деле одна задача.

Минута 3: квалификация по матрице

Дальше инженер вслух сверяется с матрицей приоритетов. Три вопроса: проблема только у одного или весь отдел лежит? Есть хоть какой-то обходной путь? Компания прямо сейчас теряет деньги? Вот после этих трёх ответов уже абсолютно понятно — P1, P2 или P3.

Минута 4: фиксация плана

Инженер говорит чётко: «Классифицирую как P2. SLA — реакция 30 минут, уже идёт. К работе приступлю в течение 2 часов, буду отчитываться каждый час. Договорились?». Ждёт подтверждения. Фиксирует всё в тикете с точной отметкой времени. Без лишних слов.

Итог четырёх минут: клиент не на взводе, инцидент классифицирован правильно, инженер знает что делать, владелец бизнеса получит автоматический отчёт. И — что для нас принципиально — никто не чувствует себя выжатым после звонка.

Как мы пресекаем системные манипуляции от коммерческого директора

Сложнее всего, если давление идёт не от рядового пользователя, а от руководителя отдела или коммерческого директора. Эти люди умеют создавать ощущение катастрофы — это буквально их рабочий инструмент. И P1 они лепят на всё подряд, лишь бы получить результат прямо сейчас.

Что мы делаем:

1. В OTRS мы настроили правило автопереклассификации. Работает так: если автор тикета числится в списке «частые поставщики ложных P1» и в теме заявки нет явных триггеров — слов «упало», «не работает у всех», «остановлено» — система автоматически снижает приоритет до P2 и добавляет пометку «требует подтверждения от автора». Никакой ручной работы, всё происходит сразу.
2. По каждому пользователю мы ведём счётчик ложных P1. Раз в месяц владелец получает отчёт с конкретикой: «Вот человек — 18 тикетов с P1 за месяц. Реальных P1 среди них — ноль. Реальных P2 — четыре. Остальное P3». Цифры говорят сами за себя.
3. Дальше — звонок. Лично Семёнов набирает этого человека. Никакого давления, спокойный разговор: «Иван, мы заметили, что вы часто ставите P1. Я понимаю — задача важная. Но когда P1 на всём подряд, он перестаёт работать как сигнал тревоги. Давайте договоримся: один-два реальных P1 в месяц — норма, остальное идёт как P2 или P3». Один раз. Без обвинений.
4. Если после звонка ничего не меняется — разговор уходит на уровень владельца. На нашей практике уже второй отчёт решает вопрос: владелец сам идёт к сотруднику и разбирается внутри команды.

По моему опыту, алгоритм закрывает 8 случаев из 10. Оставшиеся два — это либо клиент с системно больной корпоративной культурой, либо ситуация, когда коммерческий директор оказывается родственником владельца и тот «не хочет конфликтов». Такое тоже бывает, скрывать не буду.

FAQ: что чаще всего спрашивают клиенты

Что делать, если клиент звонит ночью и требует немедленного решения некритичной задачи?

Для таких случаев у нас есть простой протокол. Дежурный инженер слушает — не перебивает, это принципиально — задаёт два уточняющих вопроса по матрице приоритетов. Если задача объективно не тянет на P1, он называет конкретное время начала работы следующим утром. В 96% случаев этого хватает. Если клиент всё равно стоит на своём — дежурный передаёт вопрос мне лично, и в 8:30 я разговариваю с ним уже не про технику, а про бизнес-последствия.

Как объяснить клиенту, что его задача не P1, не обидев его?

Наш главный приём — мы никогда не говорим «это не P1». Вместо этого звучит примерно так: «По нашей матрице задача относится к P2, SLA — 4 рабочих часа. Если нужно быстрее — давайте разберёмся, почему». И очень часто выясняется, что сам клиент не может объяснить, зачем ему срочно. Просто стресс. Стоит переключить его на реальные последствия задержки — и 3-4 часа уже не выглядят катастрофой. Такой разговор занимает от 4 до 7 минут.

Какой SLA реалистично выдержать на P1 в аутсорсинговой модели?

В нашем стандартном договоре для МСБ в Москве SLA по P1 выглядит так: реакция — 15 минут в рабочие часы и 60 минут в нерабочие; начало работы инженера — 30 и 90 минут соответственно. Жёсткого таймера на восстановление нет — слишком зависит от характера инцидента. Зато есть чёткое обязательство: работаем непрерывно до закрытия. На практике 89% P1-инцидентов закрываются за 4 часа, 97% — за 12.

Что делать, если коммерческий директор клиента постоянно ставит всё на P1?

Проблема с раздутыми приоритетами — не разовая история, она системная. Поэтому в нашем SLA-договоре прямо закреплено право ITFresh переклассифицировать приоритет с уведомлением клиента. Коммерческий директор может поставить P1 — но если объективных признаков нет, мы переводим задачу в P2 и подробно расписываем причину в комментарии к тикету. Всю статистику переклассификаций мы ежемесячно показываем владельцу бизнеса. Обычно после второго такого отчёта владелец сам решает вопрос с коммерческим директором.

Стоит ли вообще включать в договор фиксированные SLA-таймеры?

Таймеры в SLA ставить нужно — но только те, которые реально выполнимы. Я своими глазами видел договоры с формулировкой «восстановление за 1 час» по P1. Никто это не соблюдает. Никогда. И это становится постоянным источником конфликтов. У нас таймеры прописаны только на реакцию и на начало работы. По восстановлению — обязательство работать непрерывно и отчитываться владельцу каждый час. Реалистичный SLA защищает обе стороны. Нереалистичный — прямая дорога к войне с клиентом.

Итог

Хорошо написанный SLA-договор — это не бумажка в папке. Это живой инструмент, который защищает команду от выгорания, а клиента от паники. Ключевые компоненты: прозрачная матрица приоритетов с конкретными признаками каждого уровня, реалистичные таймеры на реакцию и начало работы (не на восстановление), закреплённое право аутсорсера пересмотреть приоритет, чёткий путь эскалации до владельца и готовые шаблоны отказа — чтобы никто не терял лицо. Вся эта система в связке превращает панику «всё горит, всё P1» в управляемый процесс — за 4 минуты разговора. У той самой юрфирмы с 38 рабочими местами мы остановили этот хаос за 7 дней: инженер остался в команде, а коммерческий директор начал ставить адекватные приоритеты уже через 2 месяца.