Договор на внедрение Битрикс24: что обязательно прописать

Большая часть конфликтов между заказчиком и специалистом по внедрению Битрикс24 возникает не из-за недобросовестности сторон, а из-за расплывчатого договора, который никто заранее не продумал до деталей. «Настроить CRM под ключ» — формулировка, которую можно трактовать десятком способов, и именно на этих расхождениях трактовок ломается доверие и портятся отношения на середине проекта. Разберём, что должно быть в договоре на внедрение вне зависимости от того, кто его составляет — специалист или сам заказчик.

Почему устные договорённости не работают даже с проверенным исполнителем

Даже при полном взаимном доверии стороны по-разному запоминают детали разговора двухнедельной давности. Через месяц работы заказчик уверен, что «мы же обсуждали интеграцию со складской программой», а исполнитель помнит это как «упомянули вскользь, но не включили в объём». Письменная фиксация — это не про недоверие к человеку, а про защиту от естественных ограничений памяти обеих сторон.

Раздел 1. Объём работ — самый важный и самый часто упускаемый пункт

Формулировка объёма работ должна перечислять конкретные результаты, а не общие направления.

• Плохая формулировка: «настройка CRM под нужды отдела продаж».
• Рабочая формулировка: «настройка одной воронки продаж с 6 статусами, настройка 12 пользовательских полей сделки, подключение телефонии одного оператора, настройка 3 автоматических уведомлений менеджерам, обучение отдела продаж в объёме 2 часов».
• Отдельным пунктом — что явно НЕ входит в объём работ (например, интеграция с 1С, разработка мобильного приложения, миграция данных из другой CRM) — этот пункт защищает обе стороны от споров о «подразумевалось ли это».

Раздел 2. Этапы и сроки

Разбивка проекта на этапы с промежуточной приёмкой каждого — это не бюрократия, а способ выявить недопонимание на ранней стадии, а не в конце проекта, когда переделка стоит дорого обеим сторонам.

1. 1.Этап предпроектного обследования и сбора требований — фиксированный срок, например 5-7 рабочих дней.
2. 2.Этап базовой настройки — воронки, поля, права доступа.
3. 3.Этап автоматизации — роботы, бизнес-процессы, интеграции.
4. 4.Этап обучения сотрудников и передачи документации.
5. 5.Этап гарантийного сопровождения после сдачи — обычно 2-4 недели бесплатных мелких правок.

Раздел 3. Порядок приёмки и критерии готовности

Договор должен описывать, как именно заказчик подтверждает, что этап принят: срок на проверку (например, 5 рабочих дней с момента передачи), формат обратной связи (акт, письмо, сообщение в оговорённом канале) и что происходит, если заказчик не ответил в срок — по умолчанию этап считается принятым, чтобы работа не зависала на неопределённое время из-за молчания одной стороны.

Раздел 4. Оплата и доступы

Разумная и распространённая на рынке схема оплаты — предоплата 30-50% перед стартом, оплата по завершении каждого крупного этапа и финальный расчёт после сдачи всего проекта. Полная предоплата 100% невыгодна заказчику, полная постоплата — исполнителю; поэтапная схема справедливо распределяет риск между сторонами.

• Отдельно нужно прописать, кому принадлежат административные доступы к аккаунту Битрикс24 после завершения проекта — по умолчанию это должен быть сам заказчик, а не исполнитель, чтобы избежать зависимости от одного человека.
• Прописать порядок передачи логинов и паролей, а также обязанность исполнителя не хранить чувствительные доступы дольше необходимого срока.
• Указать валюту и способ расчёта (безналичный перевод для ИП или самозанятого, реквизиты), а также, кто несёт налоговые обязательства по договору.

Раздел 5. Что происходит при изменении объёма работ по ходу проекта

Практически любой проект внедрения обрастает дополнительными пожеланиями заказчика в процессе работы — это нормально, но должно быть предусмотрено в договоре отдельным пунктом о дополнительных соглашениях: любое изменение объёма работ сверх изначально согласованного оформляется отдельным письменным соглашением с указанием новой стоимости и срока, прежде чем исполнитель приступает к этой работе.

Правило письменной фиксации изменений. Любая правка, которая не была в изначальном техническом задании, должна быть письменно согласована и оценена по стоимости до начала работы над ней — даже если это «просто добавить одно поле». Именно накопление таких «просто одна мелочь» без фиксации превращает проект с адекватным бюджетом в работу в убыток для исполнителя или в бесконечный проект без даты завершения для заказчика.

Раздел 6. Гарантийные обязательства и постпроектная поддержка

Стоит чётко разграничить два разных явления: исправление ошибок настройки, допущенных исполнителем (это гарантийные обязательства, обычно бесплатные в течение оговорённого срока, например месяца после сдачи), и доработка или расширение функциональности по новым пожеланиям заказчика (это уже новый оплачиваемый объём работ, а не гарантия).

Курс школы: Пакет «Полный»: роботы, бизнес-процессы и вебхуки в Битрикс24 — от 39 990 ₽

Раздел 7. Конфиденциальность и ответственность

В договоре стоит указать обязательство исполнителя не разглашать данные клиентской базы и внутренние бизнес-процессы заказчика третьим лицам, а также ограничение ответственности исполнителя — например, что он не несёт ответственности за потери, вызванные действиями сотрудников заказчика после сдачи проекта (неправильное использование системы, нарушение регламентов) или за сбои со стороны самой платформы Битрикс24, которые находятся вне его контроля.

