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