Запуск бота — это половина проекта. Дальше начинается жизнь: меняется бизнес, ломаются интеграции, выходят новые версии API, появляются ошибки, которые проявляются только на реальной нагрузке. Без понятного договора на поддержку любой инцидент превращается в торг. Разберем, как правильно оформить SLA на бота в MAX.
Что такое SLA и зачем он нужен
SLA (Service Level Agreement) — это формальное описание уровня сервиса. Для бота это:
- Доступность (uptime).
- Время реакции на инциденты.
- Время восстановления работоспособности.
- Часы поддержки (9/5, 24/7).
- Каналы связи для эскалации.
- Объем включенных работ.
Без SLA любой запрос превращается в «когда сможете — тогда сделаете». С SLA понятно, что считается инцидентом, кто и когда отвечает.
Категории инцидентов
Стандартная градация:
- Critical (P1). Бот не работает целиком: не отвечает, не принимает заявки, не отправляет уведомления. Выручка останавливается.
- High (P2). Часть функций сломана: оплата проходит, а уведомления не приходят. Бизнес работает, но с ограничениями.
- Medium (P3). Несущественные ошибки: текст не выровнен, кнопка ведет не туда.
- Low (P4). Запросы на улучшения и небольшие правки.
Для каждой категории — свой SLA по реакции и решению.
Типовые цифры SLA
Что обычно прописывают:
- P1: реакция — 30 мин, восстановление — до 4 часов в рабочее время.
- P2: реакция — 2 часа, решение — до 1 рабочего дня.
- P3: реакция — 1 рабочий день, решение — в плановом релизе.
- P4: обсуждается отдельно, идет в бэклог.
Эти цифры — отправная точка. Конкретные значения определяются критичностью бота для бизнеса. Если простой бота на 4 часа — это потеря 200 000 ₽ выручки, цифры P1 надо ужесточать.
Часы поддержки
Три типичных режима:
- 9/5 — рабочие часы рабочих дней. Подходит для B2B-ботов.
- 8/7 — каждый день в дневные часы. Подходит для розничных и сервисных ботов.
- 24/7 — круглосуточно. Нужно, если простой ночью критичен.
Очевидно, что 24/7 стоит дороже: нужно ночное дежурство, on-call инженер, бюджет на пейджинг. Прописывайте честно — иначе через месяц возникает спор «а почему вы не подняли в 3 ночи».
Что входит в поддержку
Стандартный минимум:
- Мониторинг и реагирование на инциденты.
- Исправление ошибок, выявленных в работающем функционале.
- Обновление зависимостей и реакция на изменения API MAX.
- Профилактические работы (бэкапы, обновления ОС).
- Ежемесячный отчет.
Что обычно идет отдельно:
- Разработка нового функционала.
- Существенные доработки сценариев.
- Новые интеграции.
Граница между «правкой бага» и «новой задачей» иногда размыта. Хорошая практика — раз в квартал ревизия скоупа поддержки и пересмотр условий.
Канал поддержки
Где ставятся задачи:
- Личный чат / email — для P3-P4. Удобно, фиксируется в переписке.
- Тикет-система (Jira, Yandex Tracker, Bitrix24) — для повторяющихся проектов.
- Телефон / отдельный чат — для P1-P2. Эскалация мгновенная.
Важно прописать: каждое обращение — через один канал, чтобы не терялось.
Ответственность исполнителя
Несколько пунктов, которые защищают бизнес:
- Гарантия после запуска (часто 30 дней).
- Передача знаний — документация, доступы, инструкции.
- Возврат кода — клиент имеет копию исходников.
- Резервный канал связи — если основной контакт недоступен.
- Ответственность за SLA — например, скидка на следующий месяц при нарушении.
Студия, которая не готова прописать ответственность за SLA, — повод задуматься.
Стоимость поддержки
Ориентиры:
- Базовая поддержка простого бота — от 5 000–15 000 ₽/мес.
- CRM-бот среднего объема — 20 000–60 000 ₽/мес.
- Корпоративный бот с интеграциями — 60 000+ ₽/мес.
Это не «чистые часы», а пакет: мониторинг + инциденты + мелкие правки. Крупные доработки — отдельно по часовой ставке.
Что не работает
Несколько паттернов, которых стоит избегать:
- Поддержка «по факту обращения» без SLA. Никаких гарантий — никакой ответственности.
- Безлимитные часы за фикс. Звучит привлекательно, но заканчивается перетягиванием каната.
- Поддержка только разработчиком. Уехал в отпуск — бот не поддерживается. Должна быть команда минимум из двух.
Итого
SLA на бота в MAX — это не бюрократия, а инструмент управления рисками. В договор обязательно включить категории инцидентов, время реакции, часы поддержки, канал эскалации и ответственность за нарушения. Стоимость поддержки — обычно 10–20% от стоимости разработки в год; экономия здесь почти всегда возвращается потерями при инцидентах.
Частые вопросы
Что такое SLA для бота в MAX и зачем он нужен?
SLA (Service Level Agreement) — формальное описание уровня сервиса. Для бота это: доступность (uptime), время реакции на инциденты, время восстановления работоспособности, часы поддержки (9/5, 24/7), каналы связи для эскалации, объём включённых работ. Без SLA любой запрос превращается в «когда сможете — тогда сделаете». С SLA понятно, что считается инцидентом, кто и когда отвечает. Это инструмент управления рисками, а не бюрократия — особенно когда простой бота напрямую связан с потерей выручки.
Какие категории инцидентов включают в SLA бота?
Стандартная градация четырёх уровней. Critical (P1) — бот не работает целиком: не отвечает, не принимает заявки, не отправляет уведомления, выручка останавливается. High (P2) — часть функций сломана: оплата проходит, а уведомления не приходят, бизнес работает с ограничениями. Medium (P3) — несущественные ошибки: текст не выровнен, кнопка ведёт не туда. Low (P4) — запросы на улучшения и небольшие правки. Для каждой категории — свой SLA по реакции и решению, иначе любой запрос превращается в P1.
Какие типовые цифры SLA для бота MAX?
Отправная точка по уровням. P1: реакция 30 мин, восстановление до 4 часов в рабочее время. P2: реакция 2 часа, решение до 1 рабочего дня. P3: реакция 1 рабочий день, решение в плановом релизе. P4: обсуждается отдельно, идёт в бэклог. Эти цифры — стартовые. Конкретные значения определяются критичностью бота для бизнеса. Если простой бота на 4 часа — это потеря 200 000 ₽ выручки, цифры P1 надо ужесточать вплоть до 5 минут реакции и часа восстановления, что сильно поднимает стоимость.
Какие часы поддержки выбрать для бота в MAX?
Три типичных режима. 9/5 — рабочие часы рабочих дней. Подходит для B2B-ботов и внутренних HR-сценариев. 8/7 — каждый день в дневные часы. Подходит для розничных и сервисных ботов с активностью пользователей по выходным. 24/7 — круглосуточно. Нужно, если простой ночью критичен (платежи, медицина, финтех). 24/7 стоит дороже из-за ночного дежурства, on-call инженера, бюджета на пейджинг. Прописывайте честно — иначе через месяц возникает спор «а почему вы не подняли в 3 ночи».
Что входит в стандартную поддержку бота, а что отдельно?
Стандартный минимум: мониторинг и реагирование на инциденты, исправление ошибок в работающем функционале, обновление зависимостей и реакция на изменения API MAX, профилактические работы (бэкапы, обновления ОС), ежемесячный отчёт. Отдельно идут: разработка нового функционала, существенные доработки сценариев, новые интеграции. Граница между «правкой бага» и «новой задачей» иногда размыта. Хорошая практика — раз в квартал ревизия скоупа поддержки и пересмотр условий с учётом изменений в продукте.
Сколько стоит поддержка бота MAX по SLA?
Ориентиры по типам ботов. Базовая поддержка простого бота — от 5 000–15 000 ₽/мес (мониторинг плюс инциденты плюс мелкие правки). CRM-бот среднего объёма — 20 000–60 000 ₽/мес. Корпоративный бот с интеграциями — 60 000+ ₽/мес. Это не «чистые часы», а пакет работ. Крупные доработки — отдельно по часовой ставке. Поддержка обычно 10–20% от стоимости разработки в год — экономия здесь почти всегда возвращается потерями при инцидентах. Лучше платить за поддержку, чем за восстановление с нуля после серьёзного бага.