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

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

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

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

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

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

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

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

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

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

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

• «У меня одного не открывается Outlook» — это P3 (затронут один пользователь, есть обходное решение — web-версия).
• «У бухгалтерии не идёт обмен с банком» — это P2 (затронут отдел, есть обходное решение — ручной импорт выписки).
• «Принтер этажа не печатает» — это P2 (затронут отдел, есть обходное решение — соседний принтер).
• «Я не могу подключиться по VPN из дома» — это P3, если в офисе при этом все работают.

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

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

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

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

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-минутный диалог»: за 4 минуты он либо подтверждает P1 и заводит инцидент, либо переводит обращение в нормальную классификацию. Я его прогонял на курсах с инженерами не меньше 30 раз — он работает.

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

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

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

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

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

Инженер вслух применяет матрицу: «это затронуло вас одного или весь отдел? Есть обходной путь? Деньги теряются прямо сейчас?». На этом этапе становится понятно — P1, P2 или P3.

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

Инженер озвучивает: «классифицирую как P2, SLA реакция 30 минут уже идёт, начало работы — в течение 2 часов, я лично возьму, держу в курсе через час. ОК?». Получает подтверждение. Записывает в тикет с тайм-стампом.

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

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

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

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

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

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

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, но если объективные признаки P1 отсутствуют, мы автоматически переводим в P2 и пишем причину в комментарий тикета. Эти переклассификации мы раз в месяц показываем владельцу бизнеса с количественной разбивкой. Обычно после второго отчёта владелец сам сажает коммерческого на нормальные приоритеты.

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

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

Итог

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