Тариф поддержки уже оплачен, но команда всё равно спорит, можно ли поставить в очередь правку формы, обновление CMS или проверку резервной копии. Это признак, что в договоре описана цена, но не зафиксирован состав работ.
В техническую поддержку обычно включают быстрые правки, безопасные обновления, проверку форм и заявок, резервные копии, мониторинг, сопровождение действующих интеграций и выпуск небольших релизов — в пределах согласованных часов и регламента. Крупная разработка, новый дизайн, аварийная работа вне SLA и сторонние лицензии автоматически в тариф не входят: их нужно оговаривать отдельно.
Главный критерий хорошего тарифа — не самый длинный список обещаний, а понятная граница ответственности: что команда делает регулярно, как ставятся задачи, когда начинается работа и по какому результату она принимается.
Актуальные пакеты часов и условия лучше сверять на странице стоимости поддержки сайта. Эта статья отвечает на информационный вопрос о составе работ; выбор тарифа и текущая стоимость остаются на коммерческой странице.
Кому это актуально
Такой разбор нужен владельцу сайта, интернет-магазина или веб-сервиса, если задачи появляются каждый месяц, но заранее непонятно, какие из них входят в абонентский пакет. Особенно важно зафиксировать границы, когда сайт связан с заявками, оплатой, CRM, 1С, доставкой, личным кабинетом или внешним API.
Материал также полезен перед сменой подрядчика. Новый исполнитель может получить проект без документации, списка интеграций и понятной истории релизов. В этой ситуации регулярная поддержка начинается не с обещания «исправлять всё», а с технической приёмки и согласования критичных сценариев.
Какие работы входят в техническую поддержку сайта
Конкретный состав зависит от тарифа и состояния проекта. Но в договоре стоит отдельно описать как минимум семь групп работ.
Быстрые правки и исправления
К этой группе относятся локальные изменения, которые не требуют проектирования нового продукта: поправить текст или вёрстку, восстановить отправку уведомления, изменить поле формы, исправить некорректный редирект, локализовать ошибку в существующем сценарии.
Слово «быстрая» не должно означать «без проверки». Даже небольшая правка может затронуть мобильную версию, аналитику, права доступа или интеграцию. Поэтому в состав задачи входят воспроизведение проблемы, изменение, проверка и контролируемый выпуск.
Обновления CMS, модулей и окружения
Поддержка может включать плановые обновления CMS, библиотек и модулей, если договор определяет порядок подготовки. Перед изменением нужно проверить совместимость, сделать резервную копию, согласовать окно работ и определить способ отката.
Автоматическое обновление без проверки не равно сопровождению. Если версия устарела на несколько поколений или обновление требует переделки собственного кода, это уже отдельный этап со своей оценкой.
Формы, заявки и уведомления
В тариф часто включают проверку форм, серверной обработки, писем и передачи данных в CRM. Важно фиксировать не только сообщение «форма отправлена», но и конечный результат: заявка дошла до согласованной точки, уведомление сформировано, а ошибка видна в логах и мониторинге.
Такая проверка особенно важна после релизов. Внешне страница может работать, но вложение не прикрепится, письмо попадёт в ошибку, а интеграция не создаст запись. Поддержка должна рассматривать всю цепочку, а не только кнопку на сайте.
Резервные копии и восстановление
В договоре нужно указать, кто создаёт копии, как часто они формируются, где хранятся и кто проверяет возможность восстановления. Сам факт наличия архива ещё не подтверждает, что сайт можно вернуть в рабочее состояние.
Периодическая тестовая проверка восстановления может быть отдельной задачей или частью расширенного тарифа. Граница должна быть видна заранее, потому что объём и риск зависят от размера базы, файлов и инфраструктуры.
Мониторинг и первичная диагностика
Мониторинг помогает заметить недоступность, рост ошибок, сбой сертификата или остановку важного фонового процесса. Но сигнал мониторинга — это начало расследования, а не готовый диагноз.
В договоре полезно перечислить, что именно контролируется: только ответ главной страницы или ещё формы, API, очереди, сертификаты и критичные пользовательские сценарии. Чем шире контроль, тем больше времени требуется на настройку и разбор событий.
Сопровождение действующих интеграций
Если сайт уже связан с CRM, 1С, оплатой, доставкой или внешним API, поддержка может включать локализацию сбоев, разбор логов, корректировку существующего обмена и проверку после изменений.
Создание новой интеграции с нуля обычно не относится к обычной поддержке. Это самостоятельная доработка: нужны требования, схема данных, обработка ошибок, тестовый контур и критерии приёмки.
Подготовка и выпуск небольших релизов
Изменение считается выполненным не тогда, когда разработчик закончил код, а когда оно проверено и безопасно выпущено. Поэтому в пакет могут входить работа через Git, проверка на staging, резервная копия, релиз и короткий контроль ключевого сценария после выкладки.
Если проект не имеет репозитория, тестового контура или регламента релизов, сначала нужно восстановить управляемый процесс. Эти начальные работы лучше выделить отдельно, а не скрывать внутри обещания о ежемесячной поддержке.
Обезличенные примеры задач в рамках тарифа
Состав работ проще понять на типовых сценариях. Это не обещание одинакового срока для любого сайта: фактическая оценка зависит от кода, доступов и причины сбоя.
- У формы перестало уходить вложение. Команда воспроизводит ошибку, проверяет серверную обработку и ограничения почты, исправляет найденную причину, проводит тестовую отправку и фиксирует результат в задаче.
- Нужно обновить CMS или библиотеку. Сначала проверяются зависимости и резервная копия, затем обновление проходит на тестовом контуре, после чего выпускается в согласованное окно с проверкой основных сценариев.
- В CRM перестало передаваться одно поле. Поддержка сравнивает данные на входе и выходе, локализует точку потери, корректирует существующее сопоставление и проверяет тестовую заявку по всей цепочке.
- После небольшой правки каталога сломалась мобильная вёрстка. Исполнитель воспроизводит проблему на нужной ширине, исправляет компонент, проверяет соседние страницы и выпускает изменение по обычному регламенту.
- Мониторинг сообщил об ошибках API. Команда подтверждает событие по логам, определяет влияние на пользователей и либо исправляет локальную причину в рамках пакета, либо готовит отдельный план более крупной доработки.
Что обычно не входит автоматически
Граница поддержки нужна не для отказа от задач, а для предсказуемой оценки. Отдельно чаще согласуются:
- разработка нового раздела, модуля или интеграции;
- полный редизайн и переработка интерфейса;
- миграция на другую CMS или новая архитектура;
- большой объём контентного наполнения;
- закупка сторонних лицензий и сервисов;
- аварийная работа вне согласованного времени и SLA;
- восстановление проекта без доступов, резервных копий и исходного кода;
- полноценное SEO-продвижение, реклама и другие маркетинговые работы.
Небольшая задача может перейти в отдельную разработку после диагностики. Например, просьба «добавить поле в заказ» затрагивает сайт, CRM, документы и обмен с учётной системой. Подрядчик должен объяснить эту границу до начала работ и дать новую оценку, а не списывать часы без согласования.
Реакция, диагностика и исправление — разные сроки
Время реакции показывает, когда подрядчик подтвердит обращение и возьмёт его в работу. Это не обещание, что неисправность будет устранена за тот же срок.
Диагностика нужна, чтобы воспроизвести проблему, оценить влияние и найти слой сбоя. Иногда для этого требуются логи, доступ к внешнему сервису или данные от третьей стороны.
Срок исправления появляется после диагностики. Он зависит от причины, риска изменения, необходимости тестирования и доступности интеграций. Для временного восстановления может быть согласован обходной сценарий, а окончательная правка пойдёт отдельным релизом.
Если в коммерческом предложении указан только «ответ за 15 минут», спросите отдельно о времени начала диагностики, порядке эскалации и правилах оценки исправления.
Какие риски закрывает договор поддержки
Понятный регламент снижает риск потери заявок из-за незамеченной ошибки, выпуска правки без резервной копии, конфликтов из-за списания часов и ожидания, что любой новый функционал уже включён в тариф.
Для бизнеса важна и непрерывность знаний. Когда задачи, решения, оценки и результаты хранятся в единой очереди, следующий специалист видит историю проекта и реже повторяет уже пройденную диагностику.
Договор не может гарантировать отсутствие сбоев. Он определяет, как команда замечает проблему, кто принимает решение, как безопасно выпускаются изменения и что получает заказчик в отчёте.
Что должно быть зафиксировано в договоре
До подписания проверьте, что документ или приложение отвечает на следующие вопросы:
- какие типы задач входят в пакет и какие требуют отдельной оценки;
- как считаются часы, минимальный шаг и неиспользованный остаток;
- какие приоритеты и каналы связи действуют для обычных и аварийных обращений;
- чем отличаются время реакции, начало диагностики и срок исправления;
- кто предоставляет доступы и согласует рискованные действия;
- нужны ли Git, staging, резервная копия и план отката перед релизом;
- как принимается результат и что входит в ежемесячный отчёт;
- как меняется тариф, если объём регулярных задач вырос.
Как выбрать тариф без переплаты
Не начинайте с максимального пакета «на всякий случай». Составьте список повторяющихся задач за последние месяцы и выделите сценарии, простой которых влияет на заявки, заказы или работу сотрудников.
Для стабильного сайта с редкими правками может подойти небольшой пакет. Проекту с регулярными релизами, CRM, оплатой или 1С нужен запас часов на проверки и более быстрый регламент реакции. Если состояние кода неизвестно, сначала разумнее провести диагностику и только потом выбирать постоянный формат.
Текущие условия, пакеты часов и ориентиры собраны на коммерческой странице стоимости поддержки. Более широкий состав процессов и тарифов можно сверить в разделе поддержки OpenStart. В статье не зафиксированы цены, чтобы информационный материал не расходился с актуальными коммерческими условиями.
Как это решает OpenStart
OpenStart начинает сопровождение с проверки технического состояния, критичных пользовательских сценариев, интеграций и истории изменений. Затем задачи ведутся через общую очередь, а формат работ связывается с пакетом часов, приоритетами, отчётностью и согласованным регламентом релизов.
Быстрые правки выполняются не в отрыве от проекта: команда учитывает backend, frontend, инфраструктуру и интеграции. Для изменений используются Git, тестовый контур и проверка после выпуска, когда это поддерживается проектом и входит в согласованный процесс.
Если первичная диагностика показывает крупную доработку, она не маскируется под обычную поддержку. Заказчик получает границу задачи, риски и основание для отдельной оценки.
Что запросить у подрядчика
Попросите не только коммерческое предложение, но и пример регламента. В нём должны быть понятны категории задач, приоритеты, канал аварийной связи, правила релиза и формат отчёта.
Полезно запросить:
- пример обезличенного отчёта по задачам и часам;
- перечень ролей, которые могут подключаться к проекту;
- порядок работы с доступами и резервными копиями;
- критерии готовности правки к релизу;
- план действий, если задача вышла за границы тарифа;
- правила фиксации и разбора повторяющихся инцидентов.
Частые вопросы
Любая ли правка входит в техническую поддержку?
Нет. Локальное изменение может войти в пакет часов, если не требует проектирования большого нового функционала. После диагностики подрядчик должен сообщить, остаётся ли задача в тарифе или ей нужна отдельная оценка.
Время реакции равно времени исправления?
Нет. Реакция — подтверждение и начало обработки обращения. Диагностика и исправление зависят от причины, доступов, риска и объёма тестирования.
Должны ли резервные копии входить в каждый тариф?
Это зависит от договора. Важно зафиксировать периодичность, место хранения, ответственного и порядок проверки восстановления. Наличие файла без проверяемого сценария восстановления недостаточно.
Можно ли включить интеграции с CRM и 1С?
Сопровождение уже работающего обмена и локальные исправления могут входить в пакет. Новая интеграция или существенное изменение бизнес-логики обычно оцениваются как отдельная разработка.
Как понять, сколько часов потребуется?
Соберите историю задач и критичных сценариев, затем начните с диагностики или подходящего пакета. После первого периода станет видно, сколько времени уходит на регулярные работы, профилактику и развитие.