Du bietest 3.500 $ für den Build an. Gleicher Discovery-Call, gleiches Scope-Dokument, gleiche 3.500 $ — egal, ob die Workflows am Ende in Zapier oder in Make landen. Sechs Monate später hat der Zapier-Kunde vierzig unberechnete Stunden „Quick Fixes" und drei unangenehme Gespräche über Task-Überschreitungen verschlungen, während der Make-Build, der dreißig Stunden dauern sollte, sechzig gedauert hat, weil das Szenario ständig neue Verzweigungen und Edge Cases trieb. Gleiche Gebühr, zwei verschiedene Verluste. Die Plattformen haben keinen davon verursacht. Sie identisch zu bepreisen hat es getan.
Dieser Beitrag richtet sich an Automatisierungsberater und kleine Agenturen, die Zapier- und Make-Builds verkaufen. Er erklärt, warum die beiden Plattformen gegensätzliche Risiken tragen, wie du dein Preismodell am Risiko statt am Logo ausrichtest und was du in deinen Büchern erfassen solltest, damit jedes Projekt das nächste besser bepreist.
Die Plattformrechnung, die sich hinter deinem Angebot versteckt
Zapier und Make berechnen dieselbe Idee — ein automatisierter Schritt, der einmal läuft — auf Arten, die schnell auseinanderdriften. Zapier rechnet pro Task ab, und nahezu jeder Schritt in einem Zap zählt: der Trigger, jede Aktion, Formatter- und Filter-Schritte. Make rechnet pro Operation ab, mit deutlich großzügigerem Volumen in jeder Stufe. Die Listenpreise wirken ähnlich, bis man sie mit Schritten und Volumen multipliziert.
Direkt gegenübergestellt bei identischen Workloads zu Listenpreisen von 2026 liegt der Abstand zwischen beiden in jeder Volumenstufe bei etwa dem Fünf- bis Achtfachen. Ein Benchmark, der denselben Workflow-Korb 1.000-mal im Monat laufen ließ, bepreiste ihn mit 73,50 $ auf Zapier gegenüber 9 $ auf Make. Ein sechsstufiger KI-Workflow, der 1.000 Leads im Monat verarbeitet, landet bei etwa 150 bis 300 $ auf Zapier und unter 50 $ auf Make. Bei 10.000 monatlichen Läufen deckt Makes Core-Stufe das Volumen für etwa 9 bis 11 $ im Monat, während die entsprechende Zapier-Task-Anzahl auf einem Plan liegt, der ein Vielfaches kostet.
Nichts davon ist am Build-Tag das Problem deines Kunden. Es wird dein Problem in dem Monat, in dem sich sein Volumen verdoppelt. Ein Zapier-Kunde, der seine Task-Stufe überwächst, bekommt eine Überschreitungsmitteilung mit den Fingerabdrücken deiner Agentur darauf — du hast die Plattform gewählt, du hast die Schrittanzahl entworfen, und jetzt kostet seine Automatisierung jeden Monat mehr. Ein Make-Kunde mit demselben Wachstum absorbiert es meist innerhalb des Plans, den er bereits hat. Wenn deine Pauschale annahm, „der Build ist die ganze Arbeit", dann verfällt die Zapier-Version dieser Annahme zuerst.
Zwei Plattformen, zwei gegensätzliche Arten, Geld zu verlieren
Der Verlust bei einem Zapier-Build kommt meist nach dem Launch. Mehrstufige Zaps sind schnell zusammengebaut, sodass der Build selbst oft unter Budget bleibt — was sich wie ein Erfolg anfühlt, bis die Wartungsphase beginnt. Jeder neue Schritt, den du zur Behebung eines Edge Case hinzufügst, erhöht den monatlichen Task-Verbrauch des Kunden. Jeder Volumensprung wird zu einem Support-Ticket. Weil die Plattformrechnung des Kunden sichtbar und steigend ist, verhandelt er deine Wartungsgebühr genau in dem Moment nach unten, in dem die Arbeitslast wächst. Du hast den Build angeboten; jetzt verschenkst du den Betrieb.
Der Verlust bei einem Make-Build kommt meist vor dem Launch. Make-Szenarien sind günstiger im Betrieb, aber langsamer sauber zu entwerfen. Router, Iteratoren, Fehlerbehandlungsrouten und Data-Store-Lookups belohnen sorgfältige Architektur und bestrafen Eile. Ein Scope-Dokument, das aus Zapier-förmigen Annahmen geschrieben wurde — ein Trigger, ein paar lineare Schritte, fertig — unterschätzt einen Make-Build still um die Hälfte. Agenturen, die ehrlich Zeiten erfassen, stellen oft fest, dass die Make-Version „desselben" Projekts 50 bis 100 Prozent länger dauert zum Bauen, Testen und Dokumentieren. Du hast den Build ebenfalls angeboten; du hast nur eine andere Hälfte davon unterbewertet.
Das ist das Kernargument für plattformbewusste Preisgestaltung: Zapier konzentriert dein Risiko nach der Übergabe, in volumengetriebenem Support und Überschreitungsreibung. Make konzentriert dein Risiko vor der Übergabe, in der Build-Komplexität. Eine Pauschale kann beide Formen nicht abdecken. Sie wird zu großzügig auf der Plattform sein, auf der du schnell bist, und zu dünn dort, wo du langsam bist — und du wirst es monatelang nicht bemerken, weil jeder Verlust sich in unberechneten Stunden versteckt statt in einer Rechnung.
Festpreis vs. Retainer: Passe das Modell an das Risiko an
Festpreis- und Retainer-Engagements sind nicht zwei Varianten derselben Sache. Ein Festpreis-Engagement ist ein Projekt mit vereinbarten Liefergegenständen, einem definierten Zeitrahmen und festen Kosten: Der Kunde bekommt Budgetsicherheit, und du trägst das Kostenrisiko für alles innerhalb des Scope-Dokuments. Ein Retainer ist vorab gekaufte monatliche Kapazität — eine feste Stundenzahl oder ein definiertes Service-Level —, die je nach Bedarf auf neue Builds, Fixes, Monitoring und Verbesserungen angewendet wird. Der Kunde bekommt Kontinuität; du bekommst planbaren Umsatz.
Die Entscheidungsregel ist einfach: Festpreis passt zu stabilen, klar definierten Builds, und Retainer passen zu allem, was sich ständig ändert. Ein einmaliger Lead-Routing-Zap mit eingefrorener Spezifikation ist ein Festpreisprojekt. Ein Automatisierungsprogramm, bei dem der Kunde jeden Monat einen neuen Workflow entdeckt, ist ein Retainer-Kunde in einem Projektangebot. Die meisten Agenturverluste entstehen daraus, die erste Form zu verkaufen, wenn das Engagement eigentlich die zweite ist — einen Build anzubieten, wenn der Kunde eine laufende Fähigkeit kauft.
Speziell bei Zapier-Arbeit solltest du dazu neigen, jeden Festpreis-Build ab Tag eins mit einem Care Plan zu kombinieren. Die Ökonomie der Plattform garantiert Gespräche nach dem Launch über Tasks, Volumen und Planstufen; ein Retainer verwandelt diese von kostenlosem Support in den Service, den der Kunde bereits gekauft hat. Bei Make-Arbeit schütze stattdessen die Build-Phase: Bepreise Festpreise aus getimten Make-Schätzungen, nicht aus Zapier-förmigen Vermutungen, und setze eine engere Änderungsgrenze um Szenario-Redesigns, denn dort landen die Make-Stunden tatsächlich.
Die Zahlen, die deine Sätze setzen sollten
Echte Satzdaten von 2026 aus der Praxis von Automatisierern setzen komplette Kunden-Builds — Lead-Erfassung ins CRM mit Benachrichtigungen, das Brot-und-Butter-Projekt — bei etwa 1.800 bis 4.500 $ Pauschale an, mit monatlichen Retainern zwischen 1.200 und 3.800 $ für Wartung plus neue Workflow-Builds. Stundensätze reichen von 95 bis 235 $, und etablierte Agenturen berechnen 3.000 bis 15.000 $ pro Projekt mit Retainern von 500 bis 5.000 $ im Monat. Wenn deine Pauschale unter dieser Build-Spanne liegt, während deine Lieferstunden denen aller anderen entsprechen, zahlt dir der Markt nicht zu wenig. Dein Angebot tut es.
Die Margenrechnung spricht für Retainer, sobald du über dem ersten Build bist. Branchenbenchmarks setzen die Bruttomargen von Retainern bei etwa 50 bis 70 Prozent gegenüber 40 bis 60 Prozent bei Festpreisprojekten, und Retainer-Kunden sind typischerweise über ihre Lebensdauer drei- bis fünfmal mehr wert. Aber Retainer lecken: Etwa 52 Prozent der Projekte erleben Scope Creep, fast vier von fünf Agenturen berechnen Arbeiten außerhalb des Umfangs selten oder nur manchmal, und ein Retainer mit gesunder Marge kann etwa fünf Margenpunkte pro Jahr durch unberechnetes Scope-Wachstum verlieren. Die Agenturen, die ihre Retainer-Margen halten, sind nicht die, die Scope Creep vermeiden. Es sind die, die ihn messen und neu bepreisen.
Zwei Benchmarks lohnen sich über deinem Schreibtisch. Erstens: Dein effektiver Satz pro Projekt — tatsächlicher Umsatz geteilt durch tatsächlich gearbeitete Stunden — sollte deinen Kostensatz um ein Vielfaches übertreffen, mit genug Puffer, dass Scope Creep und Abschreibungen ihn nicht auffressen können; wenn er nahe an den Kosten landet, ist die Differenz in unberechnete Stunden gegangen. Zweitens: Verfolge diese Zahl getrennt für Zapier-Builds und Make-Builds. Gemittelte Durchschnitte sind der Grund, warum die Quersubventionierung unsichtbar bleibt: Die Plattform, die du korrekt bepreist, verdeckt die, die du es nicht tust.
Was deine Bücher erfassen sollten
Dein Buchhaltungs-Setup deckt diese Lecks entweder auf oder vergräbt sie. Vier Gewohnheiten machen den Unterschied.
Erstens: Trenne Build-Umsatz und Retainer-Umsatz in deinem Kontenplan. Ein einziges Konto „Kundeneinnahmen" vermischt einmalige Projektgebühren mit wiederkehrenden Care Plans, sodass du nicht sehen kannst, welches Modell seine Kosten verdient. Zwei Ertragskonten — Projekte und Retainer — machen jeden Monatsabschluss zu einer Auswertung deines Geschäftsmixes.
Zweitens: Bündle niemals das Plattform-Abo des Kunden in deine Gebühr. Der Kunde sollte Zapier oder Make direkt bezahlen, auf seinem eigenen Konto, selbst wenn du es für ihn einrichtest. In dem Moment, in dem Plattformkosten als Umsatz und Aufwand durch deine Bücher fließen, bläht sich deine oberste Zeile auf, deine Margen verzerren sich, und jedes Plan-Upgrade wird zu einer Neuverhandlung deines Preises. Wenn du ein Abo vorstrecken musst, buche es als durchlaufender Posten in einem eigenen Konto, niemals als Umsatz.
Drittens: Erfasse Stunden gegen Projekte, auch wenn das Projekt Festpreis ist. Unberechnete Stunden sind die Währung, in der beide Plattformrisiken handeln — Zapier-Support nach dem Launch, Make-Überziehungen vor dem Launch —, und Stunden, die du nicht aufzeichnest, sind Verluste, die du nicht in das nächste Angebot einpreisen kannst. Dein Zeittracker ist zuerst ein Preisgestaltungsinstrument und zweitens eine Lohnunterlage.
Viertens: Prüfe die Profitabilität pro Kunde jedes Quartal, nicht nur den Gesamtgewinn. Agenturen, die das tun, finden typischerweise heraus, dass 10 bis 20 Prozent der Kunden unprofitabel sind, sobald die tatsächlichen Lieferkosten gezählt werden — meist die Festpreis-Kunden, die Monate nach dem Launch noch kostenlosen Support erhalten. Diese Prüfung ist die einzelne wertvollste finanzielle Gewohnheit, die die meisten kleinen Agenturen nie aufbauen. Jeder unprofitable Kunde ist entweder ein Neupreisierungsgespräch oder ein Kündigungsschreiben; die Bücher sagen dir, welche, und je länger du wartest, desto teurer wird die Antwort.
So sieht der Monat in einem Plain-Text-Ledger für einen Berater aus, der diese Gewohnheiten pflegt — ein Festpreis-Build von 3.500 $, ein monatlicher Care Plan von 1.200 $, Auftragnehmer-Hilfe beim Build und ein kleines Make-Abo, das für den Kunden vorgestreckt wird:
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 USDMit Build- und Retainer-Einnahmen in getrennten Konten zeigt eine Abfrage den Mix, der sich Monat für Monat verschiebt. Kombiniere sie mit deinem Zeitprotokoll — Build-Stunden gegen die 3.500 $, Support-Stunden gegen die 1.200 $ —, und der effektive Satz pro Engagement ist einfache Arithmetik statt ein Gefühl.
Ein Preis-Playbook für deine nächsten zwei Angebote
Setze das in die Praxis um, wenn der nächste Interessent nach „einer einfachen Automatisierung" fragt:
- Bepreise Make-Builds aus getimten Make-Schätzungen. Wenn du noch nie einen Make-Build ehrlich erfasst hast, addiere 50 Prozent auf deine Zapier-förmige Vermutung und time das Projekt, um das nächste zu kalibrieren.
- Hänge jedem Zapier-Build bei Vertragsunterzeichnung einen Care Plan an, bepreist aus dem erwarteten monatlichen Task-Volumen plus einer Support-Pauschale — nicht als Nachgedanke, wenn die erste Überschreitungsmitteilung eintrifft.
- Setze den Kunden auf sein eigenes Plattform-Konto, mit seiner eigenen Karte, bevor du irgendetwas baust. Keine durchlaufenden Abos in deiner Preisgestaltung.
- Definiere eine Änderungsgrenze schriftlich: neue Apps, neue Trigger und Szenario-Redesigns sind neue Angebote, keine Anpassungen. Der meiste unberechnete Umfang kommt über Vokabular herein, nicht über Böswilligkeit.
- Prüfe den effektiven Satz pro Projekt und den Gewinn pro Kunde vierteljährlich. Bepreise die unteren 20 Prozent neu oder entlasse sie.
Die Agenturen, die bei Automatisierungsarbeit Geld verlieren, sind auf dem Papier selten unterbezahlt. Ihre Angebote sehen gut aus, weil die Verluste nie auf einer Rechnung erscheinen — sie erscheinen als unberechnete Dienstagnachmittage, kostenlose Überschreidungs-Triage und Builds, die doppelt so viele Stunden brauchten, wie niemand erfasst hat. Bepreise die Plattform, die du tatsächlich verkaufst, verkaufe den Retainer, der das Engagement tatsächlich ist, und lass deine Bücher jedes Angebot benoten. Die 3.500-$-Gebühr war nie das Problem. Sie zweimal identisch zu berechnen war es.
