Automation Unit Economics Benchmark 2026

Executive Summary

Automatisierungsplattformen verkaufen nicht dasselbe Produkt in unterschiedlichen Farben. Sie messen Nutzung in unterschiedlichen Einheiten:

• erfolgreiche Actions oder Tasks,
• ausgeführte Module oder Credits,
• vollständige Workflow-Executions,
• aktive Flows,
• eigene Infrastruktur und Betriebsarbeit.

Dadurch kann derselbe Geschäftsprozess bei identischem Volumen völlig unterschiedliche Rechnungsgrößen erzeugen. Die sichtbare Zahl „zehn Workflows“ sagt fast nichts über die tatsächliche Kostenkurve aus.

Dieser Report verbindet ein öffentliches Anbieter-Meter-Modul mit zwölf offengelegten Workflow-Archetypen und drei Volumenstufen. Für jeden Archetyp werden erfolgreiche Erstläufe, Retry-Multiplikator, menschliche Reviewzeit, Fehlernacharbeit und externe API-Kosten separat modelliert. Daraus entstehen 180 Szenariozeilen für Kosten pro erfolgreich abgeschlossenem Geschäftsereignis.

Die verwendeten marginalen Preisraten im erweiterten Kostenmodell sind ausdrücklich illustrative Annahmen, keine behaupteten Anbieterangebote. Die belastbare Primäranalyse liegt in der Übersetzung von Geschäftsereignissen in technische Abrechnungseinheiten.

Zitierfähige Kernergebnisse

1. [CALCULATED] Im Basismodell erzeugen 10.000 identische Lead-Ereignisse 90.000 Zapier-Tasks, 100.000 Make-Credits, 10.000 n8n-Executions oder einen aktiven Activepieces-Flow – vor Retry- und Fehlerpfaden.
2. [CALCULATED] In den zwölf erweiterten Archetypen variiert der angenommene Retry-Multiplikator von 1,05 bis 1,35; damit steigt die abrechenbare technische Arbeit ohne zusätzlichen Geschäftswert.
3. [SCENARIO] Beim Lead-Routing mit 10.000 Ereignissen liegt die modellierte Plattformkomponente je nach Meter zwischen 5 und 1.154 Euro, während Review und Fehlernacharbeit 5.500 Euro ausmachen.
4. [SCENARIO] Bei der modellierten Rechnungsverarbeitung dominieren menschliche Prüfung und Nacharbeit die Gesamtkosten so stark, dass die Wahl des Plattformmeters die Kosten pro akzeptiertem Ergebnis nur gering verändert.
5. [INTERPRETATION] Je höher Fachrisiko und Unsicherheit, desto weniger erklärt die reine Plattformrechnung die Unit Economics.
6. [OBSERVED] Zapier zählt erfolgreiche Actions grundsätzlich als Tasks; Make beschreibt Credits pro Modulaktion; n8n bepreist Cloud-Pläne nach Workflow-Executions; Activepieces veröffentlicht ein aktiver-Flow-Modell.
7. [INTERPRETATION] Self-Hosting beseitigt keine Kosten. Es ersetzt Vendor-Meter durch Compute, Updates, Security, Monitoring, Backup, Incident Response und Ownership.
8. [RECOMMENDATION] Die zentrale Kennzahl sollte Kosten pro erfolgreich abgeschlossenem Geschäftsereignis sein, nicht Tasks, Workflows oder Tokenverbrauch.

---

1. Forschungsdesign

1.1 Forschungsfrage

Wie verändern Meter-Definition, Workflow-Topologie, Retries, Fehler und Human-in-the-Loop die Kosten desselben automatisierten Geschäftsprozesses?

1.2 Vier Analyseebenen

Ebene	Frage
Meter	Welche technische Einheit rechnet die Plattform ab?
Topologie	Wie viele billable Schritte erzeugt ein Ereignis?
Zuverlässigkeit	Wie viele Versuche, Fehlerpfade und Wiederholungen entstehen?
Outcome	Wie viele fachlich akzeptierte Ergebnisse bleiben übrig?

1.3 Formel

Cost per accepted outcome =
(
  Plattformgrundpreis
  + billable units × marginal rate
  + externe APIs
  + menschliche Prüfung
  + Fehlernacharbeit
  + Betriebsanteil
)
/
akzeptierte Geschäftsergebnisse

1.4 Warum dieser Nenner besser ist

Ein Workflow kann technisch billig und fachlich teuer sein:

• niedrige Plattformkosten,
• aber hohe Fehlerquote,
• manuelle Nacharbeit,
• Duplikate,
• falsche Entscheidungen,
• Incident- oder Compliance-Kosten.

Umgekehrt kann eine teurere Plattform durch bessere Governance, Debugging oder geringere Nacharbeit wirtschaftlich überlegen sein. Der Report bewertet diese Produktqualitäten nicht; er zeigt nur, warum sie in die Rechnung gehören.

---

2. Zwölf Workflow-Archetypen

ID	Geschäftsprozess	zentrale Risikotreiber
lead_routing	Lead → CRM, Enrichment, Owner, Notification	Duplikate, falsches Routing
order_sync	Bestellung → ERP, Inventory, Invoice, Fulfilment	doppelte Buchung, Race Conditions
support_triage	Ticket → Klassifikation, Kontext, Routing, Entwurf	Fehlrouting, Halluzination
invoice_processing	OCR → Validate, Match, Approve, Archive	Betrags- und Lieferantenfehler
employee_onboarding	Identitäten, Geräte, Payroll, Training	Berechtigungs- und Offboardingrisiko
marketing_attribution	Consent, Identity Resolution, Destinations	Consent- und Datenqualitätsfehler
daily_reporting	Extract, Transform, Aggregate, Alert	verspätete oder inkonsistente Daten
compliance_screening	Screening, Evidence, Case, Approval	False Positives/Negatives
document_generation	Template, Render, Sign, Deliver	falsche Daten oder Version
catalog_sync	Normalize, Map, Distribute, Verify	Variantendrift, API-Limits
incident_enrichment	Correlate, Enrich, Page, Timeline	Alert-Fatigue, falsche Korrelation
research_brief	Retrieval, Synthesis, Citations, Review	Quellenqualität, Reviewlast

