директор и машина · право и риски · запись № 024 · 25 июля 2026 · Давид Герштейн

Регламент работы с договорами: как сделать шаблон, который не подведёт в суде

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные.

Сколько версий вашего типового договора ходит сейчас по компании? Если вы уверены, что одна, — проверьте: я почти уверен, что их три. И одна из них — та, куда менеджер когда-то внёс правку клиента и забыл откатить.

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

У компании, которая снимает семейные фильмы на заказ, были старые договоры с первыми клиентами и новые — с последними. В старых не было ни слова про итоговый фильм, сопровождение и визуальные ожидания. В новых — было. Разница появилась не потому, что кто-то сел и продумал риски заранее. Она появилась после конфликтов. Шаблоны договоров с клиентами в этой компании росли как заплатки поверх дыр, а не как система.

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

Договоры с клиентами: шаблоны, которые растут заплатками — это риск

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

В компании, которая сопровождает клиентов в длительных разрешительных процедурах через внешние инстанции, был пункт 6.8: возврат денег полагался «при соблюдении рекомендаций компании о продолжении работы». Клиент получил два отказа от внешнего ведомства, отказался от дальнейшего обжалования и потребовал полный возврат. Компания потратила 70 тыс. ₽ на сбор документов и бонусы менеджерам, но вернула клиенту оплаченные 420 тыс. ₽ — потому что формулировка не выдерживала спора. Слово «отказ» звучало как финальная точка, хотя по факту первый отказ ведомства не был последней инстанцией.

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

Регламент работы с договорами: какие версии хранить и когда их менять

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

Второе решение той же компании — разбить договор по этапам работ с согласованием выполненного перед переходом к следующему. До выхода на производство должно быть закрыто 60–70% условий, с актами выполненной работы. Это защищает обе стороны: клиент видит, за что платит на каждом шаге, компания фиксирует, что этап принят, и не отвечает потом за то, что происходило до подписания акта.

Если у вас нет истории конфликтов, по которой можно построить такую таблицу — начните собирать её сейчас. Каждый спор, дошедший до претензии, это готовая строка для будущей версии шаблона. Держите таблицу версий в отдельном реестре — Google Sheets или лист в CRM, — а не в переписке между менеджером и юристом, иначе через год никто не вспомнит, почему пункт звучит именно так.

Гарантии: разделить то, что вы контролируете, и то, что нет

Клиент требовал гарантировать итоговый результат в срок 6–12 месяцев с полным возвратом за 10 рабочих дней при неудаче. Компания не может контролировать проверки внешних инстанций, форс-мажоры и действия самого клиента. Но по договору обязана отвечать за результат целиком — это ловушка, в которую легко попасть, если гарантия написана одной строкой без разбивки.

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

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

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

Типовые договоры: риски, которые не в тексте, а в людях

Шаблон может быть идеальным, но его нарушает конкретный человек. Руководитель отдела заключил договор на консультационные услуги на 350 тыс. ₽ с клиентом, которому компания такие услуги не оказывает. Деньги получены, чек не выписан, договор подписан на ИП сотрудника — вопреки прямому запрету руководства. Это классический прецедент бокового заработка, и, что хуже, не первый: политика против таких договоров уже озвучивалась на совещаниях. Клиенты потом звонили собственнику с претензией, думая, что покупали услугу у компании, а получили её по отдельному договору мимо кассы.

Здесь шаблон бессилен — нужен контроль исполнения. Я долго считал такие истории проблемой найма: не тех взяли. Оказалось, дело в другом — в компании не было ни одной бумаги, где сотруднику прямо запрещалось бы это делать. Но кое-что шаблон всё же может: явный пункт о запрете параллельных договоров с клиентами компании, подписанный каждым сотрудником с доступом к клиентской базе. Это не остановит недобросовестного человека, но даёт основание для иска и увольнения без долгих споров о трудовом праве.

