Критерии выбора
После успешного релиза мобильного приложения, SaaS-платформы, личного кабинета, крупного интернет-магазина или корпоративного портала поддержка выделяется в самостоятельную услугу. Это уже не этап «доделать проект по ТЗ», а процесс обеспечения непрерывной работоспособности продукта: исправление скрытых дефектов, обновление уязвимых компонентов, мониторинг, реакция на инциденты и выпуск минорных релизов.
В современных реалиях цифровые продукты критически зависят от внешней инфраструктуры: облачных хранилищ, платежных шлюзов, CRM-систем, сервисов push-уведомлений, SMS-провайдеров, обновлений мобильных ОС (iOS, Android) и сторонних API. Даже если исходный код написан безупречно, фатальный сбой может произойти из-за отзыва SSL-сертификата, изменения политики Apple/Google или ошибки на стороне хостинг-провайдера.
Качественный договор поддержки должен давать однозначные ответы на пять ключевых вопросов:
Подробнее на эту тему — Сравнить платёжные шлюзы для мобильного приложения с подпис….
1. Что конкретно находится на поддержке: мобильные клиенты, backend-часть, база данных, интеграционные шины, админ-панель, серверная инфраструктура.
2. Как быстро реагирует команда: в течение 15 минут, 1 часа, 4 часов или только на следующий рабочий день после обращения.
3. Когда инцидент должен быть устранен: зафиксирован ли жесткий срок восстановления работоспособности (Resolution Time), а не только время первого ответа (Response Time).
Подробнее на эту тему — Безопасность покупок: как распознать фишинг на маркетплейса….
4. Какова финансовая модель: фиксированная абонентская плата, пакет включенных часов, ставка Time & Material сверх лимита, коэффициенты за работу в выходные и праздники.
5. Что грозит подрядчику за нарушение: штрафные санкции, сервисные кредиты (скидки на следующий период), бесплатные часы разработки или иная материальная компенсация.
Таблица проверки договора поддержки
| Что обязательно проверить | Как должно быть сформулировано в договоре | Риск для заказчика, если пункта нет |
|---|---|---|
| Состав сервиса | Детально перечислены модули: iOS/Android приложения, backend, сайт, интеграции (1С, CRM), серверы. | Подрядчик откажется чинить спорный компонент, сославшись на то, что он не входит в контур поддержки. |
| SLA (Уровень сервиса) | Прописаны уровни критичности (от P1 до P4), точные сроки реакции и полного восстановления. | Поддержка будет оказываться в режиме «best effort» (по мере возможности), без гарантий сроков. |
| Канал постановки задач | Указана конкретная система (Jira, YouTrack, Helpdesk) с автоматической фиксацией времени тикета. | Невозможно доказать факт и точное время обращения при расчете штрафов за простой. |
| Время реакции | P1 (Критичный) — 15–30 минут; P2 — 1–2 часа; P3 — 4–8 часов. | Команда может взять критическую заявку в работу только к концу дня. |
| Время восстановления | P1 — 2–4 часа; P2 — до 1 рабочего дня; P3 — 2–5 рабочих дней. | Быстрый ответ «Заявка принята» не гарантирует, что сервис починят в обозримом будущем. |
| График работы | Четко указано: 5/2 (с 9 до 18), 12/7 или 24/7. Описан регламент для выходных и праздников. | Сервис, упавший в пятницу вечером, пролежит до утра понедельника. |
| Тарификация | Указана сумма абонентской платы, расчетный период, количество включенных часов и порядок биллинга. | Возникновение непредсказуемых счетов за «скрытые» работы. |
| Ставки сверх лимита | Зафиксирована стоимость 1 часа по ролям: Senior/Middle разработчик, QA, DevOps, Project Manager. | Любые доработки сверх пакета будут оцениваться по завышенным тарифам. |
| Гарантийные обязательства | Указан срок гарантии на новые релизы (например, 30-90 дней) и критерии гарантийного бага. | Ошибки, допущенные самим подрядчиком, будут исправляться за счет платных часов заказчика. |
| Исключения из SLA | Описан закрытый перечень: падение чужих API, сбои дата-центра, действия сотрудников заказчика. | Подрядчик сможет снять с себя ответственность практически за любой инцидент. |
| Ответственность | Предусмотрены штрафы, сервисные кредиты (например, возврат до 30% абонентской платы за простой). | Длительная недоступность сервиса принесет бизнесу убытки, которые никто не компенсирует. |
| Управление доступами | Описан регламент хранения паролей, выдачи прав и срок возврата всех доступов при расторжении (до 3 дней). | Заказчик может стать заложником подрядчика и потерять контроль над собственным IT-продуктом. |
SLA: какие сроки считать рабочими
SLA (Соглашение об уровне сервиса) — это не абстрактная формулировка «исполнитель обязуется оказывать услуги своевременно». Это математически точный документ.
Практичная и рабочая классификация инцидентов выглядит следующим образом:
* P1 (Критичный): Полная остановка бизнес-процессов. Сервис недоступен, не проходят онлайн-платежи, приложение крашится при запуске у 100% пользователей. *Реакция: 15–30 минут. Восстановление: 2–4 часа.*
* P2 (Высокий): Не работает важный функционал, но система в целом жива. Сломана авторизация для части пользователей, не работает оформление заказа определенным способом, отвалилась интеграция со складом. *Реакция: 1–2 часа. Восстановление: до 1 рабочего дня.*
* P3 (Средний): Ошибка в отдельном сценарии, для которой существует обходной путь (workaround). Некорректно отображается верстка на редком устройстве, не выгружается один из типов отчетов. *Реакция: 4–8 часов. Восстановление: 2–5 рабочих дней.*
* P4 (Низкий): Косметические дефекты, опечатки, консультации по использованию админки, мелкие настройки. *Реакция: 1 рабочий день. Восстановление: в рамках плановых релизов.*
Важно: В договоре необходимо жестко разделять понятия. *Время реакции* — это момент, когда живой специалист (а не автоответчик) начал диагностику. *Время временного решения* — когда найден обходной путь и сервис запущен. *Время полного исправления* — когда баг устранен в коде и выкачен на «прод».
Оплата поддержки: что проверить в тарифах
Оплата должна быть абсолютно прозрачной. На рынке цифровых сервисов преобладают две основные модели.
1. Абонентская поддержка (Retainer)
Подходит для высоконагруженных сервисов, где простой напрямую ведет к потере выручки.
* Базовый мониторинг и поддержка (без жесткого SLA 24/7): 40 000 – 90 000 ₽ в месяц.
* Поддержка с регулярными релизами, DevOps и SLA: 100 000 – 250 000 ₽ в месяц.
* Круглосуточная поддержка (24/7) сложных B2B/FinTech продуктов: от 300 000 до 800 000 ₽+ в месяц.
Обычно в абонентскую плату включен пакет часов (например, 20, 40 или 80 часов в месяц). Проверьте в договоре: сгорают ли неиспользованные часы в конце месяца или переносятся на следующий? Какова минимальная единица тарификации (списание по 15 минут или округление до часа)?
2. Почасовая оплата (Time & Material)
Подходит для стабильных, редко обновляемых проектов (корпоративные сайты, внутренние порталы с низкой нагрузкой). Вы платите только за фактически затраченное время по ставке, например, 2 500 – 5 000 ₽ за час. Минус модели — у вас нет гарантированного приоритета. Если у подрядчика аврал на другом проекте, вашу задачу могут отложить.
Сравнение вариантов
| Модель поддержки | Для каких проектов подходит | Главный плюс | Главный минус и риск |
|---|---|---|---|
| Гарантийная поддержка | Продукт только что сдан, идет период стабилизации (первые 1-3 месяца). | Бесплатно для заказчика (в рамках ТЗ). | Подрядчик будет пытаться признать любой баг «новым требованием», чтобы выставить счет. |
| Почасовая (T&M) | Редкие задачи, контентные правки, сервис не критичен для ежедневной выручки. | Экономия бюджета, оплата только по факту. | Нет жесткого SLA. В случае аварии реакция может занять несколько дней. |
| Абонентская 8/5 | Стандартные сервисы, работающие в бизнес-время (B2B порталы, CRM). | Прогнозируемый бюджет, выделенная команда, SLA. | Сбои, произошедшие ночью или в выходные, начнут чинить только утром в понедельник. |
| Абонентская 24/7 | E-commerce, финтех, медицина, логистика, сервисы такси и доставки. | Максимальная защита бизнеса, дежурные инженеры, мониторинг 24/7. | Высокая стоимость. Требует сложной настройки алертов и регламентов эскалации. |
Риски: что может пойти не так
* Вендор-лок (Vendor Lock-in): Подрядчик регистрирует домены, сервера и аккаунты разработчика (App Store / Google Play) на свое имя. При попытке сменить команду вы теряете продукт. *Решение:* Все аккаунты должны быть зарегистрированы на юрлицо заказчика.
* Формальные отчеты: В конце месяца вы получаете акт на «Услуги техподдержки — 100 000 руб.» без расшифровки. *Решение:* Требуйте выгрузку из Jira/Helpdesk с указанием номера тикета, сути проблемы, ФИО исполнителя и затраченного времени с точностью до минут.
* Слепая зона внешних интеграций: Отвалился шлюз банка, а поддержка разводит руками. *Решение:* В матрице ответственности должно быть указано, что при сбое внешнего API подрядчик обязан провести диагностику, локализовать проблему и самостоятельно связаться с саппортом банка от лица заказчика.
Когда договор поддержки не подходит
Договор технической поддержки категорически не подходит, если под видом «сопровождения» фактически планируется масштабная новая разработка.
Если вам требуется провести крупный редизайн интерфейса, внедрить новую ролевую модель пользователей, разработать личный кабинет с нуля, изменить логику проведения платежей, провести глубокий рефакторинг архитектуры или мигрировать продукт на совершенно другой фреймворк (например, переписать приложение с React Native на Swift/Kotlin) — это не поддержка.
В таких случаях необходимо заключать полноценный Договор на разработку программного обеспечения. Для него потребуются новые предпроектные исследования, написание подробного Технического задания (ТЗ), проектирование архитектуры, оценка по методологии Waterfall или Agile, а также отдельные этапы тестирования и приемки. Попытка «впихнуть» создание новых крупных модулей в рамки абонентских часов техподдержки приведет к срыву сроков, перерасходу бюджета и конфликту из-за отсутствия четких критериев приемки результата.