Оплата за результат, а не за обещание: как я перешёл на событийные этапы в B2B-автоматизации

Несколько недель назад у меня был разговор с клиентом по медицинскому проекту. Задача понятная: автоматизировать запись пациентов, собрать аналитику по нагрузке врачей, настроить автоматические напоминания перед визитом. ROI очевидный — это освобождает три часа административной работы ежедневно плюс снижает процент неявок на 20–30%, что при среднем чеке клиники означает очень конкретные рубли в месяц. Но его cashflow был зажат до середины лета, и исходное предложение на 180 тысяч рублей просто не укладывалось в текущий бюджет.

Полгода назад я бы поехал домой. Сейчас я сделал КП на 90 тысяч, разбил на три платежа по 30 и привязал каждый не к дате в календаре, а к событию в продакшн-системе. Он согласился за один разговор, без торга, без «я подумаю».

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

Вот уже несколько месяцев я продаю автоматизацию именно так. Это изменило и скорость закрытия сделок, и качество клиентов, которые приходят. Ни разу не пожалел.

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

Классическая схема продажи IT-услуг выглядит так: ты считаешь полный объём работ, называешь финальную цифру, просишь 50% аванса, остаток при сдаче. Если клиент говорит «дорого» — начинается торг. Если говорит «нет бюджета сейчас» — сделка разваливается, потому что ты уже не можешь сдвинуться дальше «ну хорошо, 40% аванса».

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

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

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

Стандартная схема не даёт ему войти. Событийная — даёт. Разбираемся как именно.

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

Большинство этапных контрактов которые я видел выглядят так: «Этап 1 к 15 числу. Этап 2 к концу месяца. Этап 3 через 6 недель.» Это не событийный контракт — это рассрочка с заранее прописанными оправданиями для задержек. Дата пришла, подрядчик говорит «ну мы в целом готовы», клиент платит и надеется что дальше будет лучше.

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

Вот несколько примеров событий для разных типов автоматизации:

• Входящие заявки: «Бот принял и корректно обработал 50 реальных входящих запросов за 7 дней на боевом аккаунте» — не «разработка завершена и протестирована»
• CRM-интеграция: «В CRM появились 100 автоматических записей с корректной разметкой за 14 дней» — не «интеграция настроена и работает»
• Отчётность: «Автоматический отчёт за прошлую неделю пришёл в нужный Telegram-чат в 08:00 понедельника» — не «дашборд готов и настроен»
• Модерация: «Модератор обработал 200 сообщений за 3 дня: 180 пропустил, 20 удалил по критериям, 0 ложных срабатываний на контрольной выборке» — не «модератор запущен»
• Воронка продаж: «Бот довёл 30 реальных лидов до квалификации за 14 дней» — не «воронка собрана»

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

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

Структура трёхэтапного контракта: старт, пилот, работа на цифрах

Я пришёл к трём стандартным этапам. Не потому что красиво делится на три, а потому что этот ритм совпадает с тем, как клиент учится доверять новой системе. Каждый этап — это конкретное событие с конкретным списком артефактов. Каждый платёж — за то что уже произошло, а не за то что произойдёт.

Этап 1 — Старт (30% бюджета). Оплата при подписании договора. Это не аванс «за обещание» — это оплата первого реального шага. К концу этапа у клиента есть: аудит текущего процесса, согласованная архитектура, рабочий прототип или стенд с доступом. Он видит живое, а не слайды с красивыми схемами. В примере с медицинским проектом это было: подключиться к API медицинской CRM, разобрать форматы данных, развернуть тестовую среду, показать первый автоматический отчёт на синтетических данных.

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

Этап 2 — Пилот в продакшне (30% бюджета). Оплата когда система развёрнута на боевом сервере и обрабатывает реальные данные. Событие фиксируется конкретно: «в систему поступили и корректно обработаны первые N реальных объектов» — без уточнений «в целом» и «в основном». Обычно это 2–3 недели от старта. Клиент уже видит живой результат на своих данных. Если что-то идёт не так — ещё не поздно скорректировать архитектуру, логику или интеграцию с его CRM.

Этап 3 — Работа на цифрах (40% бюджета). Оплата через 30 дней работы системы в продакшне. К этому моменту есть реальные данные: сколько задач обработано, сколько времени сэкономлено, какова точность, где узкие места. Это финальное закрытие — за стабильную работу, полную документацию и передачу системы клиенту в его зону ответственности.

Итого: три события, три платежа, ни один не завязан на «мне кажется что готово» или просто «прошло N дней по календарю».

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

Как урезать scope без потери ценности: выбор первого модуля

Исходный запрос на 180 тысяч включал три отдельных процесса. Клиент не мог войти в такой бюджет прямо сейчас. Я не дал скидку — я предложил начать с одного модуля за 90 тысяч.

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