Die vollständigen Annahmen liegen in:

data/FDR-2026-04_workflow_archetypes.csv

2.1 Warum die Archetypen Szenarien sind

Sie sind keine anonymisierten Kundenfälle. Jede Zeile enthält bewusst sichtbare Annahmen zu:

• Actions/Module pro Versuch,
• Retry-Multiplikator,
• First-Pass-Success,
• menschlicher Reviewzeit,
• Nacharbeit bei Fehlern,
• externen API-Kosten.

Der Nutzer des Datensatzes kann jeden Wert ersetzen.

---

3. Drei ökonomische Kurven

3.1 Meter-Kurve

Geschäftsereignisse
× Versuche je Ereignis
× billable Schritte je Versuch
= Abrechnungseinheiten

3.2 Zuverlässigkeits-Kurve

Ereignisse
× (1 - First-Pass-Success)
× Nacharbeitszeit
= Fehlerkosten

3.3 Review-Kurve

Ereignisse
× Prüfminuten
× Arbeitskostensatz
= Human-in-the-Loop-Kosten

[INTERPRETATION] In einfachen, deterministischen Integrationen kann die Meter-Kurve dominieren. In risikoreichen Dokument-, Compliance- oder Research-Prozessen dominieren häufig Review und Nacharbeit.

---

Teil I - Anbieter-Meter und Basismodell

I.1 Forschungsfrage

Wie verändert die Definition der Abrechnungseinheit die Kostenkurve desselben automatisierten Geschäftsprozesses?

Der Report bewertet nicht Funktionsumfang, Stabilität, Integrationsqualität oder Benutzerfreundlichkeit. Er isoliert die ökonomische Wirkung des Meters.

---

I.2 Das normalisierte Geschäftsereignis

Prozessdefinition

Ein eingehender qualifizierter Lead löst folgenden Ablauf aus:

1. Trigger empfangen
2. CRM-Datensatz suchen
3. Kontakt erstellen oder aktualisieren
4. Unternehmen erstellen oder aktualisieren
5. Enrichment-Dienst aufrufen
6. Lead Score speichern
7. Deal erstellen
8. zuständigen Owner bestimmen
9. Slack-/Teams-Nachricht senden
10. Aktivität im Reporting protokollieren

Für den Benchmark werden die Schritte 2 bis 10 als neun erfolgreiche externe Actions modelliert. Make zählt im vereinfachten Modell den eingehenden beziehungsweise lesenden Modulschritt plus neun weitere Module als zehn Credits. Branches, Schleifen, AI, Fehler und Retries sind im Basismodell ausgeschlossen.

Warum ein Geschäftsereignis?

„Ein Workflow“ ist keine wirtschaftliche Einheit. Derselbe Workflow kann einmal pro Monat oder hunderttausendmal laufen. Ein Geschäftsereignis verbindet technische Nutzung mit betrieblicher Bedeutung:

Lead, Bestellung, Ticket, Rechnung, Bewerbung, Incident
→ Workflow-Lauf
→ technische Schritte
→ abrechenbare Einheiten

---

I.3 Anbieterdefinitionen

3.1 Zapier

[OBSERVED] Zapier beschreibt einen Zap als Trigger plus Actions. Ein Trigger verbraucht laut FAQ keinen Task. Jede erfolgreich ausgeführte Action zählt grundsätzlich als eigener Task. Bestimmte eingebaute Datenwerkzeuge – unter anderem Filter, Formatter und Paths – werden in der öffentlichen FAQ als nicht taskpflichtig aufgeführt. Die 2026er Preisseite weist zusätzlich darauf hin, dass AI-Schritte, Code-Laufzeit und Connector-Typ die Task-Rate beeinflussen können.

Folge:

Tasks ≠ Runs
Tasks ≈ erfolgreiche billable Actions × Runs × Rate

3.2 Make

[OBSERVED] Make zählt Modulaktionen als Credits. Lesen, Suchen, Erstellen, Aktualisieren, Löschen und bestimmte Transformationen können jeweils Credits verbrauchen. Router und bestimmte Error-Handler sind ausgenommen. Fortgeschrittene AI-Funktionen können mehr als einen Credit benötigen.

Folge:

Credits ≈ ausgeführte billable Module × Bundles × Runs

Bundles, Iteratoren und Suchergebnisse können die Zahl erhöhen.

3.3 n8n

[OBSERVED] n8n veröffentlicht eine Preislogik nach vollständigen Workflow-Executions, unabhängig von der Komplexität und mit unbegrenzten Schritten. Cloud-Pläne enthalten feste Execution-Kontingente; eine Community Edition ist selbst hostbar.

Folge:

Executions ≈ gestartete/gezählte Workflow-Läufe

Die technische Infrastruktur muss die tatsächlichen Schritte trotzdem verarbeiten. „Ein Meter“ bedeutet nicht „keine Rechenkosten“.

3.4 Activepieces

[OBSERVED] Activepieces bepreist den Standardplan nach aktiven Flows. Zehn aktive Flows sind öffentlich als kostenlos ausgewiesen; darüber kostet ein aktiver Flow fünf US-Dollar pro Monat. Runs werden als unbegrenzt beschrieben. Die Community Edition ist MIT-lizenziert und selbst hostbar.

Folge im Standardplan:

Abrechnung ≈ Zahl aktiver Flows

Die Grenze verschiebt sich von Volumen zu Governance, Flow-Anzahl und gegebenenfalls Enterprise-Funktionen.

---

I.4 Ergebnis des Billing-Unit-Modells

Geschäftsereignisse / Monat	Zapier Tasks	Make Credits	n8n Executions	Activepieces aktive Flows
1.000	9.000	10.000	1.000	1
10.000	90.000	100.000	10.000	1
100.000	900.000	1.000.000	100.000	1

Maschinenlesbare Fassung:

data/FDR-2026-04_billing_unit_baseline.csv

