guides
Как составить договор на разработку чат-бота на заказ
Расплывчатый договор на чат-бота ведёт к бесконечному расширению задач и неоплаченным правкам. Вот какие пункты нужно включить, чтобы оплата, объём работ и права собственности были чётко зафиксированы.
Клиент просит «ещё одну маленькую правку» уже четвёртую неделю подряд. Вы уже сдали бота, выставили счёт и перешли к следующему проекту — только на самом деле нет, потому что в договоре так и не было прописано, что именно значит «готово».
Это происходит постоянно в разработке чат-ботов, потому что результат кажется простым («просто бот, который отвечает на вопросы»), но объём работ на деле резиновый. Каждая интеграция, каждый нестандартный случай, каждый запрос «а можно ещё X» либо попадает в рамки вашего договора, либо выходит за них. Если в договоре не прописано, что есть что, — вы работаете бесплатно.
Какие пункты нужны в договоре на разработку чат-бота?
Надёжный договор на разработку чат-бота на заказ должен содержать как минимум 7 ключевых пунктов: объём работ, результаты и критерии приёмки, график платежей, лимит правок, сроки с этапами (milestones), условия по правам интеллектуальной собственности и условия поддержки после запуска. Пропустите хотя бы один — и вы будете вести переговоры уже после того, как работа сделана, а это худший момент для переговоров.
Думайте о договоре как о документе, который отвечает на любой спор ещё до того, как он возник. Если разногласие можно разрешить только вопросом «а о чём мы вообще договаривались?», а ответа в письменном виде нет — вы уже потеряли рычаг влияния.
Как определить объём работ так, чтобы он не расширялся незаметно?
Расширение объёма работ (scope creep) — главный убийца маржи в проектах по чат-ботам. Решение — не расплывчатые формулировки вроде «создать бота поддержки», а пронумерованный список того, что бот делает и чего не делает.
Перечислите каждый сценарий диалога по названию. «Проверка статуса заказа», «запрос на возврат», «резервный ответ на частые вопросы» — а не «функциональность поддержки клиентов».
Явно назовите каждую интеграцию. Синхронизация с CRM, платёжный шлюз, конкретные API-эндпоинты — всё, что не названо, выходит за рамки договора.
Ограничьте количество интентов или сценариев, включённых в базовую цену. Распространённая схема: до 15 определённых интентов включены, дополнительные интенты оплачиваются по фиксированной ставке за штуку.
Определите, что считается «правкой», а что — «новой функцией». Исправление сломанного сценария — это правка. Добавление сценария, которого не было в исходном ТЗ, — это дополнительный заказ (change order).
Приложите документ с требованиями как приложение к договору. Договор должен ссылаться на него напрямую, а не просто описывать проект в свободной форме.
Если вы ещё не зафиксировали требования в письменном виде перед составлением договора, сделайте это в первую очередь — см. как составить документ с требованиями для разработки Telegram-бота клиенту. Договор должен ссылаться на этот документ как на источник истины по объёму работ.
Сколько раундов правок стоит включить?
Большинство договоров на чат-ботов включают 2-3 раунда правок в базовую цену, а каждый дополнительный раунд оплачивается отдельно — почасово или по фиксированной ставке. Фраза «неограниченные правки» никогда не должна появляться в договоре — это открытое приглашение к тому, чтобы проект никогда не заканчивался.
Определите раунд правок конкретно: клиент проверяет сданного бота на соответствие согласованному ТЗ, присылает обратную связь одним сводным документом в установленный срок (обычно 5-7 рабочих дней), а вы вносите исправления в согласованные сроки. Фидбэк, присылаемый по частям в течение нескольких недель, не считается «одним раундом» — пропишите это явно.
Как правильно структурировать этапы оплаты?
Распространённая и справедливая структура для проектов по чат-ботам делит оплату на три или четыре этапа, привязанных к конкретным результатам, а не к календарным датам:
Депозит (30-50%) — оплачивается при подписании, до начала любых работ. Это отсеивает несерьёзных клиентов и покрывает ваше время, если проект застопорится на раннем этапе.
Промежуточный этап (25-30%) — оплачивается, когда сценарии диалогов построены и тестируются в стейджинг-окружении.
Этап перед запуском (10-20%) — оплачивается после того, как клиент одобрит финальную протестированную версию.
Финальный платёж (остаток) — оплачивается при запуске или передаче проекта, с чётко обозначенным грейс-периодом (7-15 дней с момента выставления счёта).
Привязывайте каждый этап к конкретному, проверяемому результату — а не к «неделе 2» или «неделе 4». Этапы, привязанные к календарю, провоцируют споры о том, действительно ли вы их выполнили; этапы, привязанные к результату, — нет.
Перед тем как перейти к предзапусковому этапу, вам понадобится полноценный QA-прогон — см. как протестировать сценарий диалога чат-бота перед сдачей клиенту и как настроить стейджинг-окружение для Telegram-бота перед запуском — это процесс, который должен идти непосредственно перед этим платёжным этапом.
Кому принадлежит бот, код и данные после запуска?
Права на интеллектуальную собственность должны быть прописаны явно, а не подразумеваться. По умолчанию в большинстве фриланс-/агентских договоров клиент становится владельцем финального результата после полной оплаты — но «результат» нужно точно определить.
Кастомный код и сценарии диалогов, созданные специально для этого клиента, обычно переходят к нему после финального платежа.
Переиспользуемые фреймворки, шаблоны или внутренние инструменты, созданные до этого проекта (или предназначенные для использования в других проектах), должны оставаться вашими — пропишите это явно, иначе вам придётся каждый раз заново собирать свой инструментарий.
Сторонние платформы и лицензии (CRM, хостинг, любой платный API) остаются собственностью соответствующих поставщиков — клиент лицензирует использование, а не покупает платформу.
Данные клиента, собранные через бота, принадлежат клиенту — и точка. Пропишите это явно, особенно если вы работаете с чем-то чувствительным.
Что происходит после запуска — кто отвечает за баги?
Определите гарантийный период на исправление багов отдельно от любого текущего абонемента на поддержку. Типичная схема: 14-30 дней бесплатного исправления багов после запуска для дефектов в функциях, входивших в исходный объём работ, а всё остальное (новые функции, изменения сторонних API, текущее обслуживание) оплачивается по отдельному договору на поддержку.
Это также момент, когда стоит определить сам процесс передачи проекта — кто получает доступ администратора, кто получает документацию, и как внутренняя команда клиента берёт на себя мониторинг. Если вы ещё это не проработали, статья как передать готовый проект чат-бота внутренней команде клиента подробно описывает, что нужно включить.
Если вы ведёте текущую работу бота и отслеживание лидов через свой собственный CRM-стек, а не передаёте всё «вхолодную», отразите это в договоре тоже — включая то, у кого есть доступ к данным диалогов и дашбордам аналитики во время и после сотрудничества. Статью как настроить аналитику для отслеживания конверсии чат-бота клиента стоит прочитать перед тем, как писать этот пункт, поскольку она определяет, что на практике означает владение данными.
Стоит ли упоминать в договоре используемый техстек и платформы?
Да — назовите конкретные инструменты, а не просто «CRM» или «AI-модель». Если вы создаёте бота в Telegram и ведёте лидов через CRM-слой, назовите оба. Это защищает вас, если клиент позже заявит, что ожидал другую платформу, и защищает его, давая чёткое понимание того, от чего он зависит.
Если ваш рабочий процесс включает управление Telegram-стороной через CRMChat, стоит отметить в договоре, что данные о лидах и история переписок хранятся там на протяжении сотрудничества. Центр помощи CRMChat описывает процесс настройки, если клиент захочет разобраться в деталях перед подписанием.
Что должен охватывать пункт о расторжении договора?
Каждому договору нужен «выход» для обеих сторон. Охватите следующие моменты:
Срок уведомления — обычно 7-14 дней письменного уведомления для расторжения без указания причины.
Оплата за выполненную работу — клиент оплачивает все этапы, завершённые до даты расторжения, пропорционально, если расторжение произошло в середине этапа.
Компенсация за досрочное расторжение (kill fee) — фиксированная сумма (часто 10-20% от оставшейся стоимости договора), если клиент расторгает договор без причины после начала работ.
Возврат материалов — какой код, доступы и документация передаются при расторжении, независимо от причины.
Без этого пункта досрочное расторжение превращается в переговоры с нуля — именно в тот момент, когда у вас меньше всего рычагов влияния и больше всего вложенных усилий.
Часто упускаемые пункты, которые стоит добавить
Условия конфиденциальности / NDA — особенно если бот затрагивает данные клиентов или закрытую бизнес-логику.
Перекладывание расходов на сторонние API — если бот зависит от платной AI-модели или мессенджерского API, чётко пропишите, кто оплачивает эти текущие расходы.
Процесс дополнительных заказов (change order) — простая процедура из одного абзаца о том, как оцениваются и утверждаются запросы на новые функции, чтобы «а можно ещё добавить...» имело понятный путь, а не срывало сроки.
Применимое право и разрешение споров — даже одно предложение с указанием юрисдикции сэкономит реальные деньги, если что-то пойдёт не так.
Настолько детальный договор может показаться избыточным для «простого бота» — пока в почту не придёт третий запрос на расширение объёма работ. Цель не в том, чтобы клиент чувствовал себя под микроменеджментом. Цель в том, чтобы на любой будущий спор уже был письменно зафиксированный ответ.