Второй похожий кейс — клиент оплатил 262 тысячи, а через суд потребовал 772 тысячи. Компания смогла задокументировать только 150 тысяч как не оказанные услуги и вернула именно эту сумму. Разница между тем, что требовал клиент, и тем, что удалось доказать, — это разница между компанией с актами на каждый этап и компанией без них. Похожая история — спор, где клиент требовал вернуть большую часть предоплаты, заявив, что не получил обещанную стратегию. Компания предложила стратегию постфактум, но было поздно: договор не фиксировал, что именно и когда должно быть предоставлено.

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

Данные клиентов в договоре: не только про деньги

Отдельная категория рисков — то, что вы обязаны прописать про данные клиента, а не только про услугу. Юрист проверил, что все юрлица группы зарегистрированы как операторы персональных данных, но выявил пробел: в договорах с клиентами не было явного согласия на трансграничную передачу данных, хотя документы обрабатывались на зарубежных серверах. Это отдельный пункт, который легко забыть, если шаблон писался до того, как в процессе появилась внешняя обработка данных. Подробнее о том, что можно и что нельзя передавать через ИИ-сервисы — в статье «Персональные данные и нейросети: что можно отправлять в ИИ, а что нельзя».

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

Ещё один пробел того же типа — ответственность за иностранное контрактное право. Юрист составляет и проверяет договоры, но не имеет права общаться с клиентом напрямую. Ответ на это — не переписывание договора, а назначение отдельного специалиста, который отвечает за юридическую поддержку и может привлекать консультантов при необходимости. Иногда риск не в тексте документа, а в том, что некому объяснить клиенту, что там написано.

ИИ-связка: автоматическая проверка договора перед юристом

Юрист не должен читать каждый договор целиком, если 80% текста — типовые блоки, уже проверенные раньше. Его время нужно тратить на нестандартные условия. Чтобы это работало, между менеджером и юристом ставится дешёвая модель — она не подписывает и не советует, она находит расхождения с эталонным шаблоном и помечает риск.

Схема конвейера — как это выглядит в виде реестра шагов и статусов:

Дорогую модель я сюда сначала и ставил — и зря платил за то, что делает дешёвая. Модель здесь нужна дешёвая (класса mini, тип GPT-4o-mini или аналог) — задача не творческая, а классификационная: сверить пункт с пятью известными типами дыр и вернуть структурированный вердикт. По публичным ценникам таких моделей стоимость входных и выходных токенов минимальна — доли рубля за тысячу токенов (курс и точная цифра зависят от провайдера и меняются). Дорогую модель звать незачем, она нужна только если позже понадобится сгенерировать саму формулировку правки, а не найти проблему.

Ты — ассистент юридического отдела. На входе текст договора с клиентом.
Проверь его ТОЛЬКО на пять типов риска, ничего не придумывай сверх них:

1. Гарантия результата сформулирована как обязательство по итогу,
   а не по контролируемым компанией этапам.
2. Условие возврата денег зависит от формулировки, которую клиент
   может трактовать в свою пользу (например слово "отказ" без уточнения,
   финальная это инстанция или нет).
3. Нет разбивки на этапы с актами выполненных работ.
4. Нет пункта о согласии на трансграничную передачу персональных данных,
   при этом договор предполагает обработку данных на внешних серверах.
5. Нет запрета для сотрудников компании заключать параллельные договоры
   с клиентом в обход компании.

Верни строго JSON без пояснений вне него:
{
  "risks_found": [
    {"type": "номер риска 1-5", "quote": "точная цитата пункта", "severity": "low|medium|high"}
  ],
  "clean": true/false,
  "recommendation": "одна короткая фраза по самому серьёзному риску"
}

Текст договора:
"""
{{CONTRACT_TEXT}}
"""

Пример ответа модели на договор с пунктом про возврат без уточнения инстанции:

{
  "risks_found": [
    {"type": "2", "quote": "возврат при соблюдении рекомендаций компании о продолжении работы", "severity": "high"}
  ],
  "clean": false,
  "recommendation": "Уточнить, что первый отказ ведомства не финальная инстанция"
}