Wichtige Einschränkung

Die Zahlen sind keine Rechnungsprognose. Sie übersetzen nur die definierte Workflow-Topologie in Standard-Meter. Insbesondere:

• Zapier kann für AI, Code und bestimmte Connector-Nutzung abweichende Task-Raten anwenden.
• Make kann bei Bundles, Iteratoren, AI und mehrstufiger Verarbeitung zusätzliche Credits erzeugen.
• n8n kann Sub-Workflows, Retries und Fehlerläufe nach seiner jeweiligen Execution-Definition zählen.
• Activepieces kann bei Governance, Hosting oder Enterprise-Anforderungen zusätzliche Kosten haben.
• externe APIs verursachen eigene Gebühren.

---

I.5 Öffentliche Preisanker am Datenstichtag

Plattform	Öffentlicher Anker	Meter
Zapier	Free: 100 Tasks; Professional ab 19,99 USD/Monat; Team ab 69 USD/Monat	Tasks / variable Task-Raten
Make	Free: 1.000 Credits; Core 9 USD bei 10.000 Credits; Pro 16 USD; Teams 29 USD	Credits
n8n Cloud	Starter 20 EUR für 2.500 Executions; Pro 50 EUR für 10.000	Workflow-Executions
n8n Business	667 EUR für 40.000 Executions, self-hosted	Workflow-Executions plus eigene Infrastruktur
Activepieces Standard	zehn aktive Flows frei, danach 5 USD je aktivem Flow	aktive Flows
Community Editions	n8n verfügbar; Activepieces MIT	Infrastruktur und Betrieb statt Vendor-Meter

Die Tabelle ist eine historische Momentaufnahme. Zahlungsintervall, Region und dynamische Selektoren sind vor Publikation neu zu erfassen.

Warum keine durchgehende Preisrangliste?

Bei Zapier wird die konkrete Preisstufe für 10.000, 100.000 oder mehr Tasks dynamisch im Selektor bestimmt. Eine statische Zahl ohne dokumentierte UI-Auswahl wäre nicht reproduzierbar. Der Report veröffentlicht deshalb keine geschätzten Großvolumenpreise.

Das ist eine bewusste Forschungsentscheidung:

Eine Lücke ist belastbarer als eine erfundene Zahl.

---

I.6 Topologie-Effekte

6.1 Branches

Bei einem Router oder Path laufen nicht immer alle Pfade. Die Kosten hängen von:

• Anzahl Pfade
• Anteil je Pfad
• Aktionen pro Pfad
• parallelen Pfaden
• Fehlerbehandlung

ab.

6.2 Schleifen

Ein Workflow mit zehn Schritten kann bei einem Array mit 100 Elementen hunderte oder tausende Modulaktionen ausführen. Die sichtbare Canvas-Komplexität unterschätzt dann die Rechnungsmenge.

6.3 Polling

Ein Trigger kann kostenfrei sein und trotzdem Infrastruktur belasten. Anbieter behandeln Polling unterschiedlich. Zusätzlich entstehen API-Limits bei der Quellanwendung.

6.4 Retries und Fehler

Ein fehlgeschlagener Schritt kann:

• keine billable Action erzeugen,
• bereits vorherige Schritte trotzdem abgerechnet haben,
• automatisch erneut laufen,
• einen Error-Handler auslösen,
• eine manuelle Wiederholung benötigen.

Ein Kostenmodell muss Erfolgs-, Fehler- und Retry-Pfade abbilden.

6.5 AI-Schritte

AI erweitert die Kostenfunktion:

Automation-Meter
+ Modell-Token
+ Tool Calls
+ Retrieval
+ Vektorspeicher
+ Evaluations- und Guardrail-Schritte

Ein „AI Agent“ ist deshalb selten nur ein zusätzlicher Workflow-Schritt.

---

I.7 Self-Hosted-TCO

Self-Hosting wird häufig als „kostenlos“ bezeichnet, wenn die Softwarelizenz kostenfrei ist. Für einen produktiven Betrieb entstehen mindestens:

• Compute
• Storage
• Datenbank
• Backups
• Monitoring
• Alerting
• TLS/DNS
• Updates
• Security
• Incident Response
• interne Administration

Die folgenden Profile sind [SCENARIO] und keine FW-Delta-Preisliste:

Profil	Compute/Storage	Backup/Monitoring	Administration	Monatliche TCO
Lean	€30	€20	2 h × €75	€200
Production	€120	€100	6 h × €75	€670
High availability	€400	€200	16 h × €75	€1800

Maschinenlesbare Fassung:

data/FDR-2026-04_selfhosted_ops_scenarios.csv

Interpretation

• Das Lean-Profil kann für nicht kritische interne Workflows plausibel sein.
• Das Production-Profil berücksichtigt mehr Betriebszeit und Observability.
• High Availability benötigt Redundanz, Tests, On-call und mehr Administration.

[INTERPRETATION] Self-Hosting wird wirtschaftlich interessant, wenn Volumen stark wächst, viele Schritte pro Ereignis existieren, Governance wichtig ist oder dieselbe Plattform viele Workflows bündelt. Bei wenigen einfachen Automationen kann SaaS klar günstiger sein.

---

I.8 Der bessere Vergleich: Kosten je erfolgreichem Geschäftsereignis

Plattformkosten
+ externe API-Kosten
+ Betrieb
+ Fehlerbehandlung
+ Administration
--------------------------------
erfolgreich abgeschlossene Ereignisse

Beispielhafte Kennzahl:

Cost per completed order
Cost per qualified lead
Cost per resolved ticket
Cost per processed invoice

Diese Kennzahl verhindert zwei Fehler:

1. günstige Plattformkosten bei hoher Fehlerquote,
2. niedrige Task-Kosten bei unnötig aufgeblähten Workflows.

---

I.9 Architekturentscheidungen mit wirtschaftlicher Wirkung

Reduziere externe Aktionen

Daten lokal zusammenführen, bevor mehrere APIs geschrieben werden.

Nutze idempotente Writes

Wiederholungen dürfen keine Duplikate oder doppelte Kosten erzeugen.

