Максим Носарев

CEO & Founder в Tretten Lawyers

Договор SLA регулирует отношения по эксплуатации конкретного готового продукта. Но хочу сразу обратить внимание, что это касается в первую очередь сервисных компаний.

Если компания продает свой продукт, то правовая природа отношений с клиентом регулируется обычно Terms of Use, а не SLA.

А если компания занимается техническим саппортом продукта для заказчика, то без SLA просто не обойтись.

Но чтобы договор об уровне обслуживания по-настоящему давал эффект, он должен быть максимально кастомным, сделан по индивидуальному заказу.

Founder & СЕО в Tretten Lawyers Максим Носарев делится опытом составления SLA: что надо обязательно включать применительно к IT бизнесу.

Обратите внимание на другие статьи Kraftblick.Media, посвященные юридическим аспектам IT бизнеса:

Как IT компаниям зарабатывать больше, правильно применяя контракты Fixed Price и Time & Material.

Как составить договор с сотрудником в IT, чтобы защитить компанию.

Безопасные продажи: как сейлзу проверить IT контракт.

Договор аутстаффинга: чем отличается от Time & Material и что в него нужно включать.

В этой статье вы прочитаете:

• Ключевые условия SLA, одинаково важные для обеих сторон
• Список услуг
• Уровни критичности запроса клиента
• Время реакции исполнителя
• Финальное разрешение запроса
• Список команды
• Метрики качества услуг
• Рабочее время предоставление сервиса
• Цена и условия оплаты
• Масштабы поддержки
• К чему приведут ошибки при составлении SLA

Ключевые условия SLA, одинаково важные для обеих сторон

Договор об уровне обслуживания надо заключать перед началом сотрудничества, иначе проблем не избежать.

Да, он во многом индивидуален, но все равно есть ряд стандартных пунктов, которые, по моему опыту, важно всегда включать.

О них и расскажу далее.

Список услуг

Речь не только о видах и категориях услуг (например, “компьютерное программирование”), а о каждой конкретной услуге. 

Ее важно ювелирно прописать.

Возьмем пример с мобильным приложением.

Одно может быть качественно написано, с логичным и красивым программным кодом. А другое — экономвариант, собранное индусами на коленке из программных костылей.

У каждого их них будет свой договор на обслуживание и, как показывает практика, количество предоставляемых услуг тоже будет отличаться.

Потому что во втором варианте намного больше потенциальных рисков.

Клиент готов ежемесячно вносить плату за обслуживание предоставленного IT компанией продукта, он заинтересован в том, чтобы все работало.

А исполнитель соглашается решать возникающие проблемы за фиксированную плату.

Но тут обеим сторонам надо понять, что именно будет входить в список услуг.

Заказчик может несколько месяцев платить абонплату, но при этом у него не возникнет никаких проблем.

Но может случится и так, что ему срочно понадобится решение сверхсложной задачи, которое отнимет у исполнителя слишком много ресурсов. 

Чтобы избежать подобных казусов, надо каждую услугу максимально описывать в договоре.

А до этого предусмотреть все возможные варианты развития события.

Тогда и заказчику будет ясно, какой сервис он получит, и исполнитель будет знать, какой сервис он обязан предоставлять.

Идеальный вариант для SLA: когда имеется раздел “Определения”, в котором прописано, в чем заключается каждая конкретная услуга.

Уровни критичности запроса клиента

Узнавайте о новых статьях на Kraftblick.Media!