Инженерная обвязка простая и без иллюзий: скрипт крутится в Google Apps Script, привязанном к служебному аккаунту, а не к личному — ровно тот урок, который компания усвоила на истории с курсом, где доступ был завязан на личную учётку разработчика и стал недоступен при масштабировании. Промпт и API-ключ хранятся в коде скрипта, а не в текстовом файле на диске — тот же принцип, что и с токенами доступа к порталу: «единственный способ сохранить работу при блокировке — чтобы все файлы были у тебя, а не зависели от чужой учётной записи».

Шаг 5 в таблице конвейера — вебхук в CRM при high-риске — помечен предупреждением не случайно. При аудите безопасности в одной из систем выяснилось, что вебхуки лежат без защиты и через них можно достучаться до данных клиентов на внешнем портале. Ошибки в самом коде проверки риска оказались там мельче проблемы: настоящей дырой была архитектура доступа, а не логика скрипта. Прежде чем подключать вебхук уведомлений к боевой CRM, закройте его токеном и ограничьте IP отправителя — иначе вы чините одну дыру и открываете другую.

При сбое API — три автоматических повтора с паузой, затем письмо ответственному юристу с пометкой «скрининг не сработал, проверьте вручную». Реестр рисков в Google Sheets открыт по принципу «один человек — одна таблица»: юрист правит статусы, менеджер только читает, чтобы автоматическая запись не конфликтовала с ручной правкой. Реальная стоимость токенов на поток в несколько десятков договоров в месяц оказалась ниже, чем я закладывал в план: по прикидке выше это десятки-сотни рублей в месяц даже с запасом на повторные прогоны. Основные деньги в этой схеме экономятся не на API, а на часах юриста — это разбираем в разделе экономики.

Согласование без юриста на каждый пункт: пять блоков, которые закрывают всё заранее

Самый частый вопрос, который я слышу: «Можно ли согласовывать договоры быстрее, не гоняя каждый вариант через юриста?» Можно, если заранее закрыть типовые риски библиотекой формулировок:

• Гарантийные пункты — по этапам, которые компания контролирует, а не по итоговому результату.
• Возвраты — с чёткой развилкой «что считается отказом» и «что не является финальной инстанцией».
• Этапы и акты — минимум для 60–70% объёма работ до основной фазы проекта.
• Данные — согласие на трансграничную передачу, если данные уходят на внешние серверы.
• Ограничения для сотрудников — прямой запрет параллельных договоров с клиентами компании.

Когда эти пять пунктов закрыты один раз юристом, дальше менеджер собирает договор из проверенных блоков без согласования каждой версии заново. Юрист подключается только когда клиент просит нестандартное условие — гарантию срока, особый порядок оплаты, изменение ответственности. Это резко сокращает время согласования, потому что большая часть текста уже проверена, а спорным остаётся один-два пункта.

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

Экономика: что стоит библиотека шаблонов и что она даёт

Настройка ИИ-скрининга — около 6 часов на скрипт и промпт, эксплуатация — десятки-сотни рублей в месяц на токены, эффект — около 13 500 ₽ экономии на времени юриста в месяц (оценка). Возьмём отдел из 8 менеджеров со средним чеком 180 тыс. ₽. Каждый ведёт по 4 сделки в месяц с договором — 32 договора в месяц. Ниже — грубая оценка, не факт компании, а типовой расчёт «часы × ставка», который можно приложить к своим цифрам.

Разница — около 13 500 ₽ экономии на времени юриста в месяц: ставка юриста ~1 500 ₽/час, у вас юрист может стоить дороже или дешевле. Разовые затраты на создание самой библиотеки — юрист один раз сводит существующие формулировки, переписывает пять проблемных блоков и утверждает эталонный шаблон: около 40 часов по той же ставке — разово около 60 000 ₽. При экономии ~13 500 ₽/мес окупаемость составляет примерно 4–5 месяцев (оценка, без учёта того, что часть этих часов юрист и так тратил бы на разбор конкретных конфликтов).