Trenne Orchestrierung und Business Logic

Komplexe Fachlogik in testbaren Code oder Services auslagern, wenn Canvas-Schritte explodieren.

Batch statt Einzelaktion

Wo fachlich zulässig, mehrere Datensätze in einem API-Aufruf verarbeiten.

Event statt Polling

Webhooks und Queues reduzieren unnötige Checks und verbessern Latenz.

Meter beobachten

Dashboard für:

• Ereignisse
• billable Units
• Fehler
• Retries
• Kosten je Workflow
• Kosten je Geschäftsergebnis

---

I.10 Entscheidungsmatrix

Situation	Tendenz
wenige, einfache Standardautomationen	SaaS-Plan oft wirtschaftlich
viele Schritte, hohes Volumen	Execution- oder Self-Hosted-Modell prüfen
viele kleine Flows, geringe Run-Zahl	aktiver-Flow-Modell kann ungünstig werden
wenige Flows, sehr hohe Run-Zahl	aktiver-Flow-Modell kann attraktiv sein
starke Governance/SSO/Audit	Enterprise- oder eigener Betrieb
häufige Connector-Änderungen	Managed-Plattform reduziert Wartung
proprietäre Fachlogik	portabler Code-/Service-Layer
harte Latenz- oder Datenresidenzanforderung	eigener Betrieb oder kontrollierte Runtime

---

---

4. Erweiterter 12×3-Benchmark

4.1 Abrechnungseinheiten nach Volumen

Die Datei FDR-2026-04_billing_units_by_workflow_and_volume.csv enthält für jeden Archetyp:

• 1.000, 10.000 und 100.000 Ereignisse,
• erwartete Versuche,
• erwartete erfolgreiche Ergebnisse,
• Tasks,
• Credits,
• Executions,
• aktive Flows,
• Reviewstunden,
• Fehlernacharbeitsstunden,
• externe API-Kosten.

4.2 Beispiel: Lead Routing, 10.000 Ereignisse

Modell	Plattformkosten*	Review/Nacharbeit	externe APIs	Gesamtkosten	EUR pro akzeptiertem Ergebnis
Task-Meter	1.154	5.500	32	6.686	0,68
Credit-Meter	136	5.500	32	5.668	0,58
Execution-Meter	92	5.500	32	5.624	0,57
Active-Flow-Meter	5	5.500	32	5.537	0,56
Self-hosted Production	670	5.500	32	6.202	0,63

* [SCENARIO] Die Plattformkosten verwenden die offengelegten illustrativen Raten aus FDR-2026-04_cost_model_assumptions.csv. Sie sind keine Anbieterangebote.

4.3 Beispiel: Invoice Processing, 10.000 Ereignisse

Modell	Plattformkosten*	Review/Nacharbeit	Gesamtkosten	EUR pro akzeptiertem Ergebnis
Task-Meter	1.400	75.000	76.538	8,50
Credit-Meter	176	75.000	75.314	8,37
Execution-Meter	96	75.000	75.234	8,36
Active-Flow-Meter	5	75.000	75.143	8,35
Self-hosted Production	670	75.000	75.808	8,42

[INTERPRETATION] Sobald fachliche Prüfung mehrere Minuten pro Ereignis erfordert, ist das Plattformmeter nicht mehr der primäre Hebel. Eine Verbesserung der First-Pass-Qualität um wenige Prozentpunkte kann wirtschaftlich wichtiger sein als ein günstigerer Workflow-Tarif.

4.4 Beispiel: Research Brief, 10.000 Ereignisse

Im Szenario liegt die menschliche Prüf- und Nacharbeitskomponente bei 235.000 Euro. Die Unterschiede zwischen Plattformmetern bewegen sich dagegen im niedrigen vierstelligen Bereich oder darunter.

Das bedeutet nicht, dass 10.000 Research Briefs realistisch oder sinnvoll sind. Die Volumenstufe ist ein Stress-Test, der zeigt, welche Variable skaliert.

---

5. Topologie-Risiken im Detail

5.1 Fan-out

Ein Ereignis verteilt sich auf viele Ziele. Die Geschäftszahl bleibt eins, die technische Arbeit vervielfacht sich.

1 Bestellung
→ ERP
→ CRM
→ Warehouse
→ Finance
→ Customer messaging
→ Analytics

5.2 Iteratoren und Bundles

Ein sichtbarer Schritt kann intern über Hunderte Elemente laufen. Die Canvas-Komplexität unterschätzt die Meter- und Rechenlast.

5.3 Retries ohne Idempotenz

Ein Retry ist nur dann sicher, wenn derselbe Request mehrfach verarbeitet werden kann, ohne unerwünschte Doppelwirkung. Kritische Writes brauchen:

• Idempotency Keys,
• dedizierte Event IDs,
• Upsert-Semantik,
• deduplication store,
• deterministische Retry Policy,
• Dead-Letter Queue.

5.4 Teilfehler

Ein Workflow kann nach sechs erfolgreichen Writes beim siebten Schritt scheitern. Die Plattformrechnung und der fachliche Zustand sind dann beide partiell. Ein Design muss Kompensation oder Wiederaufnahme definieren.

5.5 Menschliche Ausnahmebehandlung

Die Ausnahmequote ist oft nicht konstant. Sie steigt bei:

• neuem Prozess,
• neuen Datenquellen,
• saisonalen Peaks,
• API-Änderungen,
• unvollständigen Stammdaten,
• neuen AI-Modellen,
• regulatorischen Änderungen.

Ein belastbares Modell verwendet daher nicht nur einen Mittelwert, sondern P50/P90-Ausnahmequoten.

---

6. Architekturregeln mit ökonomischer Wirkung

6.1 Business Logic aus der Canvas lösen

Wenn Fachlogik aus Dutzenden visuellen Schritten besteht, wird jede Ausführung teuer und schwer testbar. Komplexe Regeln können in versionierten, unit-testbaren Services sinnvoller sein.

6.2 Event Contracts definieren

Jedes Ereignis braucht:

