Вы называете цену $3 500 за сборку. Тот же звонок для выявления требований, тот же документ с описанием объёма работ, те же $3 500 — независимо от того, окажутся ли рабочие процессы в Zapier или в Make. Шесть месяцев спустя клиент на Zapier съел сорок неоплаченных часов «быстрых правок» и три неловких разговора о перерасходе задач, а сборка на Make, которая должна была занять тридцать часов, заняла шестьдесят, потому что сценарий то и дело обрастал новыми ветвями и крайними случаями. Один и тот же тариф, два разных убытка. Ни один из них не был вызван платформами. Их вызвала одинаковая цена за обе.
Этот пост — для консультантов по автоматизации и небольших агентств, которые продают сборки на Zapier и Make. В нём объясняется, почему две платформы несут противоположные риски, как привязать модель ценообразования к риску, а не к логотипу, и что отслеживать в своей бухгалтерии, чтобы каждый проект помогал точнее оценить следующий.
Счёт за платформу, спрятанный за вашей сметой
Zapier и Make берут деньги за одну и ту же идею — один автоматизированный шаг, выполненный один раз — способами, которые быстро расходятся. Zapier выставляет счёт за задачу, и почти каждый шаг в Zap считается: триггер, каждое действие, шаги форматирования и фильтрации. Make выставляет счёт за операцию, с гораздо более щедрым объёмом, заложенным в каждый тариф. Цены на витрине выглядят близкими, пока не умножишь их на количество шагов и объём.
При прямом сравнении на идентичных нагрузках по прайс-листам 2026 года разрыв между ними составляет примерно от пяти до восьми раз на каждом уровне объёма. Один тест, прогонявший один и тот же набор рабочих процессов 1 000 раз в месяц, оценил его в $73,50 на Zapier против $9 на Make. Шестишаговый ИИ-процесс, обрабатывающий 1 000 лидов в месяц, обходится примерно в $150–$300 на Zapier и менее чем в $50 на Make. При 10 000 запусков в месяц тариф Core в Make покрывает этот объём примерно за $9–$11 в месяц, тогда как эквивалентное число задач Zapier требует тарифа, который стоит в несколько раз больше.
Ничто из этого не является проблемой вашего клиента в день сборки. Проблемой это становится для вас в тот месяц, когда их объём удваивается. Клиент на Zapier, переросший свой тариф по задачам, получает уведомление о перерасходе, на котором стоят отпечатки пальцев вашего агентства — платформу выбрали вы, число шагов спроектировали вы, и теперь их автоматизация стоит дороже каждый месяц. Клиент на Make с тем же ростом обычно укладывается в тариф, который у него уже есть. Если ваш фиксированный тариф предполагал, что «вся работа — это сборка», то версия этого допущения для Zapier исчерпывается первой.
Две платформы, два противоположных способа терять деньги
Убыток на сборке в Zapier обычно наступает после запуска. Многошаговые Zap быстро собираются, поэтому сама сборка часто укладывается в бюджет — что кажется победой, пока не начинается фаза поддержки. Каждый новый шаг, который вы добавляете, чтобы исправить крайний случай, повышает ежемесячный расход задач клиента. Каждый скачок объёма становится обращением в поддержку. Поскольку счёт за платформу у клиента виден и растёт, он снижает вашу плату за поддержку ровно в тот момент, когда нагрузка растёт. Вы оценили сборку; теперь вы дарите операции.
Убыток на сборке в Make обычно наступает до запуска. Сценарии Make дешевле в работе, но медленнее в качественном проектировании. Роутеры, итераторы, маршруты обработки ошибок и обращения к хранилищу данных вознаграждают тщательную архитектуру и наказывают за спешку. Документ с описанием объёма работ, написанный из допущений, свойственных Zapier, — один триггер, несколько линейных шагов, готово — тихо занижает сборку на Make вдвое. Агентства, которые честно учитывают время, часто обнаруживают, что версия «того же самого» проекта на Make требует на 50–100 процентов больше времени на сборку, тестирование и документирование. Вы и здесь оценили сборку; вы просто занизили цену другой её половины.
Это основной аргумент в пользу ценообразования с учётом платформы: Zapier концентрирует ваш риск после передачи, в поддержке, обусловленной объёмом, и в трении из-за перерасхода. Make концентрирует ваш риск до передачи, в сложности сборки. Один фиксированный тариф не может покрыть обе формы. Он окажется слишком щедрым на платформе, где вы быстры, и слишком скудным там, где вы медленны — и вы не заметите этого месяцами, потому что каждый убыток прячется в неоплаченных часах, а не в счёте.
Фиксированная цена или абонентская плата: привяжите модель к риску
Проекты с фиксированной ценой и по абонентской плате — это не два варианта одного и того же. Проект с фиксированной ценой — это проект с согласованными результатами, определёнными сроками и зафиксированной стоимостью: клиент получает определённость бюджета, а вы берёте на себя риск затрат за всё, что входит в документ с описанием объёма работ. Абонентская плата — это предоплаченная ежемесячная ёмкость: установленное число часов или определённый уровень обслуживания, — применяемая к новым сборкам, исправлениям, мониторингу и улучшениям по мере необходимости. Клиент получает непрерывность; вы получаете предсказуемый доход.
Правило принятия решения простое: фиксированная цена подходит для стабильных, хорошо определённых сборок, а абонентская плата — для всего, что постоянно меняется. Разовая маршрутизация лидов через Zap с замороженной спецификацией — это проект с фиксированной ценой. Программа автоматизации, в которой клиент каждый месяц открывает для себя новый рабочий процесс, — это клиент по абонентской плате в костюме проектной сметы. Большинство убытков агентств происходит от продажи первой формы, когда по сути взаимодействие является второй, — от оценки сборки, когда клиент покупает постоянную возможность.
Конкретно на работах в Zapier склоняйтесь к тому, чтобы с первого дня сочетать каждую сборку с фиксированной ценой с планом обслуживания. Экономика платформы гарантирует разговоры после запуска о задачах, объёме и тарифах; абонентская плата превращает их из бесплатной поддержки в услугу, которую клиент уже купил. На работах в Make защищайте вместо этого фазу сборки: назначайте фиксированные цены на основе оценок Make по учтённому времени, а не догадок в стиле Zapier, и ставьте более жёсткую границу для запросов на изменения вокруг переработки сценариев — именно там на самом деле уходят часы Make.
Цифры, которые должны определять ваши ставки
Реальные данные о ставках 2026 года от работающих операторов автоматизации оценивают полные клиентские сборки — захват лидов в CRM с уведомлениями, хлеб с маслом любого проекта — примерно в $1 800–$4 500 фиксированной цены, с ежемесячными абонентскими платежами от $1 200 до $3 800 за поддержку плюс новые сборки рабочих процессов. Почасовые ставки колеблются от $95 до $235, а устоявшиеся агентства называют цену $3 000–$15 000 за проект с абонентской платой от $500 до $5 000 в месяц. Если ваша фиксированная цена ниже этого диапазона сборок, а часы выполнения совпадают с часами всех остальных, то рынок вам недоплачивает. Ваша смета недоплачивает.
Математика маржи благоприятствует абонентским платежам, как только вы миновали первую сборку. Отраслевые ориентиры оценивают валовую маржу абонентских платежей примерно в 50–70 процентов против 40–60 процентов для проектов с фиксированной ценой, а клиенты на абонентской плате обычно стоят в три-пять раз больше за всё время сотрудничества. Но абонентские платежи текут: около 52 процентов проектов сталкиваются с расползанием объёма работ, почти четыре из пяти агентств редко или лишь иногда выставляют счёт за работы вне объёма, а абонентская плата с хорошей маржой может терять около пяти пунктов маржи в год из-за неоплаченного роста объёма. Агентства, сохраняющие маржу абонентских платежей, — это не те, кто избегает расползания объёма, а те, кто его измеряет и пересматривает цену.
Два ориентира стоит держать на виду. Во-первых, ваша эффективная ставка на проект — фактический доход, делённый на фактически отработанные часы, — должна превышать вашу себестоимость часа с большим запасом, достаточным, чтобы расползание объёма и списания не могли его съесть; когда она оказывается вблизи себестоимости, разница ушла в неоплаченные часы. Во-вторых, отслеживайте этот показатель отдельно для сборок в Zapier и сборок в Make. Средневзвешенные значения — это то, как перекрёстное субсидирование остаётся невидимым: платформа, которую вы оцениваете правильно, скрывает ту, которую вы оцениваете неправильно.
Что должна фиксировать ваша бухгалтерия
Ваша система бухгалтерского учёта либо выявляет эти утечки, либо прячет их. Разницу делают четыре привычки.
Во-первых, разделяйте доход от сборок и доход от абонентских платежей в плане счетов. Единый счёт «доход от клиентов» смешивает разовые проектные гонорары с регулярными планами обслуживания, так что вы не видите, какая модель окупается. Два счёта дохода — проекты и абонентские платежи — превращают каждое закрытие месяца в сводку о структуре вашего бизнеса.
Во-вторых, никогда не включайте подписку клиента на платформу в свой гонорар. Клиент должен платить Zapier или Make напрямую, со своего собственного аккаунта, даже если вы всё для него настроили. Как только расходы на платформу проходят через ваши книги как доход и расход, ваша выручка завышается, маржа искажается, а каждое повышение тарифа становится пересмотром вашей цены. Если вам приходится оплачивать подписку авансом, учитывайте её как возмещаемый транзитный платёж на отдельном счёте, но не как доход.
В-третьих, фиксируйте часы по проектам, даже когда проект с фиксированной ценой. Неоплаченные часы — это валюта, в которой торгуются оба платформенных риска — поддержка Zapier после запуска, перерасход Make до запуска — и часы, которые вы не записали, — это убытки, которые нельзя учесть в следующей смете. Ваш трекер времени — прежде всего инструмент ценообразования, а уже потом кадровый учёт.
В-четвёртых, пересматривайте рентабельность по каждому клиенту каждый квартал, а не только общую прибыль. Агентства, которые это делают, обычно обнаруживают, что 10–20 процентов клиентов убыточны, если посчитать реальную себестоимость выполнения, — как правило, это клиенты с фиксированной ценой, всё ещё получающие бесплатную поддержку спустя месяцы после запуска. Этот обзор — единственная самая ценная финансовая привычка, которую большинство небольших агентств так и не заводит. Каждый убыточный клиент — это либо разговор о пересмотре цены, либо заявление об уходе; книги подскажут вам, какие именно, и чем дольше вы ждёте, тем дороже ответ.
Вот как выглядит месяц в текстовом реестре для консультанта, который придерживается этих привычек — сборка за $3 500 с фиксированной ценой, план обслуживания за $1 200 в месяц, помощь подрядчика по сборке и небольшая подписка Make, оплаченная авансом за клиента:
2026-01-01 open Assets:Cash:Operating USD
2026-01-01 open Assets:Receivable USD
2026-01-01 open Income:Projects USD
2026-01-01 open Income:Retainers USD
2026-01-01 open Expenses:Contractors USD
2026-01-01 open Expenses:Software USD
2026-10-01 * "Harbor Dental" "Lead-routing build, fixed fee"
Assets:Receivable 3500.00 USD
Income:Projects -3500.00 USD
2026-10-05 * "Harbor Dental" "Build invoice paid"
Assets:Cash:Operating 3500.00 USD
Assets:Receivable -3500.00 USD
2026-10-05 * "Contract developer" "Scenario build help, 12 hours"
Expenses:Contractors 1080.00 USD
Assets:Cash:Operating -1080.00 USD
2026-11-01 * "Harbor Dental" "November care plan"
Assets:Receivable 1200.00 USD
Income:Retainers -1200.00 USD
2026-11-01 * "Make" "Client scenario operations, October"
Expenses:Software 29.00 USD
Assets:Cash:Operating -29.00 USDКогда доход от сборок и от абонентских платежей на отдельных счетах, один запрос показывает, как структура меняется месяц за месяцем. Сопоставьте его с журналом времени — часы сборки против $3 500, часы поддержки против $1 200 — и эффективная ставка на каждое взаимодействие становится простой арифметикой, а не ощущением.
Пособие по ценообразованию для ваших следующих двух смет
Примените это на практике в следующий раз, когда потенциальный клиент попросит «простую автоматизацию»:
- Назначайте цену за сборки в Make на основе оценок Make по учтённому времени. Если вы никогда честно не отслеживали сборку в Make, добавьте 50 процентов к своей догадке в стиле Zapier и замерьте время проекта, чтобы откалибровать следующую.
- Привязывайте план обслуживания к каждой сборке в Zapier при подписании, с ценой исходя из ожидаемого ежемесячного объёма задач плюс запас на поддержку, — а не как запоздалую мысль, когда приходит первое уведомление о перерасходе.
- Переводите клиента на его собственный аккаунт платформы, на его собственную карту, прежде чем что-либо собирать. Никаких транзитных подписок в вашем ценообразовании.
- Определите одну границу для запросов на изменения в письменном виде: новые приложения, новые триггеры и переработка сценариев — это новые сметы, а не мелкие правки. Большая часть неоплаченного объёма проникает через лексику, а не через злой умысел.
- Пересматривайте эффективную ставку на проект и прибыль по клиенту каждый квартал. Пересматривайте цену для нижних 20 процентов или отпускайте их.
Агентства, теряющие деньги на работах по автоматизации, редко бывают недоплачены на бумаге. Их сметы выглядят нормально, потому что убытки никогда не появляются в счёте — они проявляются как неоплаченные вторники после обеда, бесплатная разборка перерасходов и сборки, занявшие вдвое больше часов, которые никто не записал. Назначайте цену за платформу, которую вы на самом деле продаёте, продавайте абонентскую плату, которой на самом деле является взаимодействие, и позвольте своим книгам оценивать каждую смету. Гонорар в $3 500 никогда не был проблемой. Проблемой было дважды назначить его одинаково.