Это только эффект от сокращения ручного чтения — не смешивайте его с эффектом от кейса 772/262/150 тысяч. Там сработал не ИИ-скрининг, а факт наличия поэтапных актов в договоре: это отдельная инициатива (перестройка структуры договора), и её вклад нельзя списывать на автоматизацию проверки. Что не считаем эффектом ИИ-скрининга: снижение суммы иска в конкретном споре, ускорение получения оплаты и любые изменения, которые дали акты и этапная разбивка договора, — это отдельные рычаги со своей отдельной экономикой.

Чек-лист: с чего начать в понедельник

Внедрение библиотеки шаблонов и ИИ-скрининга — не проект на квартал, а неделя сфокусированной работы, если у вас уже есть история конфликтов.

• Понедельник. Собрать все действующие версии договорных шаблонов в один реестр (Google Sheets или лист CRM). Выписать все претензии и споры за последние 12 месяцев — каждая станет строкой будущей таблицы версий.
• Вторник. Свести найденные проблемы в пять категорий: гарантии, возвраты, этапы/акты, данные, боковые договоры сотрудников. Отдать список юристу на разовую вычитку — не всего шаблона, а именно этих пяти блоков.
• Среда. Юрист переписывает проблемные формулировки один раз и утверждает эталонный шаблон. Параллельно — проверить права доступа к реестру и таблицам с договорами: не лежат ли они открытыми по ссылке.
• Четверг. Настроить скрипт скрининга: Apps Script на служебном аккаунте, промпт из этой статьи, запись вердиктов в Google Sheets. Прогнать на 5–10 старых договорах, чтобы откалибровать severity и убедиться, что модель не путает риски.
• Пятница. Подключить уведомление в CRM при high-риске через защищённый вебхук (токен + ограничение по отправителю). Провести короткую летучку с менеджерами: как собирать договор из готовых блоков и когда обязательно звать юриста.
• Через месяц. Пересчитать часы, которые юрист реально тратит на договоры, и сверить с оценкой из раздела экономики — если цифры разошлись сильно, дело либо в ставке, либо в доле нестандартных условий выше ожидаемых 20%.

Отдельно — про людей, а не про текст. Библиотека шаблонов и ИИ-скрининг не остановят сотрудника, который решит заключить параллельный договор в обход компании, как это уже случалось. Здесь помогает только явный пункт о запрете и регулярный аудит закрытых сделок — если политика озвучена один раз на совещании, это не значит, что прецедент не повторится.

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

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

И ещё одно, чему мне пришлось учиться самому: читать собственный договор глазами клиента, который завтра захочет вернуть деньги. Это управленческий навык, а не юридический. Юрист сверит текст с законом, но только вы знаете, что менеджер пообещал клиенту голосом и чего клиент ждёт по факту. Руководитель, который умеет заранее назвать пять мест, где его же договор прочитают против него, стоит компании дешевле любого разбирательства.

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

Как поставить проверку версий и первичный разбор входящих договоров машиной — в бесплатном курсе для руководителей.

И последнее: договорите с вашим юристом одну вещь — кто и как часто проверяет актуальность шаблонов. Без этого правила ваш идеальный договор устареет вместе с законодательством, и узнаете вы об этом в суде.

Как это было у нас

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

Я тогда не стал разбираться, кто виноват: система позволяла хранить договоры где угодно, и рано или поздно это должно было случиться. Мы завели единое место, откуда берётся шаблон, и правило, что личные копии не используются.

Сверьте свои шаблоны на этой неделе — и заведите одно место, откуда их берут все. Как поставить проверку версий машиной, разбираю в бесплатном курсе.

Частые вопросы

Что входит в регламент работы с договорами?

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

Какие риски у типовых договоров с клиентами?

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

Нужно ли фиксировать этапы работ в договоре?

Да — 60–70% условий стоит закрывать актами выполненных работ ещё до начала основной части проекта, это резко снижает сумму, которую можно отсудить постфактум.

Сколько стоит внедрить ИИ-скрининг договоров?

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

#автоматизация #деньги #контроль и надёжность