• stabile ID,
• Schema-Version,
• Erzeugungszeit,
• Quelle,
• fachliche Bedeutung,
• Wiederholungssemantik,
• PII-Klassifikation.

6.3 Batch dort, wo Fachlichkeit es erlaubt

Bulk APIs reduzieren Roundtrips und Meter. Sie erhöhen aber Batch-Radius und Fehlerkomplexität. Daher müssen Batchgröße und Wiederaufnahme getestet werden.

6.4 Observability pro Outcome

Nicht nur „Workflow succeeded“, sondern:

• welches Geschäftsergebnis entstand,
• welche Datensätze wurden verändert,
• welche externe Antwort wurde genutzt,
• welches Retry/Manual Review folgte,
• wie hoch waren Zeit und Kosten.

6.5 Kostenbudgets als Guardrail

Für volumen- oder AI-sensitive Prozesse:

max_units_per_event
max_retries
max_external_api_cost
max_review_minutes
max_total_cost_per_outcome

Bei Überschreitung muss der Prozess stoppen, degradieren oder in menschliche Bearbeitung wechseln.

---

7. Entscheidungsmodell

Situation	tendenziell passendes Modell
wenige einfache Workflows, geringe Kritikalität	SaaS-Meter oft wirtschaftlich
viele Schritte, hohes Volumen	Execution-/Flow-Modell oder Self-Hosting prüfen
viele Teams, Governance-Anforderungen	Enterprise-Funktionen und Betrieb gemeinsam bewerten
hochriskante AI-/Dokumentprozesse	Human Review und Fehlerkosten zuerst optimieren
stark schwankendes Volumen	variable Kosten gegen Kapazitätsreserve vergleichen
kritischer 24/7-Prozess	HA, On-call, DR und Vendor-Support in TCO aufnehmen

---

8. Failure Economics: Der Preis eines technisch erfolgreichen, fachlich falschen Laufs

Eine Automation kann in der Plattform als erfolgreich erscheinen und trotzdem wirtschaftlich scheitern. Der HTTP-Request antwortet mit 200, die Queue bestätigt die Nachricht und der Workflow erreicht seinen letzten Node. Fachlich kann dennoch ein falscher Kunde aktualisiert, eine Rechnung doppelt gebucht, ein Lead dem falschen Gebiet zugeordnet oder ein Dokument mit einer veralteten Vorlage erzeugt worden sein. Deshalb trennt dieser Report drei Erfolgsbegriffe:

Ebene	Definition	typisches Messsignal
technische Ausführung	Der Workflow lief ohne ungefangenen technischen Fehler bis zum Ende.	Execution-Status, Exit-Code, Queue-Ack
fachliche Annahme	Das Ergebnis erfüllt Geschäftsregeln und wird vom nachgelagerten Prozess akzeptiert.	Validierung, Freigabe, Reconciliation
wirtschaftlicher Outcome	Das Ergebnis erzeugt den gewünschten Wert ohne überproportionale Folge- oder Risikokosten.	Abschluss, verbuchte Zahlung, korrektes Fulfilment

Die Differenz ist für die Unit Economics zentral. Ein Anbieter kann 99,9 Prozent technische Erfolgsquote melden, während die Organisation zwölf Prozent der Ergebnisse manuell korrigiert. Diese Korrekturarbeit taucht auf der Plattformrechnung nicht auf. Sie liegt in Finance, Operations, Support oder Engineering und wird damit leicht aus der Toolentscheidung herausgerechnet.

8.1 Erwartete Fehlerkosten

Für einen Prozess mit mehreren Fehlerklassen kann die erwartete Fehlerlast so modelliert werden:

Expected failure cost per event =
Σ (Wahrscheinlichkeit der Fehlerklasse i × Kosten der Fehlerklasse i)

Einfaches Beispiel für eine Rechnungsautomation:

Fehlerklasse	angenommene Wahrscheinlichkeit	angenommene Folgekosten	Erwartungswert je Ereignis
OCR-Feld falsch, intern korrigierbar	2,0 %	8 EUR	0,16 EUR
doppelte Buchung, vor Zahlung erkannt	0,3 %	45 EUR	0,14 EUR
falsche Zahlung ausgelöst	0,05 %	800 EUR	0,40 EUR
Compliance-/Auditabweichung	0,02 %	2.500 EUR	0,50 EUR
Summe	-	-	1,20 EUR

Die Werte sind ein Szenario, keine beobachteten Branchenraten. Sie zeigen aber einen häufigen Effekt: Seltene, teure Fehler können die sichtbaren Plattformkosten deutlich übersteigen. Eine Automation, die technisch 0,05 Euro je Ereignis kostet, ist nicht automatisch wirtschaftlich, wenn ihr erwarteter Fehlerwert 1,20 Euro beträgt.

8.2 Retry ist nicht Recovery

Retries sind sinnvoll bei transienten Fehlern: Timeouts, Rate Limits oder vorübergehend nicht erreichbaren Endpunkten. Sie sind gefährlich, wenn der Prozess nicht idempotent ist oder der fachliche Zustand unbekannt bleibt. Ein Retry kann dann denselben Auftrag erneut auslösen.

Jede produktive Automation sollte mindestens unterscheiden:

1. transienter technischer Fehler - Wiederholung mit Backoff;
2. permanenter technischer Fehler - Dead-Letter-Queue und Bearbeitung;
3. fachliche Validierungsabweichung - kein Retry, sondern Klärung;
4. unklarer Commit-Status - Reconciliation, bevor erneut geschrieben wird;
5. Downstream-Erfolg bei lokalem Timeout - Idempotency-Key oder Zustandsabfrage;
6. menschlich abgelehnte Entscheidung - Lern- oder Regelprozess, nicht blindes Wiederholen.

Die Kostenformel muss deshalb nicht nur die Anzahl der Versuche, sondern auch die Verteilung der Retry-Ursachen berücksichtigen. Ein pauschaler Multiplikator von 1,10 ist für ein transparentes Szenario brauchbar; für einen Produktionsprozess braucht es Telemetrie nach Fehlerklasse.

