SLA с подрядчиком 1С: шаблон соглашения и разбор ошибок
📅 Опубликовано 22 июля 2026 г.
Коротко: SLA (Service Level Agreement) с подрядчиком 1С — это приложение к договору, где фиксируются измеримые метрики поддержки: время реакции (обычно 15–60 минут для критичных инцидентов), время восстановления (2–8 часов), доступность системы (99,5–99,9%), приоритеты инцидентов и штрафы за нарушение (5–20% от абонплаты). Без SLA спор о «долго чинили» превращается в конфликт без критериев. Готовый шаблон и разбор 7 ошибок — ниже.
- 4 приоритета инцидентов — от Critical (система стоит) до Low (косметика); для каждого свои сроки.
- Время реакции ≠ время решения — путаница этих метрик даёт 80% споров.
- Доступность 99,5% = до 3,65 часов простоя в месяц; 99,9% = 43 минуты.
- Штрафы 5–20% от месячной абонплаты за нарушение метрик — реалистичный диапазон.
- Часы обслуживания 8×5 или 24×7 радикально влияют на стоимость поддержки.
Что такое SLA с подрядчиком 1С и зачем он нужен?
SLA — соглашение об уровне сервиса, документ, который переводит расплывчатые обещания «мы вас поддержим» в конкретные, измеримые обязательства. Для сопровождения 1С это критично: когда встаёт учётная система в день сдачи НДС или зарплаты, вопрос «через сколько минут вы отреагируете» стоит денег и нервов.
Без SLA заказчик и подрядчик оперируют разными ожиданиями. Клиент считает, что «срочно» — это 10 минут, подрядчик — что до конца дня нормально. SLA убирает эту неопределённость: он фиксирует, что для инцидента приоритета Critical реакция наступает за 30 минут, а восстановление — за 4 часа. Всё остальное — нарушение с последствиями.
SLA не заменяет договор — он является его приложением. Договор описывает предмет, цену и юридические условия, а SLA — техническую и сервисную часть: метрики, приоритеты, каналы обращений, окна обслуживания. Правильно составленное соглашение защищает обе стороны: заказчик получает гарантии, подрядчик — защиту от бесконечных «горящих» задач в нерабочее время без доплаты.
Из каких разделов состоит рабочий SLA?
Полноценное соглашение об уровне сервиса для сопровождения 1С включает обязательный набор блоков. Пропуск любого из них создаёт «дыру», через которую утекают споры.
Предмет и границы услуги
Что именно поддерживается: конкретные конфигурации (1С:Бухгалтерия, ЗУП, ERP), базы, число пользователей. Что НЕ входит: разработка нового функционала, обучение, восстановление данных из-за действий пользователя. Границы важнее самого перечня — они предотвращают ситуацию, когда под «поддержкой» клиент понимает бесплатную доработку отчётов.
Классификация инцидентов по приоритетам
Сердце SLA. Каждое обращение относится к одному из уровней, и для каждого — свои сроки. Об этом ниже отдельным разделом.
Метрики и целевые значения
Время реакции, время восстановления/решения, доступность системы, процент решённых в срок обращений. Все — с конкретными числами.
Окна обслуживания и каналы
Часы работы поддержки (8×5, 12×5, 24×7), способы подачи заявок (тикет-система, телефон, почта), время учёта обращений вне рабочих часов.
Ответственность и штрафы
Что происходит при нарушении метрик: снижение абонплаты, штрафы, эскалация. И встречно — обязанности заказчика (доступы, тестовая среда, контактное лицо).
Порядок пересмотра
SLA — живой документ. Раздел о том, как и когда метрики пересматриваются (обычно раз в квартал или год по итогам отчётов).
Как классифицировать инциденты по приоритетам?
Приоритет определяет всё: скорость реакции, эскалацию, штраф. Стандартная модель — 4 уровня. Ключевое правило: приоритет присваивается по влиянию на бизнес, а не по эмоциям заказчика.
| Приоритет | Описание | Пример в 1С | Время реакции | Время решения |
|---|---|---|---|---|
| Critical (P1) | Система полностью недоступна, работа остановлена | Не запускается база, «зависла» вся конфигурация в день сдачи отчётности | 15–30 мин | 2–4 часа |
| High (P2) | Критичная функция не работает, есть обходной путь | Не проводятся документы реализации, не формируется УПД | 1 час | 8 часов |
| Medium (P3) | Ошибка не блокирует основную работу | Некорректно считается один отчёт, ошибка в печатной форме | 4 часа | 2–3 дня |
| Low (P4) | Косметика, пожелания, консультации | Настроить фильтр в списке, вопрос по функционалу | 1 день | 5–10 дней |
Отдельно пропишите механизм разрешения спора о приоритете: кто присваивает (обычно подрядчик по описанным критериям), как заказчик может оспорить. Без этого каждая заявка станет «Critical».
Какие метрики включать в SLA и как считать?
Метрика без формулы расчёта — пустой звук. Разберём три ключевых показателя.
Время реакции vs время решения
Самая частая путаница. Время реакции — от момента регистрации заявки до первого содержательного ответа специалиста (не автоответ!). Время решения — до полного восстановления работоспособности. Это разные метрики с разными сроками. Заказчик часто думает, что «реакция за 30 минут» = «починят за 30 минут» — отсюда конфликты.
Доступность системы
Процент времени, когда система работала, от общего времени в периоде. Считается по формуле: (общее время − время простоя) / общее время × 100%.
| Уровень доступности | Простой в месяц | Простой в год | Когда применимо |
|---|---|---|---|
| 99,0% | ~7,3 часа | ~3,65 дня | Некритичные базы |
| 99,5% | ~3,65 часа | ~1,83 дня | Стандарт для среднего бизнеса |
| 99,9% | ~43 минуты | ~8,76 часа | Критичные системы, торговля |
Важно: из расчёта доступности исключают плановые технические работы (обновление платформы, регламентное обслуживание) — но их окна должны быть заранее согласованы.
Процент обращений, решённых в срок
Доля тикетов, закрытых в рамках SLA-сроков, от общего числа. Целевое значение обычно 90–95%. Эта метрика — основа для расчёта штрафов и отчётности.
Готовый шаблон SLA с подрядчиком 1С
Ниже — структура соглашения, которую можно взять за основу. Адаптируйте числа под свою критичность бизнеса.
ПРИЛОЖЕНИЕ №__ к Договору №__ от __.__.2026
Соглашение об уровне сервиса (SLA)1. Предмет. Исполнитель оказывает услуги технической поддержки следующих информационных систем Заказчика: [1С:Бухгалтерия ред. 3.0, 1С:ЗУП ред. 3.1]. Количество пользователей: [__]. Режим работы поддержки: [8×5 / рабочие дни 9:00–18:00 МСК].
2. Каналы обращений. Основной — тикет-система [ссылка]. Резервный для P1 — телефон [номер]. Обращения вне рабочих часов регистрируются, но время реакции отсчитывается с начала следующего рабочего дня (если не согласован режим 24×7).
3. Приоритеты и сроки. Согласно таблице приоритетов (P1–P4). Приоритет присваивает Исполнитель по описанным критериям; Заказчик вправе оспорить в течение 2 часов.
4. Метрики. Целевая доступность — 99,5%. Доля обращений, решённых в срок — не менее 92%. Время реакции и решения — по таблице приоритетов.
5. Ответственность. При снижении доли решённых в срок обращений ниже 92% — скидка [10%] от месячной абонплаты; ниже 85% — [20%]. Максимальная суммарная неустойка за месяц — не более [50%] абонплаты.
6. Обязанности Заказчика. Предоставить доступы, назначить ответственное лицо, обеспечить тестовую среду, своевременно продлевать лицензии 1С:ИТС.
7. Отчётность. Исполнитель ежемесячно предоставляет отчёт по метрикам SLA.
8. Пересмотр. Метрики пересматриваются по соглашению сторон, но не чаще раза в квартал.
Обратите внимание: SLA — приложение, значит основные юридические формулировки должны согласовываться с текстом договора. Если у вас ещё нет корректно оформленного основного соглашения, полезно изучить, какие изменения в договорах с подрядчиками 1С действуют с 1 июля 2026.
7 типичных ошибок при составлении SLA
Разберём ошибки, из-за которых соглашение либо не работает, либо оборачивается против заказчика.
Ошибка 1. Неизмеримые формулировки
«Быстрая реакция», «оперативное решение», «в разумные сроки» — это не SLA, а благие пожелания. Любую метрику нужно выражать в минутах, часах и процентах. Если вы не можете измерить показатель — его нельзя включать в соглашение.
Ошибка 2. Смешение времени реакции и решения
Как отмечено выше, это разные метрики. Прописывайте их раздельно для каждого приоритета. Иначе подрядчик отчитается «отреагировали за 20 минут», а система будет стоять весь день — формально нарушений нет.
Ошибка 3. Отсутствие классификации инцидентов
Без приоритетов все заявки равны, и подрядчик решает косметическую правку раньше упавшей базы — потому что она пришла первой. Или наоборот, всё объявляется «критичным». Матрица приоритетов обязательна.
Ошибка 4. Игнорирование обязанностей заказчика
SLA — двусторонний документ. Если заказчик не дал доступы, не выделил тестовую среду или не назначил контактное лицо, подрядчик физически не уложится в сроки. Пропишите встречные обязательства и оговорку: время ожидания информации от заказчика в SLA-таймер не входит.
Ошибка 5. Нереалистичные метрики
Требование 99,99% доступности и реакции за 5 минут при абонплате в 30 тыс. руб./мес — фантазия. Подрядчик либо не подпишет, либо подпишет и будет постоянно платить штрафы, заложив их в цену. Метрики должны соответствовать бюджету и режиму (8×5 против 24×7 — разница в разы).
Ошибка 6. Штрафы без потолка и без связи с ущербом
Штраф 100% абонплаты за одно нарушение приведёт к тому, что подрядчик уйдёт или заложит риск в цену. Разумный диапазон — 5–20% с суммарным месячным потолком. Штраф — стимул, а не способ обогащения.
Ошибка 7. Нет процедуры эскалации и пересмотра
Что делать, если P1 не решён за 4 часа? Нужна лестница эскалации: специалист → руководитель поддержки → директор. И механизм пересмотра метрик — бизнес меняется, SLA должен адаптироваться.
Многие из этих ошибок пересекаются с проблемами постановки задач. Если вы столкнулись с тем, что подрядчик «сделал не то», причина часто не в SLA, а в размытом ТЗ — рекомендуем разобрать как составить ТЗ на доработку 1С с примерами и типичными ошибками, а для крупных задач — использовать готовый шаблон технического задания.
Как контролировать соблюдение SLA на практике?
Подписанный SLA без контроля — просто бумага. Настройте практику мониторинга.
- Тикет-система с таймстампами. Каждое обращение фиксирует время регистрации, первого ответа, закрытия. Это фактура для расчёта метрик.
- Ежемесячный отчёт. Подрядчик предоставляет сводку: сколько заявок, по каким приоритетам, сколько в срок, средние времена реакции/решения.
- Регулярные встречи. Квартальный разбор: где SLA нарушался, почему, что улучшить.
- Согласование плановых работ. Обновления платформы и конфигурации — с уведомлением и в окна, не входящие в расчёт доступности. Особенно это касается регулярных обновлений 1С, которые могут временно останавливать систему.
Если у вас нет собственного специалиста для контроля метрик и приёмки работ, эту функцию может выполнять независимый эксперт — подобрать его удобно через каталог специалистов 1С.
Часто задаваемые вопросы
Чем SLA отличается от обычного договора на сопровождение?
Договор — юридический документ о предмете, цене и условиях. SLA — техническое приложение к нему с измеримыми метриками сервиса: временем реакции, доступностью, приоритетами и штрафами. Договор говорит «что», SLA — «насколько быстро и качественно».
Какое время реакции для 1С считается нормальным?
Для критичного инцидента (P1, система стоит) — 15–30 минут в режиме 8×5. Для высокого приоритета (P2) — до 1 часа, для среднего — до 4 часов, для низкого — до 1 рабочего дня. В режиме 24×7 сроки для P1 могут быть жёстче, но и стоимость поддержки выше.
Какие штрафы прописывать за нарушение SLA?
Реалистичный диапазон — 5–20% от месячной абонентской платы за нарушение целевых метрик, с суммарным потолком не более 50% абонплаты за месяц. Штраф должен стимулировать соблюдение, а не разорять подрядчика — иначе он заложит риск в цену.
Нужен ли SLA при поддержке одной небольшой базы 1С?
Да, но упрощённый. Достаточно зафиксировать 2–3 приоритета, время реакции, часы работы и базовые обязанности сторон. Даже минимальный SLA убирает главные споры о том, что считать срочным и за какое время это должно быть решено.
Что такое доступность 99,5% в реальных цифрах?
Это означает, что система может быть недоступна не более ~3,65 часов в месяц (или ~1,83 дня в год). Уровень 99,9% допускает лишь ~43 минуты простоя в месяц. Из расчёта исключаются заранее согласованные плановые технические работы.
Кто определяет приоритет инцидента — заказчик или подрядчик?
Обычно приоритет присваивает подрядчик по критериям, описанным в SLA (влияние на бизнес, наличие обходного пути). Заказчик имеет право оспорить присвоенный приоритет в оговорённый срок — например, в течение 2 часов. Это предотвращает объявление всех заявок «критичными».
Как часто пересматривать SLA?
Пересмотр метрик проводят по итогам отчётности, но не чаще раза в квартал, чтобы не дестабилизировать работу. Полный пересмотр соглашения уместен при существенном изменении масштаба бизнеса, числа пользователей или критичности систем.
Найдите специалиста для решения этой задачи на koderion.ru