Главное за минуту
- Поддержка включает не только исправление ошибок, но и контроль критичных бизнес-сценариев.
- Сравнивать тарифы можно только при одинаковых SLA, включённых работах и правилах учёта часов.
- Для сайта на Битрикс отдельно фиксируют обновления, резервные копии, доступы и журнал изменений.
- Приемка задачи должна проверять путь пользователя: форма, UTM, CRM, уведомление и статус.
01
Техническая поддержка — это управляемая работа сайта
Владелец сайта обычно обращается за поддержкой после конкретного сбоя: не пришла заявка, пропала страница, не проходит оплата или редактор не может изменить баннер. Но устойчивый сайт зависит не от разовых исправлений. Нужно контролировать цепочку: домен и SSL-сертификат, сервер, ядро и модули 1С-Битрикс, шаблон, формы, почту, аналитику, интеграции с CRM и внешними API.
Поэтому в договоре технической поддержки важно разделить регулярные операции, инциденты и развитие. Регулярные операции выполняются по графику: резервное копирование, проверка ошибок, обновления и контроль доступов. Инцидент — это нарушение согласованного сценария, например заявка не создалась в CRM. Развитие — новая функция, редизайн или интеграция, которые оцениваются отдельно.
Для маркетолога результат поддержки измеряется не количеством закрытых тикетов. Важнее, что рекламный трафик не теряет UTM-метки, форма создаёт нужный тип сущности в CRM, менеджер получает уведомление, а конверсия не падает из-за технической ошибки. Для руководителя это означает понятный владелец каждого процесса, сроки реакции и журнал того, что менялось на сайте.
Если подрядчик предлагает «безлимитную поддержку» без перечня исключений, спросите, входят ли туда доработки, платные лицензии, работа ночью, внешние сервисы и восстановление после атак. Без этих границ цена выглядит понятной только до первой нестандартной задачи.
02
SLA и приоритет заявки
SLA задаёт время первой реакции и восстановления для каждого типа обращения.
03
Что обычно входит в поддержку сайта на 1С-Битрикс
Базовый контур начинается с технической доступности. Подрядчик проверяет срок домена и сертификата, доступность сайта по HTTPS, ошибки сервера, свободное место, очереди почты и состояние резервных копий. Для Битрикс полезно периодически запускать проверку системы, контролировать журнал событий и ошибки PHP. При этом само наличие бэкапа недостаточно: нужно знать, где он хранится, каков срок хранения и кто может выполнить восстановление.
Второй контур — прикладные сценарии. Для сайта с лидогенерацией это отправка каждой формы, обязательные поля, защита от спама, письма сотрудникам, запись в Битрикс24 или другую CRM, передача source, medium, campaign, landing page и client_id. Для интернет-магазина добавляются корзина, заказ, онлайн-оплата, остатки, доставка и обмен с 1С.
Третий контур — изменения. Поддержка должна безопасно публиковать контент, править шаблонные ошибки, подключать счётчики, редиректы и цели, а также объяснять влияние изменений на SEO и аналитику. Обновления ядра и модулей нельзя ставить на рабочем сайте без проверки: сначала резервная копия и тестовая среда, затем контроль ключевых сценариев.
Стабильность
Мониторинг доступности, SSL, места на диске, ошибок сервера и резервных копий.
Заявки
Проверка форм, писем, антиспама, UTM и создания лида или сделки в CRM.
Изменения
Контент, редиректы, мелкие доработки, настройка счётчиков и плановые обновления.
Безопасность
Доступы, обновления, аудит подозрительной активности и план восстановления.
04
От чего зависит цена поддержки сайта
Стоимость сопровождения сайта складывается из трудозатрат и ответственности, а не из числа страниц в меню. Небольшой корпоративный сайт с одной формой может требовать мало плановых часов. Но если заявки идут из рекламы, данные передаются в CRM, используются несколько доменов, личный кабинет и внешние API, цена растёт из-за числа точек, которые нужно контролировать.
На бюджет влияют режим реакции, объём включённых часов, квалификация команды и прозрачность процессов. Реакция в рабочее время и восстановление в течение следующего дня — одна модель. Дежурство 24/7 с целевым временем восстановления — другая: подрядчик должен иметь мониторинг, регламент эскалации и резерв специалистов.
Уточняйте, как учитываются часы: минимальная единица, округление, время на диагностику, тестирование и переписку. Отдельно зафиксируйте ставку сверх пакета и стоимость работ, не входящих в поддержку. Тогда ежемесячный счёт можно проверить по тикетам и отчёту.
| Модель | Подходит для | Что согласовать |
|---|---|---|
| Пакет часов | Плановых задач и редких обращений | Остаток, перенос часов, ставка сверх пакета |
| SLA-абонент | Сайта с регулярными лидами и продажами | Приоритеты P1–P3, реакция, эскалация |
| По заявкам | Разовых изменений без критичных процессов | Оценка до старта, срок и тестовый контур |
| Поддержка и развитие | Сайта, который постоянно меняется | Раздельный бэклог, бюджет и план релизов |
05
Граница между поддержкой, доработкой и аварией
Главный источник споров — разные ожидания. Заказчик считает, что «добавить новое поле в форму» входит в ежемесячную поддержку. Исполнитель видит изменение формы, обработчика, интеграции и CRM-воронки. Оба могут быть правы, если граница работ не была описана заранее.
К поддержке обычно относят устранение дефекта в существующем согласованном функционале, настройку контента, диагностику ошибки и плановые технические процедуры. Доработка меняет логику: новая форма, новый маршрут данных, интеграция, личный кабинет, перерасчёт цены, новая роль пользователя. Авария отличается не сложностью, а влиянием: сайт или ключевой канал продаж недоступен прямо сейчас.
Полезно вести единый бэклог с типом задачи, приоритетом, ожидаемым результатом и ссылкой на тикет. Тогда маркетинг не теряет мелкие правки, а разработчик может оценить риски до того, как изменение попадёт на боевой сайт.
Поддержка сохраняет работоспособность согласованного сценария. Если сценарий меняется, это задача на развитие с отдельной оценкой и приемкой.
Готовое сообщение
Формулировка задачи подрядчику
Цель: проверить и восстановить передачу заявок с формы «Получить расчёт» в CRM.
Сценарий: пользователь открывает страницу /services/, заполняет имя, телефон и email, отправляет форму. В CRM создаётся лид с источником «Сайт», телефоном, email, URL страницы и значениями utm_source, utm_medium, utm_campaign.
Проверка: протестировать без UTM и с тестовой ссылкой с UTM; убедиться, что письмо ответственному сотруднику приходит один раз, а дубль лида не создаётся. Номер тестовой заявки и время отправки приложить к тикету.
Критерий приемки: заявка появляется в CRM не позднее чем через пять минут после отправки, обязательные поля заполнены, UTM не подменяются, персональные данные не попадают в публичный лог.
Ограничение: изменения сначала внести на тестовой копии; перед релизом сделать резервную копию и согласовать время публикации.
06
Как принять работу: проверяем путь данных, а не ответ «готово»
Приемку лучше проводить со стороны бизнеса и в отдельном браузере без авторизации в CMS. Это снижает риск увидеть кэшированную версию или пропустить ошибку, которая возникает только у обычного посетителя. Подготовьте два теста: прямой переход и переход по ссылке с UTM. Для интернет-магазина добавьте заказ с тестовым товаром и выбранным способом оплаты.
После отправки формы проверьте не только сообщение «Спасибо». Откройте почту ответственного сотрудника, CRM и журнал интеграции, если он доступен. Сопоставьте время, телефон и идентификатор заявки. Убедитесь, что лид не попал в неправильную воронку, на корректного ответственного и с нужным источником.
Для технической части попросите ссылку на тикет, перечень изменённых файлов или настроек, результат тестов и способ отката. При обновлениях Битрикс запросите дату бэкапа и подтверждение тестирования шаблона, форм и административной части. Документацию по журналу событий и диагностике можно сверять на портале разработчиков 1С-Битрикс.
- 1
Зафиксируйте исходные данные. Запишите URL, браузер, время ошибки, тестовый телефон и ожидаемый результат до начала работ.
- 2
Проверьте пользовательский сценарий. Пройдите форму или заказ как посетитель, включая обязательные поля и сообщение об успехе.
- 3
Сверьте маркетинговые данные. Откройте CRM и убедитесь, что переданы источник, UTM, URL посадочной страницы и контакт.
- 4
Исключите дубли. Повторите тест один раз и проверьте, не создались две сущности или два письма.
- 5
Примите подтверждение. Сохраните номер тикета, описание изменения, данные бэкапа и согласованный план отката.
07
Какие риски нужно предусмотреть в договоре
Поддержка не будет управляемой, если у подрядчика нет нужных доступов или они хранятся у одного сотрудника. Минимальный набор — доступ к хостингу, доменному регистратору, DNS, CMS, почте, аналитике, CRM и репозиторию кода. Владельцем учётных записей должна оставаться компания-заказчик, а не личный аккаунт менеджера или разработчика.
Второй риск — отсутствие тестового контура. Исправление «на живом сайте» может остановить рекламу, сломать шаблон или записать некорректные данные в CRM. Если отдельной копии нет, подрядчик обязан хотя бы согласовать окно работ, сделать резервную копию и описать порядок отката.
Третий риск — молчаливое накопление технического долга. Устаревшее ядро, отключённые обновления, самописные правки в файлах ядра и неизвестные агенты повышают стоимость любого следующего изменения. Поддержка должна не только закрывать тикеты, но и фиксировать такие ограничения в отчёте с понятным приоритетом.
Доступы
Компания владеет учётными записями и контролирует выдачу прав.
Резервные копии
Есть периодичность, место хранения и проверенный способ восстановления.
Тестовый контур
Изменения проверяются до публикации на рабочем домене.
Отчётность
Часы, тикеты, риски и рекомендации видны заказчику ежемесячно.
08
Как выбрать подрядчика на сопровождение сайта
Начните не с прайса, а с короткого аудита текущего состояния. Соберите список критичных страниц и действий: лид-формы, каталог, заказ, личный кабинет, интеграция с CRM, выгрузка в 1С, письма, рекламные посадочные страницы. Для каждого действия назначьте владельца со стороны бизнеса и последствия сбоя. Это сразу покажет, какой уровень SLA действительно нужен.
Попросите подрядчика назвать не только ежемесячную цену, но и состав регламента: канал заявок, часы работы, время первой реакции, порядок эскалации, формат отчёта, правила оценки, исключения и порядок передачи доступов при завершении договора. Хороший ответ опирается на ваш сценарий, а не на универсальное обещание «всё включено».
Полезно начать с месяца сопровождения и измерить фактический поток задач. За это время станет видно, сколько уходит на контент, диагностику, интеграции и развитие. Если требуется показать текущую архитектуру или удачные сценарии интерфейсов, используйте реальные материалы из портфолио ICONICA, а не условные скриншоты.
Что запросить до договора
Пример ежемесячного отчёта, шаблон тикета, матрицу приоритетов, перечень исключений, требования к доступам и условия передачи проекта другому исполнителю.
Критичные сценарии описаны; SLA по P1–P3 согласован; доступы принадлежат компании; есть резервные копии; правила учёта часов понятны; приемка включает CRM и UTM.
09
Какое решение принять до запуска поддержки
Сначала определите, что сайт должен обеспечивать бизнесу каждый день. Для одних компаний это доступность каталога и несколько форм обратной связи. Для других — непрерывная передача заказов, синхронизация с 1С, оплата, CRM и рекламная аналитика. Именно этот перечень определяет состав технической поддержки и допустимое время простоя.
Затем разделите текущие задачи на три очереди: поддержание работы, устранение инцидентов и развитие. Для каждой очереди зафиксируйте способ постановки, ответственного, срок реакции и критерий приемки. Такой порядок позволяет контролировать бюджет: плановые часы не исчезают в авариях, а новые функции не маскируются под исправления.
Подключать подрядчика стоит, когда нет владельца технического контура, ошибки влияют на обращения и продажи, накопились обновления или команда не может проверить работу CRM после изменений на сайте. Начните с инвентаризации доступов и критичных сценариев, затем согласуйте SLA и формат отчётности. Это даст управляемую поддержку вместо набора несвязанных правок.
FAQ
Частые вопросы
Сколько часов поддержки нужно небольшому корпоративному сайту?
Начните с пакета на плановые задачи и диагностику, затем через месяц сравните фактические обращения с лимитом. Критичные формы и CRM лучше контролировать отдельно.
Входит ли обновление 1С-Битрикс в техническую поддержку?
Часто входит как плановая работа, но условия нужно закрепить: тестовая копия, резервная копия, проверка модулей и стоимость исправления несовместимости.
Можно ли передать поддержку новому подрядчику?
Да, если компания владеет доменом, хостингом, CMS, CRM и исходным кодом. При передаче нужны перечень доступов, бэкапы и история изменений.
Нужен ли SLA, если сайт не продаёт онлайн?
Да, но он может быть проще. SLA определяет, кто и когда реагирует на недоступность сайта, ошибки форм, SSL и другие инциденты.
Как понять, что подрядчик действительно потратил часы?
Запрашивайте отчёт с тикетами, описанием действий, затраченным временем, ссылками на результат и перечнем оставшихся рисков.