8.3 Fehlerbudget statt Null-Fehler-Versprechen

Ein belastbarer Prozess definiert vorab, welche Fehler tolerierbar sind und welche einen automatischen Stopp auslösen. Ein mögliches Fehlerbudget enthält:

• maximale technische Fehlerrate je Stunde und Tag;
• maximale fachliche Ablehnungsrate;
• maximale Zahl ungeklärter Ereignisse;
• maximalen monetären Exposure-Wert;
• maximale Queue-Alterung;
• maximalen Anteil manuell korrigierter Outcomes;
• verpflichtende Eskalation bei bestimmten Daten- oder Risikoklassen.

Das macht Kosten und Zuverlässigkeit gemeinsam steuerbar. Ohne Fehlerbudget wird die Automatisierung meist erst dann überprüft, wenn Supporttickets oder Buchungsdifferenzen sichtbar werden.

---

9. Kapazitätsmodell: Wenn Erzeugung schneller skaliert als Prüfung

Automatisierung erhöht häufig die Ankunftsrate von Fällen, ohne die Kapazität des Prüf- oder Ausnahmeprozesses im selben Maß zu erhöhen. Das ist besonders bei AI-gestützter Klassifikation, Dokumentverarbeitung und Research relevant. Die Queue wächst nicht, weil der Hauptworkflow langsam ist, sondern weil die Ausnahmen schneller entstehen, als Menschen sie bearbeiten.

9.1 Minimales Queue-Modell

Ausnahme-Ankunftsrate λ =
Ereignisse pro Stunde × Ausnahmequote

Prüfkapazität μ =
Reviewer × 60 / durchschnittliche Prüfminuten

Wenn λ ≥ μ, wächst die Queue strukturell. Eine kurzfristige Spitzenlast kann durch Puffer absorbiert werden; ein dauerhaftes Verhältnis oberhalb von eins erzeugt zwangsläufig Rückstand.

Beispiel:

20.000 Ereignisse/Tag
× 3 % Ausnahmen
= 600 Prüfungen/Tag

4 Reviewer
× 7 produktive Stunden
× 60 Minuten
/ 4 Minuten pro Prüfung
= 420 Prüfungen/Tag

Der Prozess erzeugt in diesem Szenario täglich 180 Fälle mehr, als er abbauen kann. Die technische Automation kann dennoch „grün“ sein. Wirtschaftlich entsteht eine alternde Queue, verzögerte Bearbeitung und schließlich eine zweite informelle Automation: Menschen exportieren Daten nach Excel, priorisieren manuell oder umgehen Kontrollen.

9.2 Vier Hebel gegen die Ausnahme-Queue

Hebel	Wirkung	Risiko
First-Pass-Success erhöhen	senkt Ankunftsrate	kann zusätzliche Entwicklungs- oder Modelkosten erzeugen
Reviewzeit reduzieren	erhöht Servicekapazität	Gefahr oberflächlicher Prüfung
risikobasiert routen	konzentriert Menschen auf kritische Fälle	benötigt gute Klassifikation und Kalibrierung
Prozessvolumen begrenzen	schützt Betrieb	reduziert kurzfristigen Durchsatz

Die sinnvollste Maßnahme ist nicht automatisch mehr Personal. Häufig lohnt sich zuerst eine Pareto-Analyse der Ausnahmegründe: zehn wiederkehrende Datenfehler können einen Großteil der Queue verursachen.

9.3 Pflichtmetriken für Reviewkapazität

• Ausnahmequote nach Ursache;
• Queue-Alter p50/p90/p99;
• Prüfminuten je Fall;
• Wiedereröffnungs- oder Rework-Rate;
• Anteil automatisch freigegebener Fälle;
• Anteil manuell übersteuerter Entscheidungen;
• Kosten je angenommener Ausnahme;
• Fehler nach Freigabe;
• Reviewer-Auslastung und Konzentration auf einzelne Personen.

Eine hohe Reviewer-Auslastung ist nicht automatisch gut. Bei 95 bis 100 Prozent laufender Auslastung fehlen Puffer für Spitzen, komplexe Fälle und Incidents. Das System wird fragil.

---

10. Messprotokoll für einen realen 30-Tage-Benchmark

Der Report liefert ein Szenariomodell. Vor einer Migration oder einem Plattformwechsel sollte eine Organisation einen eigenen kontrollierten Messzeitraum durchführen.

Phase 1 - Prozessgrenze festlegen

Dokumentieren:

• Start- und Endereignis;
• fachlich akzeptierter Outcome;
• alle externen Systeme;
• menschliche Entscheidungen;
• Datenklassen und Rechtsgrundlagen;
• finanzielle oder operative Fehlerklassen;
• vorhandene SLOs und Eskalationswege.

Phase 2 - Event Ledger aufbauen

Jedes Geschäftsereignis erhält eine stabile event_id. Diese ID begleitet Trigger, Workflow, externe APIs, Retries, Review, Zielsystem und Reconciliation. Ohne durchgehende Korrelation kann ein Unternehmen technische Ausführungen nicht zuverlässig zu fachlichen Outcomes und Kosten verbinden.

Minimalfelder:

event_id
workflow_version
started_at
completed_at
attempt_count
billable_units
external_api_cost
review_minutes
outcome_status
failure_class
rework_minutes
financial_exposure

Phase 3 - Baseline ohne Architekturänderung

Mindestens zwei normale Betriebswochen erfassen. Ausreißer nicht löschen, sondern kennzeichnen. Ein Benchmark nur an ruhigen Tagen unterschätzt Rate Limits, Monatsabschlüsse, Marketing-Peaks und saisonale Effekte.

Phase 4 - Parallel- oder Shadow-Run

Eine alternative Plattform oder Architektur verarbeitet dieselben oder repräsentative Ereignisse ohne produktive Seiteneffekte. Bei schreibenden Prozessen sind Mock-Endpunkte, Dry-Runs oder isolierte Staging-Systeme notwendig.

Phase 5 - Outcome-Reconciliation

Verglichen werden nicht nur Logs, sondern fachliche Ergebnisse:

