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

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

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

Итог

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