«Нам нужна поддержка сайта» может означать четыре разные потребности: иногда исправить ошибку, регулярно закрывать небольшие задачи, зарезервировать время специалиста или получить круглосуточную реакцию по договору. Если не разделить эти ожидания до начала работы, бизнес считает, что купил доступность, а исполнитель — что согласился только на список задач.
Разберём разовую работу, фактические часы, пакет и SLA без попытки объявить один формат лучшим для всех.
Сначала определить, что именно поддерживается
Поддержка может включать:
- исправление ошибок;
- изменения каталога, форм и страниц;
- обновление платформы и модулей;
- контроль интеграций;
- диагностику производительности;
- выпуск новых функций;
- мониторинг доступности;
- реакцию на инциденты;
- консультации сотрудников.
Это разные работы. Автоматический мониторинг не исправляет причину сбоя, а оплата часов разработки не означает круглосуточное дежурство. Состав услуги и границы ответственности следует записать отдельно от способа расчёта.
Полезно составить карту критичности. Если сайт остановится на два часа, будут потеряны продажи, нарушен внутренний процесс или только отложится публикация новости? От ответа зависит требуемый уровень доступности подрядчика.
Формат 1: разовые задачи
Компания обращается, когда возникает конкретная потребность. Подрядчик оценивает её, выполняет и закрывает. Нет постоянного обязательства или зарезервированной ёмкости.
Подходит, если:
- задачи появляются редко;
- сайт не является критичным каналом;
- внутри компании есть технический ответственный;
- допустимо ждать свободного окна исполнителя;
- каждая задача имеет самостоятельный результат.
Плюсы: нет регулярных платежей, легко сменить исполнителя, понятная граница работы.
Ограничения: на каждое обращение снова требуется контекст; срок старта зависит от загрузки; профилактика и накопленный технический долг остаются без владельца. Срочная задача не становится приоритетной автоматически только потому, что она срочна для заказчика.
Разовый формат полезен и как знакомство. Небольшая задача показывает качество коммуникации и работы с кодом до перехода к регулярному сопровождению.
Формат 2: почасовая поддержка по факту
Исполнитель остаётся знаком с проектом, задачи поступают в общий список, а бизнес оплачивает фактически затраченное время. Публичный ориентир на странице этой услуги — от 2500 ₽/час при регулярном сотрудничестве. Это не абонемент и не SLA: приоритет срочных задач обсуждается заранее.
Подходит, если:
- поток есть каждый месяц, но его объём меняется;
- задачи можно приоритизировать;
- важен один технический контекст;
- бизнес готов планировать работы короткими итерациями;
- не нужна гарантированная круглосуточная реакция.
Преимущество — гибкость: в одном периоде время уходит на ошибки, в другом на развитие каталога. Нет необходимости искусственно «сжигать» пакет. Ограничение — месячный бюджет заранее известен диапазоном, а не всегда точной суммой.
Для контроля согласуют лимит часов или бюджет, способ округления, отчёт и правило остановки. Исполнитель не должен превышать лимит молча, а заказчик — ожидать неограниченной доступности в рамках нескольких оплаченных часов.
Формат 3: пакет часов
Компания заранее покупает определённый объём времени на период. Пакет может включать приоритет перед разовыми задачами, но это нужно закрепить отдельно.
Подходит, если:
- объём достаточно стабилен;
- закупке нужен предсказуемый платёж;
- есть бэклог задач, который точно заполнит пакет;
- подрядчик реально резервирует соответствующую ёмкость.
Ключевые вопросы: переносятся ли неиспользованные часы, что считается временем, входит ли коммуникация и диагностика, как оплачивается превышение, какой приоритет получает пакет. Без ответов пакет превращается либо в неиспользованный аванс, либо в источник спора.
Пакет часов — коммерческая модель, а не гарантия времени реакции. Можно купить двадцать часов разработки, но не получить обязательство начать аварийную задачу за пятнадцать минут.
Формат 4: формальный SLA
SLA — соглашение об измеримых уровнях сервиса. Обычно оно определяет часы покрытия, категории инцидентов, время реакции, время восстановления или целевое время решения, каналы регистрации, исключения, отчётность и последствия нарушения.
Важно различать:
- реакцию — обращение принято и начата квалификация;
- восстановление — критичный сервис возвращён в рабочее состояние, возможно временным решением;
- полное решение — устранена корневая причина.
Обещание «решить любой инцидент за час» редко реалистично: причина может быть у хостинга, банка, CRM или 1С. Зрелый SLA описывает зону контроля и порядок взаимодействия с третьими сторонами.
Формальный SLA обычно требует команды, дежурств, мониторинга, резервирования специалистов и регламентов эскалации. Поэтому он дороже обычной разработки. Он оправдан, если стоимость простоя выше стоимости такой инфраструктуры.
Что предлагается здесь — и чего не обещается
Автор этого сайта — частный разработчик, а не агентство с круглосуточной сменой. На странице поддержки 1С-Битрикс прямо указано: формального агентского SLA нет. Срочные инциденты — падение сайта или остановка заказов — берутся в приоритет; рабочий режим и каналы связи согласуются, но это не следует трактовать как юридическую гарантию реакции 24/7.
Такое ограничение важно проговорить честно. Если бизнесу необходимо круглосуточное дежурство с финансовой ответственностью, резервной командой и фиксированными сроками, лучше выбирать поставщика, который организационно способен выполнить SLA. Почасовое сопровождение у одного специалиста решает другую задачу: сохраняет контекст и позволяет последовательно закрывать эксплуатационные работы.
Как оценить собственную потребность
Частота
Посмотрите историю за три–шесть месяцев: сколько было задач, ошибок и инцидентов. Если обращение возникает раз в квартал, разовый формат может быть достаточным. Если каждую неделю есть каталог, страницы и интеграции, регулярное сопровождение уменьшает повторное погружение.
Критичность
Определите последствия простоя для каждого компонента. Недоступность блога и остановка оплаты — разные приоритеты. Не весь сайт обязан иметь максимальный уровень сервиса.
Предсказуемость
Стабильный поток удобен для пакета. Неровный бэклог — для оплаты по факту с лимитом. Аварийная доступность требует отдельного резервирования, а не надежды, что подрядчик случайно свободен.
Внутренняя компетенция
Если сотрудник компании умеет проверить мониторинг, перезапустить безопасный процесс и собрать данные для диагностики, внешняя поддержка может работать эффективнее. Если никто не отвечает за сайт, подрядчику потребуется более широкий контур доступа и обязанностей.
Минимальный регламент без SLA
Даже почасовое сопровождение выигрывает от коротких правил:
- Все обычные задачи фиксируются в одном списке.
- У задачи есть бизнес-приоритет и критерий готовности.
- Для инцидентов существует отдельный канал.
- Определены рабочие часы и ожидаемый, но не гарантированный режим ответа.
- Установлен месячный лимит и правило согласования превышения.
- Изменения проходят тестирование и фиксируются в истории.
- После критичного инцидента записываются причина и профилактика.
Такой регламент не нужно называть SLA. Он создаёт прозрачность, не обещая организационные возможности, которых нет.
Что считать инцидентом
Срочность должна определяться влиянием, а не эмоциональной формулировкой. Пример классификации:
- критичный: сайт или оформление заказа недоступны для большинства пользователей;
- высокий: не работает важная функция, обходной путь существенно мешает операциям;
- обычный: локальная ошибка с доступным обходом;
- плановый: улучшение, контент или новая функция.
Конкретные категории компания адаптирует под себя. «Нужно поменять баннер к утру» может быть важной маркетинговой задачей, но это не технический инцидент. Для неё нужен плановый приоритет и заранее зарезервированное время.
Мониторинг, резервные копии и обновления
Поддержка должна отвечать на три разных вопроса:
- мониторинг — как быстро узнают о сбое;
- резервная копия — как вернуть данные и файлы;
- обновление — как устраняются известные ошибки и совместимость.
Наличие одного не заменяет остальные. Мониторинг без ответственного только отправляет уведомления. Бэкап без проверки восстановления создаёт ложную уверенность. Автоматическое обновление без тестового контура может само вызвать простой.
Перед сопровождением полезно провести вводную диагностику, проверить доступы и зафиксировать исходное состояние. Это особенно важно для сайта, который ранее обслуживали разные подрядчики.
Как выглядит регулярная работа на практике
В кейсе КриоКлиник сопровождение включает постепенные доработки каталога и контентных страниц с сохранением контекста проекта. Для Тосе задачи и возникающие проблемы разбираются в регулярном режиме. В проекте Дана96 изменения каталога и посадочных страниц приоритизируются по мере необходимости.
Эти кейсы подтверждают формат постоянного ведения, но не являются обещанием одинакового объёма, скорости или результата для любого сайта. У каждого проекта собственная сложность, доступы и критичность.
Как сравнить предложения поддержки
Попросите подрядчиков одинаково описать:
- состав включённых работ;
- часы покрытия;
- наличие или отсутствие SLA;
- время реакции и его юридический статус;
- стоимость плановых и срочных работ;
- перенос часов;
- мониторинг и отчётность;
- резерв на отпуск и болезнь;
- правила доступа и завершения сотрудничества.
Если один вариант дешевле, проверьте, не сравниваете ли вы разработку в рабочее время с круглосуточным сервисом. Если один дороже, выясните, какую доступность и резервирование он действительно добавляет.
Вывод и следующий шаг
Разовые задачи подходят редкому и некритичному потоку. Почасовое сопровождение — меняющемуся бэклогу, где ценен постоянный контекст. Пакет удобен при стабильном объёме и понятных правилах переноса. Формальный SLA нужен тогда, когда бизнес готов оплачивать гарантированную сервисную инфраструктуру.
Если вам подходит регулярная работа частного разработчика без обещания агентского SLA, опишите сайт, среднее число задач и самые критичные сценарии на странице поддержки и сопровождения 1С-Битрикс. По этим данным можно честно выбрать разовый или постоянный формат и согласовать границы до начала работ.