• identische Datensätze;
• identische Beträge;
• identische Routing-Entscheidungen;
• vollständige Attachments;
• korrekte Berechtigungen;
• gleiche oder definierte Latenz;
• nachvollziehbare Abweichungen.

Phase 6 - Normalisierte Kostenrechnung

Monthly normalized cost =
subscription + overage + APIs + compute + labor + expected failure cost

Arbeitszeit muss mit einer offengelegten Vollkostenrate bewertet werden. Reine Gehaltskosten unterschätzen Arbeitgeberanteile, Tooling, Management und Opportunitätskosten; ein pauschaler Beratertagessatz kann sie überschätzen. Wichtig ist weniger der „richtige“ eine Satz als Transparenz und Sensitivität.

Phase 7 - Entscheidung mit Konfidenzintervall

Nicht nur einen Punktwert veröffentlichen. Bei schwankenden Volumina und Fehlerraten sollten mindestens Low/Base/High-Szenarien ausgewiesen werden. Bei genügend Events können Bootstrap-Intervalle für Cost per Outcome und Success Rate berechnet werden.

---

11. Beschaffungs- und Architekturcheckliste

Meter und Vertrag

1. Was ist die kleinste abrechenbare Einheit?
2. Zählen Trigger, Filter, Router, Iteratoren und interne Transformationen?
3. Werden fehlgeschlagene Schritte, Retries oder Replay abgerechnet?
4. Gibt es harte Limits, Soft Limits oder automatische Overage?
5. Wie verändern Team-, Environment- und Governance-Funktionen den Tarif?
6. Können historische Ausführungsdaten vollständig exportiert werden?
7. Welche Preisänderungs- und Renewal-Regeln gelten?

Zuverlässigkeit

8. Unterstützt die Plattform Idempotency-Keys oder müssen sie selbst gebaut werden?
9. Gibt es Dead-Letter-Queues, Replay mit Versionierung und deterministische Reconciliation?
10. Wie werden Partial Failures sichtbar?
11. Lassen sich Workflows versionieren, testen und reproduzierbar deployen?
12. Sind Secrets, Rollen und Produktionszugriffe getrennt?
13. Wie lange bleiben Execution-Daten erhalten?

Wirtschaftlichkeit

14. Was kostet ein erfolgreiches Geschäftsereignis bei p50-, p90- und Peak-Volumen?
15. Wie hoch sind menschliche Review- und Reworkkosten?
16. Welche externen APIs haben eigene Mindestabnahmen oder Overage?
17. Was kostet ein Incident einschließlich Recovery und Kundenwirkung?
18. Welche Kosten entstehen beim Export oder Plattformwechsel?
19. Welcher Anteil der Rechnung ist produktiver Verbrauch, welcher Governance?
20. Welche Annahme verändert das Ergebnis am stärksten?

Ownership

21. Können Definitionen, Credentials, Variablen und Historie exportiert werden?
22. Ist die Logik außerhalb des Produkts lesbar und testbar?
23. Kann ein anderes Team den Betrieb anhand der Dokumentation übernehmen?
24. Sind Runbooks, Dashboards und Alert-Regeln Teil der Übergabe?
25. Gibt es einen geprüften Restore- und Exit-Pfad?

Ein Anbieter muss nicht in jeder Zeile maximal offen oder portabel sein. Die Checkliste zwingt jedoch dazu, die Kostenentscheidung nicht auf einen Monatsbetrag zu reduzieren.

---

12. Rechenbeispiel: Warum eine billigere Execution teurer enden kann

Zwei Architekturen verarbeiten monatlich 50.000 Supportfälle.

Architektur A

• Plattform und APIs: 1.200 EUR;
• First-Pass-Success: 88 Prozent;
• 6.000 Fälle benötigen je 4 Minuten Review;
• Vollkostenrate: 45 EUR/Stunde;
• Nacharbeit bei zwei Prozent der Fälle: durchschnittlich 12 EUR.

Review = 6.000 × 4/60 × 45 = 18.000 EUR
Rework = 1.000 × 12 = 12.000 EUR
Gesamt = 31.200 EUR
Cost per event = 0,624 EUR

Architektur B

• Plattform und APIs: 3.500 EUR;
• First-Pass-Success: 96 Prozent;
• 2.000 Fälle benötigen je 3 Minuten Review;
• gleiche Vollkostenrate;
• Nacharbeit bei 0,6 Prozent: durchschnittlich 12 EUR.

Review = 2.000 × 3/60 × 45 = 4.500 EUR
Rework = 300 × 12 = 3.600 EUR
Gesamt = 11.600 EUR
Cost per event = 0,232 EUR

Das Szenario beweist nicht, dass eine bestimmte Plattform höhere Qualität liefert. Es zeigt, warum eine Toolentscheidung ohne Outcome- und Fehlerdaten ökonomisch unvollständig ist. Der Plattformpreis von B ist fast dreimal so hoch; die Gesamtkosten liegen im Szenario dennoch um rund 63 Prozent niedriger.

---

13. Visualisierungsspezifikation

Chart 1 - Meter-Expansion

• Daten: FDR-2026-04_billing_unit_baseline.csv
• X: Geschäftsereignisse
• Y: technische Einheiten
• logarithmische Skala optional, deutlich kennzeichnen

Chart 2 - Workflow-Archetypen als Heatmap

• Daten: FDR-2026-04_workflow_archetypes.csv
• Dimensionen: Schritte, Retry, Success, Review, Rework
• keine Rangfolge „best/worst“

Chart 3 - Kostenkomponenten je Outcome

• Daten: FDR-2026-04_cost_per_completed_event_scenarios.csv
• gestapelte Balken: Plattform, Review/Rework, externe API
• Filter nach Workflow und Volumen

Chart 4 - Plattformanteil an Gesamtkosten

• Berechnung aus derselben Datei
• zeigt, wann Toolpreis oder Facharbeit dominiert

Chart 5 - Retry-Multiplikator

• Daten: FDR-2026-04_workflow_archetypes.csv
• X: Workflow
• Y: erwartete Versuche pro Ereignis

