Ви виставляєте рахунок на $3 500 за розробку. Той самий дзвінок для з'ясування вимог, той самий документ з обсягом робіт, ті самі $3 500 — незалежно від того, чи опиняться робочі процеси в Zapier, чи в Make. Шість місяців потому клієнт на Zapier з'їв сорок неоплачених годин «швидких правок» і три незручні розмови про перевитрати завдань, а розробка на Make, яка мала зайняти тридцять годин, зайняла шістдесят, бо сценарій постійно обростав новими гілками та крайніми випадками. Однакова ціна, два різні збитки. Платформи не спричинили жодного з них. Причиною стало однакове ціноутворення для них.
Цей пост для консультантів з автоматизації та малих агенцій, які продають розробки на Zapier і Make. Він пояснює, чому дві платформи несуть протилежні ризики, як прив'язати вашу модель ціноутворення до ризику, а не до логотипа, і що відслідковувати у своїх книгах, щоб кожен проєкт допомагав краще оцінювати наступний.
Платіжний рахунок платформи, прихований за вашою пропозицією
Zapier і Make беруть гроші за ту саму ідею — один автоматизований крок, виконаний один раз — у спосіб, що швидко розходиться. Zapier виставляє рахунок за завдання, і майже кожен крок у Zap рахується: тригер, кожна дія, кроки форматування та фільтрації. Make виставляє рахунок за операції, з набагато щедрішим обсягом, закладеним у кожен тариф. Ціни на етикетках виглядають близькими, поки не помножити на кроки та обсяг.
При прямому порівнянні на ідентичних навантаженнях за прайс-листом 2026 року розрив між ними становить приблизно п'ять-вісім разів на кожному рівні обсягу. Один бенчмарк, що проганяв той самий набір робочих процесів 1 000 разів на місяць, оцінив його у $73,50 на Zapier проти $9 на Make. Шестикроковий AI-процес, що обробляє 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 концентрує ваш ризик до передачі, у складності розробки. Одна фіксована ціна не може покрити обидві форми. Вона буде занадто щедрою на платформі, де ви швидкі, і занадто мізерною там, де ви повільні — і ви не помітите цього місяцями, бо кожен збиток ховається в неоплачених годинах, а не в рахунку-фактурі.
Фіксована ціна проти абонентської плати: прив'яжіть модель до ризику
Фіксована ціна та абонентська плата (retainer) — це не два різновиди одного й того самого. Проєкт з фіксованою ціною — це робота з узгодженими результатами, визначеним графіком і зафіксованою вартістю: клієнт отримує передбачуваність бюджету, а ви берете на себе ризик витрат за все в межах документа з обсягом робіт. Абонентська плата — це передплачена щомісячна потужність — встановлена кількість годин або визначений рівень обслуговування — що застосовується до нових розробок, виправлень, моніторингу та вдосконалень у міру потреби. Клієнт отримує безперервність; ви отримуєте передбачуваний дохід.
Правило рішення просте: фіксована ціна підходить для стабільних, чітко визначених розробок, а абонентська плата — для всього, що постійно змінюється. Одноразовий 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 ніколи не був проблемою. Проблемою було стягувати його однаково двічі.