Как выбрать с какого модуля начать:

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

Самое быстрое до измеримого результата. Модуль который начнёт давать заметный эффект через 2–3 недели, а не через 3 месяца. Быстрый результат означает что клиент видит ценность раньше и легче принимает решение о следующем этапе.

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

Есть измеримый outcome. «Было X, стало Y» — конкретная цифра которую можно записать в акт приёмки. «Улучшилась коммуникация с клиентами» это не outcome, это пожелание. «Время первого ответа снизилось с 2 часов до 5 минут» — это outcome.

Если первый модуль сработал, клиент сам приходит за следующим. В моём первом клиентском проекте именно так и произошло: начали с одного Telegram-бота, через месяц клиент сам спросил про следующий этап. Ни один успешно закрытый первый модуль ещё не заканчивался словами «всё, спасибо, дальше не надо». Это всегда начало отношений, а не разовая продажа.

Как защитить свои интересы: что должно быть в договоре

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

Чёткое определение события для каждого этапа. «Пилот запущен» — не событие. «Бот обработал 50 реальных заявок за 7 дней в продакшн-окружении по адресу X» — событие. Расплывчатая формулировка это будущий спор. Конкретная проверяемая формулировка это факт который видят оба.

Срок ожидания события и что происходит при задержке. Что если событие второго этапа не наступает потому что клиент сам затягивает интеграцию? Это нужно прописать заранее: «если событие этапа 2 не достигнуто в течение 45 дней от подписания этапа 1, стороны проводят ревью причин и согласуют новый срок или условия. Повторный перенос только с письменного согласия обеих сторон.» Это не штраф, это честность и предсказуемость для обеих сторон.

Конкретный список артефактов каждого этапа. Не «настройка и разработка», а «скрипт интеграции с API X, Telegram-бот Y, документация по администрированию, инструкция по мониторингу». Артефакты это то что клиент получает в свою зону ответственности при закрытии этапа.

Порядок выхода. Если клиент хочет выйти после этапа 1 — никаких доплат, он уже заплатил за то что получил. Если хочет выйти в середине этапа 2 — прописываете политику возврата пропорционально выполненному или нет возврата, зависит от вашей политики. Главное — это прописано заранее, а не выясняется в конфликтном разговоре.

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

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

Типичные ошибки при переходе на событийный контракт

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

Расплывчатое событие. «Система протестирована и готова к запуску» — это не событие, это ваше мнение. «Система обработала 20 реальных входящих обращений за 3 дня в продакшн-окружении» — это событие. Любая формулировка которую можно оспорить вашим же словом против слова клиента это будущий конфликт. Проверяйте каждую формулировку вопросом: «Может ли клиент проверить это самостоятельно, без моих объяснений?» Если нет — переписывайте.

Слишком маленький первый этап. Если первый этап стоит символически — 5 тысяч «за старт» — клиент не ощущает что реально начал. Первый этап должен быть ощутимым и по деньгам, и по результату. 25–30% от общего бюджета это разумная точка.

Нет списка артефактов. «Этап 1: настройка бота» — что именно входит? Что в акте? Если нет перечня конкретных артефактов, клиент может сказать «а я ожидал большего». Прописывайте конкретно: скрипт X, интеграция с Y, документация Z, доступ к W.

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

Применять схему к проектам без измеримого результата. Если у проекта нет чёткого определения «что значит работает» — событийный контракт превращается в споры о том что считать событием. Сначала определите outcome, потом структурируйте этапы.

Самая частая из этих ошибок на практике — расплывчатое событие. Кажется что обе стороны понимают одно и то же под «система готова». Но при первом же «а вот я имел в виду ещё и это» выясняется что понимания не было. Потратьте 15 минут при составлении договора на то чтобы написать событие предельно конкретно — это сэкономит несколько часов разговоров потом.

Как это изменило мои продажи: итоги нескольких месяцев

До перехода на событийные контракты у меня было два типа клиентских историй. Первые платили аванс быстро и без вопросов. Вторые неделями ходили по кругу вокруг вопроса «а вдруг не заработает» и так и не входили. Вторых было больше.

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

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

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

Как с этим работать на практике: я стараюсь держать минимум 2–3 проекта на разных этапах одновременно. Когда один проект на первом этапе, другой на втором, третий закрывает третий — платежи распределяются по времени и кассового разрыва не возникает. Это добавляет сложности в управление, но убирает зависимость от одного большого аванса в начале месяца.

Но это цена за то, что вас перестают воспринимать как того кто «берёт деньги и пропадает». Вы становитесь партнёром у которого интерес совпадает с интересом клиента: вы получаете следующий платёж только когда в его бизнесе что-то реально изменилось к лучшему.

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

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

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