Когда интернет-магазин на WooCommerce у одного из моих клиентов лёг в пятницу в шесть вечера из-за конфликта плагина оплаты Т‑Банка, у заказчика был один вопрос: через сколько я отвечу. SLA на поддержку сайта - это документ, который отвечает на такой вопрос цифрами, а не фразой “разберёмся как можно скорее”. За несколько лет работы с сайтами на Tilda, WordPress и кастомными сервисами я видел десятки версий таких соглашений - от одной строчки в договоре до таблиц на три страницы с уровнями критичности и штрафами. Ниже - как я формирую SLA на практике, какие сроки реакции закладывать по типам инцидентов и что обязательно прописывать, чтобы документ реально защищал обе стороны, а не пылился в папке “Договоры”.
Зачем сайту нужен SLA, а не просто договор на обслуживание
Обычный договор на техподдержку описывает, что подрядчик делает: чинит баги, обновляет плагины, следит за сертификатами. SLA (Service Level Agreement) добавляет к этому измеримые обязательства - за сколько часов подрядчик отреагирует на обращение и за сколько устранит проблему в зависимости от её критичности. Без этих цифр любая формулировка вроде “оперативная поддержка” не имеет юридического веса: оперативно - это через час или через три дня, решает каждый по-своему.
На практике SLA нужен в трёх ситуациях. Первая - сайт напрямую завязан на деньги: приём оплаты через эквайринг, интеграция с СДЭК для расчёта доставки, форма заявок, которая льёт лиды в CRM. Вторая - у бизнеса несколько подрядчиков или штатный сотрудник, и нужно разграничить зоны ответственности письменно. Третья - заказчик уже обжёгся на подрядчике, который сутками не отвечал на сообщения, и хочет зафиксировать сроки на бумаге. Если поддержку сайта отдают на аутсорс полностью, я обычно советую сразу оформлять техподдержку с прописанными сроками реакции, а не полагаться на устные договорённости - при первом же инциденте в нерабочее время устные обещания забываются обеими сторонами.
Время реакции и время устранения - разные вещи
Здесь чаще всего путаница. Время реакции (response time) - это срок, за который подрядчик подтверждает, что увидел обращение и начал разбираться. Время устранения (resolution time) - срок, за который проблема реально решена. Смешивать их в одном пункте SLA - ошибка, из-за которой договор становится бесполезным: заказчик думает, что за час всё почините, а исполнитель имел в виду только ответ “принято в работу”.
Я всегда развожу эти цифры по отдельности и привязываю к уровню критичности. Например, для критичного инцидента реакция может занимать 30 минут, а устранение - до 4 часов, потому что часть проблем (сбой на стороне хостера, недоступность API эквайринга) физически нельзя закрыть быстрее, сколько бы человек над ними ни сидело. И отдельно всегда прописываю рабочие часы, на которые действует SLA: 9:00-19:00 по будням - это одно, а круглосуточная реакция - совсем другая услуга и другая цена.
Уровни критичности инцидентов и сроки реакции
Делю обращения на четыре уровня. Ниже таблица, по которой я обычно строю SLA для сайтов на WordPress и Tilda с интеграциями - цифры адаптирую под конкретный проект, но логика такая.
| Уровень | Пример инцидента | Время реакции | Время устранения |
|---|---|---|---|
| Критичный | Сайт полностью недоступен, не проходит оплата через эквайринг, форма заказа не отправляется | 30-60 минут | до 4 часов |
| Высокий | Не работает виджет расчёта доставки СДЭК, aiogram-бот перестал отвечать в Telegram, отвалилась интеграция с CRM | 2-4 часа | до 24 часов |
| Средний | Визуальный баг на мобильной версии, сценарий в n8n падает раз в сутки, но не критично для бизнеса | 1 рабочий день | до 3 рабочих дней |
| Низкий | Опечатка в тексте, косметическая правка вёрстки, запрос на консультацию | 2 рабочих дня | по согласованию |
Важный момент - кто определяет уровень критичности. Если это делает только заказчик, каждая опечатка превращается в “критично, всё горит”, и SLA теряет смысл. Я прописываю в договоре конкретные признаки каждого уровня (недоступность сайта, потеря денег, невозможность оформить заказ - для критичного) и оставляю за собой право пересмотреть уровень, если формально заявленный не совпадает с реальным.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Что обязательно включать в SLA на поддержку сайта
Помимо таблицы сроков, в документе должно быть ещё несколько пунктов, без которых SLA не работает на практике.
- Часы действия соглашения - будни, выходные, праздники, и отдельно тариф на реакцию вне этих часов, если она вообще предусмотрена
- Каналы обращения - конкретный список: Telegram, почта, тикет-система. Обращение в личных сообщениях в WhatsApp, если оно не входит в список, не считается официальным стартом отсчёта
- Что входит в поддержку - исправление ошибок, обновление CMS и плагинов, мониторинг доступности, резервное копирование
- Что не входит - разработка нового функционала, редизайн, доработка скриптов интеграции сверх согласованного объёма часов оплачиваются отдельно по факту
- Регламент эскалации - к кому переходит обращение, если ответственный не отреагировал в срок
- Отчётность - ежемесячный отчёт по инцидентам и фактическому времени реакции, чтобы обе стороны видели соблюдение сроков, а не верили на слово
Отдельно проговариваю объём часов. У меня техподдержка начинается от 15 000 ₽/мес - это фиксированный пул часов на реакцию по SLA и типовые задачи, а не безлимитная доступность 24/7. На рынке студии предлагают SLA-поддержку в разных диапазонах - от 20 000 до 100 000 ₽/мес, в зависимости от круглосуточности и глубины реакции, но это ориентир по рынку, а не мой прайс - конечная цена всегда зависит от количества интеграций на сайте и требуемого времени реакции.
Каналы связи и эскалация инцидентов
Срок реакции ничего не стоит, если обращение потерялось между личными сообщениями в трёх мессенджерах. Поэтому канал связи фиксирую как часть SLA, а не как формальность. На практике использую тикет-систему или выделенный Telegram-чат с ботом-логгером - каждое сообщение фиксируется с таймстампом, и потом легко сверить, уложился ли я в срок реакции по конкретному обращению.
Эскалация нужна на случай, если основной исполнитель недоступен - заболел, в отпуске, физически не может ответить за 30 минут. В SLA прописываю резервный контакт и правило: если реакции нет в течение удвоенного срока (например, час вместо получаса для критичного уровня), обращение автоматически уходит на второй контакт или руководителя проекта. Для клиентов с автоматизацией на n8n или ботами на aiogram отдельно оговариваю мониторинг: сценарий, который упал ночью, должен сгенерировать алерт сам, а не ждать, пока заказчик заметит пропажу заказов утром - без этого пункта время реакции по SLA формально не нарушено, просто никто не знал о проблеме.
Частые ошибки при составлении SLA на поддержку сайта
Самая частая ошибка - путать время реакции со временем устранения, о чём я писал выше. Вторая - заводить один уровень критичности на всё подряд: тогда правка текста в футере и падение оплаты требуют одинаковой реакции, и SLA либо разоряет исполнителя, либо обесценивается для заказчика.
Третья ошибка - не прописывать зону ответственности за инфраструктуру. Если сайт лежит из-за хостинга, а не из-за кода, отсчёт времени устранения не должен идти на подрядчика по разработке - он может только ускорить коммуникацию с хостером, но не чинить чужой сервер руками. Это стоит развести письменно, иначе на разборе инцидента возникает спор, кто виноват в просрочке.
Четвёртая - забывать про версионность и тестовый контур. Если критичное исправление на проде разворачивается без предварительной проверки на копии сайта, риск получить второй инцидент поверх первого вырастает кратно. В SLA для проектов с интеграциями (эквайринг, CRM, СДЭК) я всегда оговариваю, что критичные правки по возможности проверяются на staging-версии, даже если это добавляет 15-20 минут к сроку устранения - это дешевле, чем откатывать сломанный платёжный модуль на боевом сайте.
Чтобы сайт работал без сбоев
Техподдержка
от 15 000 ₽/мес
Подробнее →Частые вопросы
Сколько стоит SLA на поддержку сайта
Отдельно SLA как документ не продаётся - это часть договора на техподдержку. У меня техподдержка с прописанными сроками реакции начинается от 15 000 ₽/мес, итоговая цена зависит от количества интеграций на сайте, требуемого времени реакции и того, нужна ли поддержка в выходные.
Можно ли обойтись без SLA и просто договориться на словах
Можно, но при первом серьёзном инциденте устные договорённости не помогают ничем - каждая сторона помнит их по-своему. Для сайтов без денежных операций и критичных интеграций иногда действительно достаточно общего пункта в договоре про поддержку, но для интернет-магазина или сайта с приёмом оплаты я всегда настаиваю на письменных сроках.
Что делать, если подрядчик регулярно нарушает сроки реакции по SLA
Первый шаг - сверка отчётности: если в договоре есть пункт про ежемесячный отчёт по инцидентам, там будет видно, где именно сроки не соблюдались. Дальше по договору обычно прописываются штрафные санкции или право на досрочное расторжение - эти пункты стоит закладывать заранее, до подписания, а не пытаться доказать нарушение постфактум без зафиксированных доказательств.
Нужен ли отдельный SLA для сайта на Tilda со скриптами
Если на Tilda стоят кастомные интеграции - расчёт доставки через СДЭК, вебхуки в CRM, сложная логика форм - сроки реакции нужны так же, как для WordPress. Простая посадочная страница без интеграций обычно обходится общими условиями поддержки без детальной таблицы по уровням критичности, потому что там физически нечему падать критично.