Тариф технической поддержки нужно выбирать не по размеру сайта и не по привлекательности скидки за час. Основные критерии — фактический поток задач, роль сайта в продажах, сложность интеграций и допустимое время реакции. Небольшой корпоративный сайт может требовать больше внимания, чем крупный каталог, если на него постоянно ведётся реклама и каждую неделю меняются посадочные.
Рабочий способ выбора — собрать задачи за последние три месяца, перевести их в часы, добавить резерв на непредвиденные обращения и только затем сопоставить результат с тарифом. Ниже показан такой расчёт для четырёх типовых проектов.
Содержание:
Тарифы German Web и расчётный объём
| Тариф | Стоимость | Ставка | Расчётный объём | Реакция |
|---|---|---|---|---|
| Базовый | 20 000 ₽/мес. | 2 800 ₽/час | около 7 часов | до 60 минут |
| Развитие | 100 000 ₽/мес. | 2 300 ₽/час | около 43,5 часа | до 30 минут |
| Команда | 250 000 ₽/мес. | 2 000 ₽/час | 125 часов | до 15 минут |
Расчётный объём получен делением бюджета на ставку: 20 000 / 2 800 = 7,1 часа; 100 000 / 2 300 = 43,5 часа; 250 000 / 2 000 = 125 часов. Это ориентир для планирования, а не обещание выполнить за один час любую задачу одинаковой сложности.
В пакетах «Развитие» и «Команда» неиспользованные часы можно переносить до трёх месяцев. Это важно для проектов с неравномерной загрузкой: в одном месяце выполняется только обслуживание, а в следующем запускается крупный релиз.
Шаг 1. Посчитайте плановые задачи
Составьте список повторяющихся работ: обновления, изменение контента, новые блоки, отчёты, проверка форм, каталог, интеграции и рекламные посадочные. Для каждой строки укажите среднюю частоту и трудоёмкость.
Например, две небольшие правки по 1,5 часа дают 3 часа в месяц. Одна посадочная страница может потребовать 5–10 часов разработки без учёта нового дизайна. Четыре регулярных релиза с тестированием по 4 часа — ещё 16 часов.
Шаг 2. Добавьте обязательное обслуживание
- мониторинг доступности и ключевых сценариев;
- контроль резервных копий;
- плановые обновления CMS и модулей;
- проверка форм, заказов и уведомлений;
- анализ ошибок и журналов;
- контроль домена, SSL и инфраструктуры;
- ведение документации и истории изменений.
Эти работы не всегда заметны заказчику, но они уменьшают вероятность аварии. Если весь пакет заранее заполнить задачами развития на 100%, для диагностики внезапного сбоя не останется времени.
Шаг 3. Заложите резерв
Для стабильного корпоративного сайта достаточно резерва 15–20% от плановой загрузки. Для магазина или интегрированного проекта разумно оставлять 20–30%, потому что ошибки оплаты, обмена или каталога возникают не по расписанию.
Если задачи регулярно превышают пакет, выгоднее перейти на следующий уровень, чем каждый месяц согласовывать перерасход. Если остаётся половина объёма и нет плана развития, тариф стоит уменьшить.
Пример 1. Небольшой корпоративный сайт
| Работа | Часы в месяц |
|---|---|
| Проверка форм и уведомлений | 1,5 |
| Обновления и резервная копия | 1,5 |
| Две небольшие правки | 3 |
| Резерв на ошибки | 2 |
| Итого | 8 часов |
Проект находится на границе базового тарифа. Если часть задач можно объединять и сайт стабилен, достаточно пакета 20 000 ₽ или разовых обращений. Если восемь часов требуются каждый месяц, базовый пакет будет регулярно переполняться — тогда рациональнее согласовать индивидуальный объём либо перейти к более крупному пакету только при появлении плана развития.
Пример 2. Интернет-магазин
| Работа | Часы в месяц |
|---|---|
| Мониторинг заказов, оплаты и обменов | 5 |
| Обновления и тестирование | 7 |
| Каталог, фильтры и контентные правки | 12 |
| Исправления и небольшие доработки | 10 |
| Резерв на инциденты | 8 |
| Итого | 42 часа |
Расчёт почти совпадает с пакетом «Развитие»: 100 000 ₽ дают около 43,5 часа. Для магазина важна не только ставка, но и реакция до 30 минут. Если ежемесячная нагрузка превышает 50–60 часов, следует либо пересмотреть состав задач, либо переходить к большему пакету.
Пример 3. Интегрированный B2B-проект
| Работа | Часы в месяц |
|---|---|
| Контроль интеграций и очередей | 20 |
| Развитие кабинетов и бизнес-логики | 55 |
| Тестирование релизов | 20 |
| Документация и планирование | 10 |
| Резерв на инциденты | 20 |
| Итого | 125 часов |
Такому проекту соответствует тариф «Команда» за 250 000 ₽. Однако если одновременно ведётся несколько крупных направлений, 125 часов может быть недостаточно. B2B-система обычно требует отдельного бэклога, аналитики и технического задания для крупных функций; пакет поддержки не заменяет проектирование новой архитектуры.
Пример 4. Сайт с регулярными рекламными кампаниями
| Работа | Часы в месяц |
|---|---|
| Две посадочные или крупные итерации | 16 |
| Правки офферов, форм и блоков | 8 |
| Настройка целей и событий | 6 |
| Контроль скорости и мобильной версии | 4 |
| Резерв перед запусками | 7 |
| Итого | 41 час |
Пакет «Развитие» закрывает такую нагрузку и оставляет небольшой резерв. Важно согласовать календарь рекламных запусков: срочная посадочная, поставленная вечером перед стартом кампании, может потребовать сверхурочных и не должна считаться обычной плановой задачей.
Как учесть SLA
Чем короче срок реакции, тем больше ресурсов подрядчик должен резервировать. Поэтому выбирать тариф только по часам неправильно. Если простой магазина стоит дороже месячного пакета, реакция до 30 или 15 минут может быть важнее небольшой экономии на ставке.
Подробно разница между реакцией и решением разобрана в статье о SLA технической поддержки. Для сайта, который не участвует в продажах, быстрый SLA может быть избыточным.
Красные флаги при выборе тарифа
- объём выбирается без списка задач и истории обращений;
- в тарифе написано «безлимитно», но не определены границы;
- не указаны ставка, рабочее время и правила перерасхода;
- реакция выдаётся за гарантированный срок решения;
- нет отчёта по использованным часам;
- непонятно, переносятся ли остатки;
- любая задача объявляется входящей в пакет до её анализа.
Как контролировать тариф после старта
Через два-три месяца сравните план и факт: сколько часов ушло на обслуживание, развитие, ошибки и коммуникацию. Отдельно посмотрите, какие задачи повторяются. Повторяющиеся ручные операции иногда выгоднее автоматизировать, чем постоянно оплачивать.
Оптимальный пакет должен быть загружен достаточно, чтобы не превращаться в пустую подписку, но сохранять резерв на непредвиденное. Если расход стабильно ниже 50%, уменьшайте объём. Если выше 90% и задачи переносятся, увеличивайте пакет или сокращайте приоритеты.
Что отправить подрядчику для подбора
- ссылку на сайт и описание CMS;
- список задач за последние три месяца;
- план запусков на ближайший квартал;
- перечень интеграций;
- критичные функции и допустимый простой;
- желаемый режим работы;
- информацию о качестве кода и документации.
German Web сначала уточняет нагрузку и риски, а затем предлагает формат. Посмотреть условия можно на странице технической поддержки сайтов, а подробное сравнение тарифов — в статье о стоимости сопровождения.
Частые вопросы
Можно ли начать с минимального тарифа?
Да, если текущий поток задач укладывается примерно в семь часов и быстрый SLA не критичен. Через несколько месяцев пакет можно пересмотреть по фактической загрузке.
Что делать, если часов не хватило?
Новые задачи оцениваются отдельно, переносятся на следующий период либо согласуется увеличение пакета. Критичные работы не следует начинать без понимания доступного бюджета.
Нужно ли выбирать тариф по количеству страниц?
Нет. Важнее функции, интеграции, частота изменений и влияние простоя. Одностраничный сервис может быть технически сложнее большого информационного сайта.
Входит ли дизайн в расчёт часов?
Работа дизайнера учитывается отдельно по ставке 2 000 ₽ в час. Не каждой технической задаче нужен новый макет: часть изменений выполняется в существующей стилистике.
Можно ли переносить остаток?
В пакетах на 100 000 и 250 000 ₽ неиспользованные часы можно переносить до трёх месяцев.
Когда нужен пакет на 250 000 ₽?
Когда сайт постоянно развивается, имеет сложные интеграции, требует регулярного тестирования и быстрой реакции, а месячная нагрузка приближается к 100–125 часам.