Хороший договор не защищает одну сторону за счёт другой — он заранее отвечает на вопросы, которые иначе всплывут в середине проекта в виде конфликта.

Шаблон структуры договора коротко

• Предмет договора и общее описание проекта.
• Детальный объём работ по этапам с явным перечнем того, что не входит.
• Сроки по каждому этапу и порядок их переноса при форс-мажоре или задержке со стороны заказчика.
• Стоимость, порядок и график оплаты.
• Порядок приёмки и критерии готовности каждого этапа.
• Порядок согласования дополнительных работ.
• Гарантийные обязательства и их срок.
• Права на доступы и данные после завершения проекта.
• Конфиденциальность и ограничение ответственности.
• Порядок разрешения споров и реквизиты сторон.

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

Отказ обсуждать конкретику объёма работ и сроков на этапе договора — один из самых надёжных индикаторов будущих проблем в проекте. Разумная позиция — предложить компромисс в виде короткого, но конкретного технического задания как приложения к договору, даже если сам договор оформлен упрощённо (например, через договор оказания услуг для самозанятого). Полное отсутствие письменной фиксации объёма работ стоит рассматривать как повод отказаться от проекта или заложить существенный запас в цене на непредвиденные споры.

Разбор спорной ситуации из практики

Производственная компания на 60 человек заказала внедрение CRM у специалиста без подробного договора, ограничившись коротким письмом на почте с общим описанием задачи. В процессе работы заказчик несколько раз добавлял новые требования («а ещё нужно, чтобы...»), исполнитель соглашался устно, не фиксируя изменения объёма и стоимости. К концу проекта заказчик считал, что оплаченная сумма покрывает все добавленные по ходу пожелания, а исполнитель — что дополнительные работы должны быть оплачены отдельно. Спор занял три недели переговоров и завершился компромиссом с частичной доплатой, но обе стороны потеряли время и испортили отношения, которых можно было избежать одним письменным пунктом о порядке согласования изменений на старте.

Особенности договора при работе через самозанятость и ИП

Формат оформления влияет на содержание договора. Самозанятый работает по упрощённому договору оказания услуг физическим лицом и не может нанимать субподрядчиков для исполнения по этому же договору — если планируется привлекать помощников на проекте, это стоит обсуждать отдельно. ИП может заключать более широкий по формулировкам договор подряда или возмездного оказания услуг, указывать более сложные условия ответственности и штрафных санкций за просрочку, а также при необходимости работать с НДС по отдельной договорённости, если заказчик — крупная компания на общей системе налогообложения.

Штрафные санкции: стоит ли их включать и в каком объёме

Условие о штрафах за просрочку сроков со стороны исполнителя — обычная практика в договорах на внедрение, но важно, чтобы санкции были симметричны: если исполнитель платит неустойку за задержку по своей вине, договор должен также предусматривать, что срок сдвигается без штрафа, если задержка вызвана самим заказчиком (не предоставил доступы, не согласовал требования в разумный срок, не выделил сотрудника для тестирования на своей стороне). Разумный размер неустойки на рынке — 0,1-0,5% от стоимости этапа за каждый день просрочки, с ограничением максимального размера неустойки (например, не более 10% от стоимости этапа), чтобы избежать несоразмерных рисков для исполнителя за небольшую задержку.

• Прописывайте условия штрафа за просрочку симметрично для обеих сторон.
• Указывайте предельный размер неустойки, чтобы избежать несоразмерной ответственности.
• Отдельно фиксируйте, что считается началом отсчёта срока по каждому этапу — например, дата получения всех необходимых доступов и материалов от заказчика, а не дата подписания договора.

Приложения к договору, которые экономят время в будущем

Помимо основного текста договора полезно оформлять два коротких приложения. Первое — техническое задание с перечнем воронок, полей, ролей и автоматизаций, желательно с диаграммой или таблицей, а не только текстовым описанием — это снимает большинство споров о том, что именно подразумевалось под общей формулировкой. Второе — акт приёма-передачи по каждому этапу с конкретным перечнем принятых результатов и подписью обеих сторон (даже в форме простого обмена сообщениями с явным подтверждением) — этот документ становится решающим доказательством в случае будущего спора о том, был ли этап выполнен и принят.

Что стоит проверить заказчику перед подписанием

Заказчику, впервые заключающему договор на внедрение, стоит обратить внимание не только на объём и цену, но и на статус исполнителя (ИП, самозанятый, юридическое лицо) и на то, что происходит в договоре в случае, если исполнитель по каким-то причинам не сможет продолжить проект (болезнь, форс-мажор, полная невозможность исполнения обязательств) — разумный договор предусматривает возврат неотработанной части предоплаты или передачу наработанных материалов заказчику в таком случае, а не оставляет этот вопрос неурегулированным.

• Проверьте, что в договоре явно указан статус исполнителя и реквизиты для расчётов.
• Убедитесь, что описан порядок действий при невозможности исполнителя продолжить проект.
• Проверьте, что предоплата и её размер соответствуют разумной рыночной практике (обычно 30-50%), а не запрашивается полная сумма вперёд без объективных причин.