Программа внедрена, сотрудники начали работать, а затем перестала проходить выгрузка данных. Заказчик рассчитывает, что исполнитель восстановит её в течение часа. Исполнитель считает, что обязан только принять обращение и поставить задачу в очередь. В договоре написано: «Оказывать техническую поддержку программного обеспечения».
Чтобы определить обязанности сторон, этой формулировки недостаточно. Нужно согласовать, какие системы обслуживаются, какие обращения входят в оплату, когда начинается отсчёт времени и что происходит, если проблему не удаётся решить в установленный срок.
В статье разберём договор технической поддержки ПО между компаниями и предпринимателями. Объясним, как связать его с SLA — соглашением об уровне обслуживания, — и какие условия стоит проверить заказчику, разработчику и интегратору.
Когда нужен отдельный договор технической поддержки
После разработки или внедрения программа продолжает меняться: появляются обновления, новые пользователи, интеграции и требования к инфраструктуре. Эти задачи желательно отделять от первоначального проекта.
Договор поддержки особенно полезен, если:
- исполнитель регулярно принимает обращения пользователей;
- заказчик платит ежемесячно за готовность обслуживать систему;
- требуется восстановление работы при сбоях;
- обновления и консультации входят в тариф, а доработки оплачиваются отдельно;
- поддержкой занимается другая компания, которая не разрабатывала продукт;
- несколько подрядчиков отвечают за программу, серверы и интеграции.
Не обязательно оформлять всё отдельным документом. Поддержку можно включить в основной договор, спецификацию или приложение. Важно, чтобы её условия были согласованы и не противоречили документам на разработку, внедрение и предоставление прав на ПО.
Если поддержка начинается после внедрения, определите момент перехода: подписан акт, завершена опытная эксплуатация или наступила другая согласованная дата. Иначе стороны могут одновременно спорить о незавершённом внедрении и об оплате обслуживания.
Что входит в поддержку, а что является отдельной работой
Слова «сопровождение программы» могут означать совершенно разный объём обязательств. Для одного исполнителя это консультации по электронной почте, для другого — круглосуточный мониторинг и аварийное восстановление.
В договоре стоит назвать программу, версию или поддерживаемую линейку версий, обслуживаемые модули, интеграции и среду размещения. Если есть тестовая и рабочая среды, укажите, распространяются ли одинаковые условия на обе.
| Задача | Что согласовать |
|---|---|
| Консультации пользователей | Темы, каналы, число обращений или иной предел объёма, круг пользователей |
| Разбор ошибок | Какие версии обслуживаются, как воспроизвести ошибку, кто предоставляет журналы и доступ |
| Восстановление работы | Какие действия выполняет исполнитель и в каких пределах отвечает за инфраструктуру |
| Обновления | Какие обновления входят в оплату, кто устанавливает их и проверяет совместимость |
| Доработки | Как согласуются задание, стоимость, сроки, приёмка и права на результат |
| Резервное копирование | Кто делает копии, что в них входит, где они хранятся и как проверяется восстановление |
Отдельно разграничьте исправление недостатков первоначальной разработки и новые платные задачи. Наличие договора поддержки само по себе не означает, что заказчик должен повторно оплачивать устранение недостатка, за который исполнитель уже отвечает по договору разработки.
Например, выгрузка перестала работать после обновления внешнего сервиса. Квалификация задачи зависит от причин: это может быть ошибка предусмотренного механизма, изменение стороннего API или новая интеграция. Правило «все изменения за дополнительную плату» не заменяет разбор обязательств сторон.
Для пограничных случаев полезен порядок диагностики: исполнитель сообщает предварительную причину, объясняет, почему считает задачу дополнительной, и согласует её до выполнения платных работ. Аварийные действия, которые можно выполнять без отдельного согласования, тоже лучше определить заранее.
Договор поддержки и SLA: в чём разница
Основной договор регулирует отношения сторон: предмет, оплату, права на результаты, конфиденциальность, ответственность и прекращение сотрудничества.
SLA описывает согласованный уровень обслуживания: категории обращений, сроки реакции и восстановления, режим работы, показатели доступности и порядок их измерения. Он может быть приложением или разделом договора. Для обычного коммерческого B2B-договора поддержки отдельный документ с названием SLA сам по себе не является универсальным обязательным требованием.
Юридическая конструкция зависит от содержания обязательств. Поддержка может сочетать услуги, абонентскую модель, создание доработок и предоставление прав. Название договора не определяет автоматически правила для всех этих частей.
Если документы составлены отдельно, установите их приоритет и порядок изменения. Особенно внимательно проверьте ссылки на тарифы и регламенты на сайте: какая редакция действует, как фиксируются изменения и вправе ли исполнитель менять показатели в течение оплаченного периода.
Какие сроки нужно разграничить в SLA
Главная ошибка — использовать один срок «решения обращения» для разных действий.
Регистрация обращения подтверждает, что заявка поступила в систему. Автоматическое письмо не обязательно означает, что специалист уже начал разбирать проблему.
Реакция специалиста — содержательный ответ или начало предусмотренных действий. В SLA нужно объяснить, что именно считается реакцией: назначение ответственного, запрос необходимых сведений, начало диагностики.
Восстановление работоспособности — возврат согласованной функции. Иногда этого можно добиться временным обходным решением.
Окончательное исправление — устранение причины ошибки. Оно может требовать выпуска новой версии и занимать больше времени, чем восстановление функции.
| Ситуация | Что важно закрепить |
|---|---|
| Основная функция полностью недоступна | Критерий критичности, аварийный канал, сроки реакции и восстановления |
| Часть операций не работает, но есть обходной путь | Критерии категории, допустимость временного решения и дальнейший порядок исправления |
| Есть ошибка без существенного влияния на работу | Срок ответа и порядок включения исправления в план работ |
| Пользователь просит изменить функциональность | Порядок оценки и согласования доработки вместо автоматического применения аварийных сроков |
Числовые значения следует выбирать с технической командой. Обещание восстановить любую проблему за час может оказаться невыполнимым, если для этого нужен доступ заказчика, ответ другого поставщика или изменение архитектуры.
Для каждой категории согласуйте, являются ли сроки обязательными или ориентировочными. Если указан только срок реакции, заказчик не получает из этого автоматического обязательства восстановить систему за тот же период.
Как учитывать рабочие часы и ожидание заказчика
Укажите часовой пояс, рабочие дни и часы поддержки. Отдельно решите, какие категории обслуживаются круглосуточно. Постоянная доступность сайта не означает круглосуточную работу специалистов поддержки.
Предусмотрите начало отсчёта и основания его приостановки. Например, для диагностики необходим журнал ошибки, который находится у заказчика. Нужно определить, какие сведения запросить, как подтвердить запрос, когда отсчёт приостанавливается и возобновляется.
Общее условие «срок не течёт при ожидании любой информации» создаёт пространство для споров. Причина ожидания должна быть связана с выполнением конкретной задачи. Недостаток сведений не всегда препятствует всем действиям по обращению.
Доступность сервиса: что означает показатель в процентах
Показатель доступности полезен, когда исполнитель контролирует работу сервиса или соответствующей части инфраструктуры. Если компания только консультирует пользователей программы, установленной на серверах заказчика, обещание общей доступности всей системы требует отдельной оценки.
Для расчёта можно использовать формулу:
Доступность = (время, включённое в расчёт, − учитываемый простой) / время, включённое в расчёт × 100%.
Сначала договоритесь, что именно измеряется. Открывающаяся главная страница ещё не подтверждает, что пользователь может войти в кабинет, создать документ и выполнить основную операцию.
В SLA определяют:
- расчётный период и часы, за которые измеряется доступность;
- функции и точки проверки;
- источник мониторинга и периодичность проверок;
- критерий начала и окончания простоя;
- порядок учёта частичной недоступности;
- исключения и подтверждающие их сведения;
- порядок проверки расхождений между данными сторон.
Условный пример: если учитываются все 30 суток месяца, это 43 200 минут. При доступности 99,9% соответствующий простой составляет 43,2 минуты. Это пример расчёта, а не универсальная рекомендуемая гарантия.
Плановые работы можно учитывать отдельно, но заранее определить их допустимую продолжительность, время проведения и срок уведомления. Исключение любых работ, которые исполнитель назвал «профилактикой», делает показатель малоинформативным.
Как направлять заявки и подтверждать их выполнение
Договор должен соответствовать фактическому процессу поддержки. Если заявки принимаются через сервис-деск, а аварийные обращения — по отдельному телефону, опишите оба канала и связь между ними.
Определите уполномоченных представителей заказчика. Сотрудник может иметь право сообщить об ошибке, но не заказывать доработку за дополнительную плату или принимать результат от имени компании.
Полезно согласовать обязательные сведения заявки: систему и среду, описание проблемы, время возникновения, затронутую функцию, шаги воспроизведения и контакт ответственного. При аварии предусмотрите возможность сначала сообщить минимум информации, затем дополнить обращение.
Для подтверждения выполнения используют историю заявки, отчёт, результаты проверки и, если предусмотрено, акт. В договоре нужно связать эти документы: закрытие заявки в технической системе не всегда означает юридическую приёмку всего месячного объёма.
Если устанавливается приёмка при отсутствии возражений, важно определить способ направления отчёта, срок проверки и содержание мотивированных замечаний. Исполнителю потребуется подтверждение, что документы действительно направлены согласованным способом.
Как согласовать оплату поддержки
Модель расчётов должна объяснять, что именно оплачивает заказчик.
| Модель | Что проверить |
|---|---|
| Абонентская плата | За какую готовность и какой объём обслуживания вносится платёж, какие ограничения действуют |
| Почасовая оплата | Ставки, правила учёта времени, минимальные интервалы, лимит бюджета и согласование превышения |
| Оплата отдельных заявок | Оценка стоимости, согласование задания и подтверждение выполнения |
| Комбинированная модель | Что входит в базовую плату и как оплачиваются дополнительные задачи |
При ясно согласованной абонентской модели отсутствие обращений само по себе обычно не освобождает от оплаты: заказчик платит за право потребовать предусмотренное обслуживание. Это не означает, что исполнитель вправе получать плату, не обеспечивая согласованную готовность.
Если включён определённый объём часов, уточните, что в него засчитывается: диагностика, переписка, встречи, подготовка отчёта. Решите, переносятся ли остатки и как согласуется превышение. Сам факт ежемесячной оплаты не устанавливает автоматически ни безлимитную поддержку, ни обязательное сгорание остатка.
Для сторонних расходов предусмотрите отдельный порядок: лицензии, услуги облака, выезд специалистов. Налоговые условия оплаты также согласуются применительно к сторонам и составу предоставления; нельзя автоматически переносить режим лицензии на всё сопровождение.
Ответственность за нарушение SLA
Показатели обслуживания должны быть связаны с последствиями их нарушения. Это могут быть неустойка, уменьшение платы, зачёт в следующем периоде, возмещение убытков в допустимых пределах или право прекратить договор при повторяющихся нарушениях.
Сервисный кредит — согласованный зачёт или уменьшение стоимости — нужно описать предметно: основание, расчёт, порядок заявления и использования. Само название не означает, что заказчик утрачивает остальные требования. Соотношение мер защиты зависит от договора и применимых правил.
В B2B-договоре стороны могут обсуждать предел ответственности, расчётную базу, исключения и порядок предъявления требований. Но заранее исключить или ограничить ответственность за умышленное нарушение нельзя.
Отдельно оцените потерю данных, нарушение конфиденциальности и прав третьих лиц. Один общий лимит может оказаться неприемлемым для заказчика, а неограниченная ответственность при небольшой абонентской плате — для исполнителя.
Сбой поставщика облака или внешнего API не становится автоматически форс-мажором. Нужно установить, кто выбрал поставщика, кто отвечает за взаимодействие с ним, какие зависимости раскрыты и какие действия должен выполнить исполнитель при аварии.
Доступ к данным, резервные копии и права на доработки
Поддержка нередко требует доступа к рабочей базе. Соглашение о конфиденциальности полезно, но само по себе не оформляет все вопросы обработки персональных данных.
Нужно определить роли сторон и основания доступа. Если исполнитель обрабатывает данные по поручению заказчика, оформляют соответствующие условия: состав сведений и операций, цели, требования безопасности, подтверждение выполнения обязанностей и уведомление об инцидентах. Подробнее — в статье о передаче персональных данных подрядчику.
Практически стоит согласовать персональные учётные записи специалистов, разрешённые действия, порядок выдачи и отзыва доступа. Если используются субподрядчики или внешние сервисы, проверьте допустимость их участия. Загрузку рабочей базы в сторонний инструмент нельзя оправдать только удобством диагностики.
Резервное копирование и восстановление разграничивают: наличие копии ещё не подтверждает возможность быстро вернуть систему в работу. Определите допустимую потерю данных по времени, срок восстановления, глубину хранения и порядок проверки копий. Обязанности по настройке и проверке должны иметь конкретного исполнителя.
Если в ходе поддержки создаётся новый код, заранее решите вопросы прав на него. Кто и на каком основании сможет использовать доработку, какие материалы передаются, что остаётся у исполнителя, какие сторонние компоненты применяются? Оплата счёта за «сопровождение» не заменяет согласования этих вопросов.
Что предусмотреть при прекращении поддержки
До подписания договора полезно обсудить и завершение работы. Особенно если только исполнитель хранит актуальную документацию, управляет сервером или знает настройки интеграции.
Определите:
- порядок уведомления и дату прекращения обслуживания;
- расчёты за последний период и незавершённые задачи;
- передачу документации, настроек и материалов в согласованном составе;
- выгрузку данных, если она входит в обязанности исполнителя;
- отзыв доступов и удаление копий с учётом законных оснований хранения;
- условия переходной помощи новому подрядчику.
Приостановку поддержки из-за неоплаты также нужно описать: уведомление, срок устранения нарушения, действия по открытым аварийным обращениям. Прекращение поддержки, отключение доступа к SaaS и прекращение лицензии — разные последствия; их связь должна следовать из согласованных условий.
Правила одностороннего отказа зависят от состава договора и статуса сторон. Условие о невозврате любых платежей или о немедленном прекращении всех обязательств требует отдельной проверки.
Подготовка договора поддержки и SLA в «Софисте»
Помогаем заказчикам, разработчикам, поставщикам сервисов и интеграторам согласовать поддержку с реальным процессом работы. Можно подготовить документы с нуля, проверить проект контрагента или переработать действующий договор.
Сначала выясняем, какая система обслуживается, где она размещена, кто отвечает за инфраструктуру и как работает поддержка. Затем обсуждаем с технической командой измеримые показатели и фиксируем юридические условия: объём, заявки, расчёты, приёмку, ответственность, данные и прекращение сотрудничества.
Состав результата согласовываем заранее. В зависимости от задачи это основной договор, SLA, перечень поддерживаемых систем, формы заявок и отчётов, условия обработки данных и рекомендации по применению документов. Отдельно определяем, входит ли согласование с контрагентом.
Форматы работы и стоимость
| Формат | Стоимость | Что согласуем в составе работы |
|---|---|---|
| Юридическая консультация | 5 000 руб./час | Разбор ситуации, спорных условий и возможных решений |
| Подготовка IT-договора | От 30 000 руб. | Договор под согласованную модель; объём SLA и других приложений определяем при оценке |
| Переговоры и встречные правки | От 20 000 руб. | Анализ предложений контрагента, аргументы и альтернативные условия; участие в обсуждениях — по согласованию |
| Абонентское юридическое сопровождение | От 59 000 руб. в месяц | Регулярная работа с договорами и текущими юридическими задачами в согласованном объёме |
Проверка готового договора и подготовка комплекса документов оцениваются после знакомства с материалами. Начальная стоимость IT-договора не означает, что в неё автоматически входит любое количество приложений и переговоров. До начала работы фиксируем результат, цену и сроки; дополнительные задачи согласуем отдельно.
Работаем из Казани с клиентами по всей России дистанционно. Подробнее — договоры и юридические документы и услуги для IT-компаний.
Практика сопровождения цифровых продуктов
В одном из проектов мы помогали подготовить к запуску веб-сервис для работы с 3D-моделями: анализировали бизнес-модель, сопровождали регистрацию программы, готовили пользовательское соглашение, SaaS-лицензию и документы по персональным данным.
В договоре для SaaS-продукта определяли права и обязанности сторон, оплату, продление лицензии и ограничения ответственности. Этот пример показывает, почему документы сервиса важно согласовывать между собой. Полный кейс — юридическое оформление IT-стартапа для запуска веб-сервиса.
Другие примеры работы — в разделе «Кейсы».
Благодарственные письма клиентов
Отзывы о сотрудничестве с практикой:
ИИ-сервис Mindly
ООО «МАНТЛ КОД»
Сведения о практике и другие письма — на странице «О нас».
Часто задаваемые вопросы
SLA обязательно делать отдельным приложением?
Нет. Условия уровня обслуживания можно включить в договор. Отдельное приложение удобно, если показатели различаются по тарифам или системам. В любом случае нужно определить, какая редакция согласована и как её изменять.
Нужно ли платить за поддержку, если обращений не было?
При согласованной абонентской модели обычно да: оплачивается право потребовать предусмотренное обслуживание. Но исполнитель должен обеспечивать договорную готовность. Если договор предусматривает расчёты за выполненные заявки или фактическое время, применяется соответствующая модель.
У нас уже есть договор разработки. Можно дополнить его поддержкой?
Да, если действующая конструкция позволяет последовательно описать новый этап. Проверим условия разработки, исправления недостатков, прав и оплаты. Иногда достаточно приложения, иногда удобнее отдельный договор — это определяем по содержанию документов.
Можно заказать только проверку договора заказчика?
Да. Можно разобрать проект, выделить существенные риски и подготовить правки к приоритетным условиям. Если требуется переговорный этап, его объём согласуем отдельно. Полное переписывание документа нужно не во всех ситуациях.
Кто должен выбирать сроки реакции и восстановления — юрист или технический специалист?
Техническая команда оценивает возможности обслуживания и зависимости. Юрист помогает превратить их в определённые обязательства: начало отсчёта, исключения, подтверждение выполнения и последствия нарушения. Мы не подменяем технический аудит и не назначаем сроки без обсуждения с командой.
Мы находимся в другом регионе. Можно подготовить документы дистанционно?
Да. Для договорной работы можно передать материалы электронно и обсудить процессы с ответственными сотрудниками. До начала согласуем, какие сведения нужны и кто участвует в обсуждении технических условий.
Что делать, если после передачи договора контрагент пришлёт замечания?
Разберём предложенные изменения и их влияние на ваши обязательства. Порядок доработки проекта и участие в согласовании фиксируем в составе услуги. Если переговоры выходят за согласованный объём, дополнительные действия и стоимость обсуждаем до их выполнения.