Je geeft $3.500 op voor de build. Zelfde intakegesprek, zelfde scope-document, dezelfde $3.500 — of de workflows nu in Zapier of in Make belanden. Zes maanden later heeft de Zapier-klant veertig niet-gefactureerde uren aan "snelle fixes" opgeslokt en drie ongemakkelijke gesprekken over taakoverschrijdingen, terwijl de Make-build die dertig uur zou kosten er zestig heeft geduurd omdat het scenario steeds nieuwe vertakkingen en randgevallen bleef voortbrengen. Dezelfde prijs, twee verschillende verliezen. De platforms veroorzaakten geen van beide. Ze identiek prijzen deed dat wel.
Deze post is voor automation-consultants en kleine bureaus die Zapier- en Make-builds verkopen. Het legt uit waarom de twee platforms tegengestelde risico's dragen, hoe je je prijsmodel afstemt op het risico in plaats van het logo, en wat je in je boekhouding moet bijhouden zodat elk project het volgende beter prijst.
De platformrekening die zich achter je offerte verstopt
Zapier en Make rekenen voor hetzelfde idee — één geautomatiseerde stap die één keer draait — op manieren die snel uiteenlopen. Zapier factureert per taak, en vrijwel elke stap in een Zap telt mee: de trigger, elke actie, formatter- en filterstappen. Make factureert per operatie, met veel royaler volume ingebakken in elke tier. De catalogusprijzen lijken dicht bij elkaar tot je ze vermenigvuldigt met stappen en volume.
Gemeten naast elkaar op identieke workloads tegen lijstprijzen van 2026 is het verschil tussen de twee ongeveer vijf tot acht keer in elke volumetier. Eén benchmark die hetzelfde workflowpakket 1.000 keer per maand liet draaien, prijsde het op $73,50 bij Zapier tegen $9 bij Make. Een AI-workflow van zes stappen die 1.000 leads per maand verwerkt, komt uit op ongeveer $150 tot $300 bij Zapier en onder de $50 bij Make. Bij 10.000 maandelijkse runs dekt Make's Core-tier het volume voor ongeveer $9 tot $11 per maand, terwijl het equivalente aantal Zapier-taken op een plan zit dat meerdere keren meer kost.
Niets daarvan is het probleem van je klant op de dag van de build. Het wordt jouw probleem in de maand dat hun volume verdubbelt. Een Zapier-klant die zijn taaktier ontgroeit, krijgt een overschrijdingsmelding met de vingerafdrukken van jouw bureau erop — jij koos het platform, jij ontwierp het aantal stappen, en nu kost hun automatisering elke maand meer. Een Make-klant met dezelfde groei absorbeert het meestal binnen het plan dat hij al heeft. Als je vaste prijs aannam dat "de build het hele werk is", verloopt de Zapier-versie van die aanname het eerst.
Twee platforms, twee tegengestelde manieren om geld te verliezen
Het verlies op een Zapier-build komt meestal na de lancering. Meerstaps-Zaps zijn snel in elkaar te zetten, dus de build zelf komt vaak onder budget uit — wat als een overwinning voelt tot de onderhoudsfase begint. Elke nieuwe stap die je toevoegt om een randgeval op te lossen, verhoogt de maandelijkse taakverbranding van de klant. Elke volume-piek wordt een supportticket. Omdat de platformrekening van de klant zichtbaar is en groeit, onderhandelen ze je onderhoudsvergoeding naar beneden precies op het moment dat de werklast groeit. Je gaf de build een prijs; nu doneer je de operations.
Het verlies op een Make-build komt meestal vóór de lancering. Make-scenario's zijn goedkoper in gebruik maar langzamer om goed te ontwerpen. Routers, iterators, foutafhandelingsroutes en data-store-lookups belonen zorgvuldige architectuur en straffen haast af. Een scope-document geschreven vanuit Zapier-vormige aannames — één trigger, een paar lineaire stappen, klaar — onderschat een Make-build stilletjes met de helft. Bureaus die eerlijk uren registreren, ontdekken vaak dat de Make-versie van "hetzelfde" project 50 tot 100 procent langer duurt om te bouwen, te testen en te documenteren. Je gaf de build ook een prijs; je onderprijsde alleen een andere helft ervan.
Dit is het kernargument voor platformbewuste prijsstelling: Zapier concentreert je risico na de overdracht, in volumegedreven support en wrijving rond overschrijdingen. Make concentreert je risico vóór de overdracht, in bouwcomplexiteit. Eén vaste prijs kan beide vormen niet dekken. Hij is te royaal op het platform waar je snel bent en te krap waar je traag bent — en je merkt het maandenlang niet, omdat elk verlies zich verschuilt in niet-gefactureerde uren in plaats van op een factuur.
Vaste prijs versus retainer: stem het model af op het risico
Vaste-prijs- en retaineropdrachten zijn geen twee smaken van hetzelfde. Een vaste-prijsopdracht is een project met afgesproken deliverables, een vastgestelde tijdlijn en een vastgezette kostprijs: de klant krijgt budgetzekerheid, en jij absorbeert het kostenrisico voor alles binnen het scope-document. Een retainer is vooraf gekochte maandelijkse capaciteit — een vast aantal uren of een gedefinieerd serviceniveau — ingezet voor nieuwe builds, fixes, monitoring en verbeteringen naarmate de behoeften opkomen. De klant krijgt continuïteit; jij krijgt voorspelbare omzet.
De beslisregel is eenvoudig: vaste prijs past bij stabiele, goed afgebakende builds, en retainers passen bij alles wat blijft veranderen. Een eenmalige lead-routing-Zap met een bevroren specificatie is een vaste-prijsproject. Een automatiseringsprogramma waarbij de klant elke maand een nieuwe workflow ontdekt, is een retainerklant vermomd als projectofferte. De meeste verliezen van bureaus komen voort uit het verkopen van de eerste vorm terwijl de opdracht in werkelijkheid de tweede is — een build offreren terwijl de klant een doorlopende capaciteit koopt.
Bij Zapier-werk specifiek: neig ernaar elke vaste-prijsbuild vanaf dag één te koppelen aan een care plan. De economie van het platform garandeert gesprekken na de lancering over taken, volume en plantiers; een retainer maakt daarvan de dienst die de klant al had gekocht in plaats van gratis support. Bij Make-werk bescherm je juist de bouwfase: offer vaste prijzen op basis van getimede Make-schattingen, niet op basis van Zapier-vormige gissingen, en zet een strakkere grens voor wijzigingsverzoeken rond scenario-herontwerpen, want daar gaan de Make-uren echt naartoe.
De cijfers die je tarieven zouden moeten bepalen
Echte tariefgegevens uit 2026 van werkende automation-operators plaatsen complete klantbuilds — leadcaptatie in CRM met notificaties, het brood-en-boterproject — op ruwweg $1.800 tot $4.500 vaste prijs, met maandelijkse retainers tussen $1.200 en $3.800 voor onderhoud plus nieuwe workflow-builds. Uurtarieven lopen van $95 tot $235, en gevestigde bureaus offreren $3.000 tot $15.000 per project met retainers van $500 tot $5.000 per maand. Als jouw vaste prijs onder dat buildbereik ligt terwijl je leveringsuren overeenkomen met die van iedereen, betaalt de markt je niet te weinig. Je offerte doet dat.
De margerekening pleit voor retainers zodra je voorbij de eerste build bent. Branchebenchmarks plaatsen de brutomarges op retainers rond 50 tot 70 procent tegenover 40 tot 60 procent voor vaste projecten, en retainerklanten zijn doorgaans drie tot vijf keer meer waard over hun levensduur. Maar retainers lekken: ongeveer 52 procent van de projecten krijgt te maken met scope creep, bijna vier op de vijf bureaus factureren zelden of slechts soms werk buiten de scope, en een retainer met een gezonde marge kan per jaar ongeveer vijf margepunten verliezen aan niet-gefactureerde scopegroei. De bureaus die retainer marges behouden, zijn niet degenen die scope creep vermijden. Het zijn degenen die het meten en herprijzen.
Twee benchmarks zijn het waard boven je bureau te prikken. Ten eerste je effectieve tarief per project — werkelijke omzet gedeeld door werkelijk gewerkte uren — moet je kostentarief met een ruime veelvoud overschrijden, met genoeg ruimte dat scope creep en afboekingen het niet kunnen opeten; wanneer het in de buurt van kostprijs landt, ging het verschil naar niet-gefactureerde uren. Ten tweede: houd dat getal apart bij voor Zapier-builds en Make-builds. Gemiddelden over alles heen zijn hoe de kruissubsidie onzichtbaar blijft: het platform dat je correct prijst, verbergt het platform dat je dat niet doet.
Wat je boekhouding moet vastleggen
Je boekhoudopzet onthult deze lekken of begraaft ze. Vier gewoonten maken het verschil.
Ten eerste: scheid buildomzet van retaineromzet in je rekeningschema. Een enkele "klantinkomsten"-rekening vermengt eenmalige projectvergoedingen met terugkerende care plans, waardoor je niet kunt zien welk model zijn geld verdient. Twee inkomstenrekeningen — projecten en retainers — maken van elke maandafsluiting een uitlezing van je bedrijfsmix.
Ten tweede: stop nooit het platformabonnement van de klant in je vergoeding. De klant moet Zapier of Make rechtstreeks betalen, op zijn eigen account, ook als jij het voor hem opzet. Zodra platformkosten als omzet en kosten door je boeken stromen, blaast je omzet op, vervormen je marges, en wordt elke planupgrade een heronderhandeling van je prijs. Als je een abonnement moet voorschieten, boek het dan als doorbelaste pass-through op een eigen rekening, nooit als omzet.
Ten derde: registreer uren tegen projecten, ook wanneer het project een vaste prijs heeft. Niet-gefactureerde uren zijn de valuta waarin beide platformrisico's handelen — Zapier-support na de lancering, Make-overschrijdingen vóór de lancering — en uren die je niet vastlegt, zijn verliezen die je niet in de volgende offerte kunt prijzen. Je urentracker is in de eerste plaats een prijsinstrument en pas in de tweede plaats een loonadministratie.
Ten vierde: beoordeel elk kwartaal de winstgevendheid per klant, niet alleen de totale winst. Bureaus die dit doen, ontdekken doorgaans dat 10 tot 20 procent van de klanten onrendabel is zodra de werkelijke leveringskosten worden meegeteld — meestal de vaste-prijs klanten die maanden na de lancering nog gratis support krijgen. Die beoordeling is de meest waardevolle financiële gewoonte die de meeste kleine bureaus nooit opbouwen. Elke onrendabele klant is ofwel een herprijsgesprek of een ontslagbrief; de boeken vertellen je welke, en hoe langer je wacht, hoe duurder het antwoord.
Zo ziet de maand eruit in een plain-text-grootboek voor een consultant die deze gewoonten hanteert — een vaste-prijsbuild van $3.500, een maandelijks care plan van $1.200, hulp van een contractor bij de build, en een klein Make-abonnement voorgeschoten voor de klant:
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 USDMet build- en retainerinkomsten op aparte rekeningen toont één query de mix die maand na maand verschuift. Koppel het aan je urenlog — bouwuren tegen de $3.500, supporturen tegen de $1.200 — en het effectieve tarief per opdracht is simpele rekenkunde in plaats van een gevoel.
Een prijsdraaiboek voor je volgende twee offertes
Breng dit in de praktijk de volgende keer dat een prospect om "een simpele automatisering" vraagt:
- Offer Make-builds op basis van getimede Make-schattingen. Als je nooit eerlijk een Make-build hebt bijgehouden, tel dan 50 procent op bij je Zapier-vormige gissing en time het project om de volgende te kalibreren.
- Koppel bij ondertekening een care plan aan elke Zapier-build, geprijsd op basis van verwacht maandelijks taakvolume plus een supportvergoeding — niet als bijgedachte wanneer de eerste overschrijdingsmelding binnenkomt.
- Zet de klant op zijn eigen platformaccount, met zijn eigen kaart, voordat je iets bouwt. Geen doorbelaste abonnementen in je prijsstelling.
- Definieer één grens voor wijzigingsverzoeken op papier: nieuwe apps, nieuwe triggers en scenario-herontwerpen zijn nieuwe offertes, geen aanpassingen. De meeste niet-gefactureerde scope komt binnen via woordgebruik, niet via kwaadwil.
- Beoordeel elk kwartaal het effectieve tarief per project en de winst per klant. Herprijs de onderste 20 procent of laat ze gaan.
De bureaus die geld verliezen op automatiseringswerk worden op papier zelden onderbetaald. Hun offertes zien er prima uit omdat de verliezen nooit op een factuur verschijnen — ze verschijnen als niet-gefactureerde dinsdagmiddagen, gratis afhandeling van overschrijdingen, en builds die twee keer zoveel uren kostten als niemand registreerde. Prijs het platform dat je werkelijk verkoopt, verkoop de retainer die de opdracht werkelijk is, en laat je boeken elke offerte beoordelen. De vergoeding van $3.500 was nooit het probleem. Die twee keer identiek in rekening brengen was dat wel.