---

14. Reproduzierbarkeit

Datendateien

• data/FDR-2026-04_billing_unit_baseline.csv
• data/FDR-2026-04_selfhosted_ops_scenarios.csv
• data/FDR-2026-04_workflow_archetypes.csv
• data/FDR-2026-04_billing_units_by_workflow_and_volume.csv
• data/FDR-2026-04_cost_model_assumptions.csv
• data/FDR-2026-04_cost_per_completed_event_scenarios.csv

Pflichtregeln

1. Anbieter-Meter vor Publikation live verifizieren.
2. Szenarioraten nicht als Anbieterpreise darstellen.
3. Trigger, Actions, Bundles, Retries und Fehlerpfade separat zählen.
4. First-Pass-Success nicht mit technischer Execution Success verwechseln.
5. menschliche Prüfzeit sichtbar halten.
6. externe API- und AI-Kosten separat ausweisen.
7. Self-Hosting mit Arbeit und Bereitschaft rechnen.
8. Outcome-Nenner fachlich definieren.

---

15. Grenzen

1. Die zwölf Archetypen sind synthetisch.
2. First-Pass-Success und Reviewzeiten sind Annahmen.
3. Illustrative Meter-Raten bilden keine tatsächlichen Verträge ab.
4. Anbieterpreise können nicht linear skalieren.
5. Planlimits, Overage, Enterprise-Rabatte und Mindestabnahmen fehlen im Szenariomodell.
6. Externe API- und AI-Kosten variieren stark.
7. Qualitäts- und Risikokosten sind nur teilweise modelliert.
8. Self-Hosted-Kosten hängen von Kritikalität, Team und Architektur ab.
9. Funktionsumfang und Nutzererfahrung wurden nicht bewertet.
10. Ein niedriger Cost per Outcome beweist keine Compliance oder Qualität.

---

16. Zitierhinweise

Zulässig:

„Das FW-Delta-Modell zeigt, dass derselbe Prozess je nach Plattform als Tasks, Credits, Executions oder aktive Flows gemessen wird. Die technischen Einheiten sind deshalb nicht direkt vergleichbar.“

Nicht zulässig:

„Activepieces ist immer günstiger als Zapier.“

Zulässig:

„In den offengelegten Dokument- und Research-Szenarien dominierten Review- und Fehlerkosten die Plattformkosten.“

Nicht zulässig:

„Menschliche Prüfung kostet bei Automatisierung grundsätzlich mehr als die Software.“

---

17. Versionshistorie

• 1.0 · Juli 2026 · Öffentliches Vier-Meter-Modul mit zwölf Workflow-Archetypen, drei Volumenstufen und 180 Szenariozeilen konsolidiert.
• Live-Version offen · Anbieterpreise, Meterregeln und Help-Center-Dokumente vor Veröffentlichung neu prüfen.

---

18. Quellen

1. Zapier, „Plans & Pricing“, https://zapier.com/pricing, abgerufen im Juli 2026.
2. Zapier Help, „How is task usage measured in Zapier?“, https://help.zapier.com/hc/en-us/articles/8496196837261-How-is-task-usage-measured-in-Zapier, abgerufen im Juli 2026.
3. Zapier Help, „Pay-per-task billing“, https://help.zapier.com/hc/en-us/articles/22976442824653-Pay-per-task-billing, abgerufen im Juli 2026.
4. Make, „Pricing“, https://www.make.com/en/pricing, abgerufen im Juli 2026.
5. Make Help Center, „Credits“, https://help.make.com/credits, abgerufen im Juli 2026.
6. Make Help Center, „Operations“, https://help.make.com/operations, abgerufen im Juli 2026.
7. n8n, „Pricing“, https://n8n.io/pricing/, abgerufen im Juli 2026.
8. n8n Docs, „Community edition features“, https://docs.n8n.io/hosting/community-edition-features/, abgerufen im Juli 2026.
9. n8n Docs, „Scaling“, https://docs.n8n.io/hosting/scaling/overview/, abgerufen im Juli 2026.
10. Activepieces, „Pricing“, https://www.activepieces.com/pricing, abgerufen im Juli 2026.
11. Activepieces GitHub Repository, https://github.com/activepieces/activepieces, abgerufen im Juli 2026.
12. Activepieces Docs, https://www.activepieces.com/docs, abgerufen im Juli 2026.
13. AWS Builders’ Library, „Making retries safe with idempotent APIs“, https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/, abgerufen im Juli 2026.
14. Stripe Docs, „Idempotent requests“, https://docs.stripe.com/api/idempotent_requests, abgerufen im Juli 2026.
15. Cloud Native Computing Foundation, „CloudEvents Specification“, https://github.com/cloudevents/spec, abgerufen im Juli 2026.
16. OpenTelemetry, „Specification“, https://opentelemetry.io/docs/specs/otel/, abgerufen im Juli 2026.
17. Google, „Site Reliability Engineering: Monitoring Distributed Systems“, https://sre.google/sre-book/monitoring-distributed-systems/, abgerufen im Juli 2026.
18. n8n Docs, „Execution data“, https://docs.n8n.io/hosting/scaling/execution-data/, abgerufen im Juli 2026.
19. Make Help Center, „Error handling“, https://help.make.com/error-handling, abgerufen im Juli 2026.
20. Zapier Help, „Zap limits“, https://help.zapier.com/hc/en-us/articles/8496181445261-Zap-limits, abgerufen im Juli 2026.

---

Disclosure und Haftungsausschluss

FW Delta implementiert n8n, APIs und individuelle Automatisierung. Der Herausgeber kann wirtschaftlich von Self-Hosting- und Architekturprojekten profitieren. Der Report trennt deshalb öffentliche Anbieterbeobachtungen von synthetischen Kostenannahmen.

Der Report ist keine verbindliche Preisauskunft. Für ein reales Projekt müssen tatsächlicher Vertrag, Workflow-Topologie, Daten, Fehlerraten, Reviewbedarf und Betriebsmodell erhoben werden.