Automation Unit Economics Benchmark 2026

Executive Summary

Automation platforms do not sell the same product in different colours. They measure usage in different units:

• successful actions or Tasks,
• executed modules or Credits,
• complete workflow Executions,
• active flows,
• own infrastructure and operational work.

As a result, the same business process can produce completely different invoice magnitudes at identical volume. The visible figure “ten workflows” says almost nothing about the actual cost curve.

This report combines a public vendor meter module with twelve disclosed workflow archetypes and three volume tiers. For each archetype, successful first runs, retry multiplier, human review time, error rework and external API costs are modeled separately. This produces 180 scenario rows for cost per successfully completed business event.

The marginal price rates used in the extended cost model are explicitly illustrative assumptions, not claimed vendor offers. The robust primary analysis lies in the translation of business events into technical billing units.

Citable key findings

1. [CALCULATED] In the baseline model, 10,000 identical lead events generate 90,000 Zapier Tasks, 100,000 Make Credits, 10,000 n8n Executions or one active Activepieces flow - before retry and failure paths.
2. [CALCULATED] Across the twelve extended archetypes, the assumed retry multiplier varies from 1.05 to 1.35; billable technical work therefore rises without additional business value.
3. [SCENARIO] For lead routing with 10,000 events, the modeled platform component ranges between 5 and 1,154 euros depending on the meter, while review and error rework account for 5,500 euros.
4. [SCENARIO] In the modeled invoice processing case, human review and rework dominate total cost so strongly that the choice of platform meter changes the cost per accepted outcome only marginally.
5. [INTERPRETATION] The higher the domain risk and uncertainty, the less the platform invoice alone explains the unit economics.
6. [OBSERVED] Zapier generally counts successful actions as Tasks; Make describes Credits per module action; n8n prices cloud plans by workflow Executions; Activepieces publishes an active-flow model.
7. [INTERPRETATION] Self-hosting eliminates no costs. It replaces vendor meters with compute, updates, security, monitoring, backup, incident response and ownership.
8. [RECOMMENDATION] The central metric should be cost per successfully completed business event, not Tasks, workflows or token consumption.

---

1. Research design

1.1 Research question

How do meter definition, workflow topology, retries, errors and human-in-the-loop change the cost of the same automated business process?

1.2 Four levels of analysis

Level	Question
Meter	Which technical unit does the platform bill?
Topology	How many billable steps does one event generate?
Reliability	How many attempts, failure paths and repetitions arise?
Outcome	How many results are accepted by the business in the end?

1.3 Formula

Cost per accepted outcome =
(
  platform base price
  + billable units × marginal rate
  + external APIs
  + human review
  + error rework
  + operations share
)
/
accepted business outcomes

1.4 Why this denominator is better

A workflow can be technically cheap and expensive in business terms:

• low platform costs,
• but a high error rate,
• manual rework,
• duplicates,
• wrong decisions,
• incident or compliance costs.

Conversely, a more expensive platform can be economically superior through better governance, debugging or less rework. This report does not evaluate those product qualities; it only shows why they belong in the calculation.

---

2. Twelve workflow archetypes

ID	Business process	key risk drivers
lead_routing	Lead → CRM, enrichment, owner, notification	duplicates, wrong routing
order_sync	Order → ERP, inventory, invoice, fulfilment	duplicate posting, race conditions
support_triage	Ticket → classification, context, routing, draft	misrouting, hallucination
invoice_processing	OCR → validate, match, approve, archive	amount and supplier errors
employee_onboarding	Identities, devices, payroll, training	permission and offboarding risk
marketing_attribution	Consent, identity resolution, destinations	consent and data quality errors
daily_reporting	Extract, transform, aggregate, alert	delayed or inconsistent data
compliance_screening	Screening, evidence, case, approval	false positives/negatives
document_generation	Template, render, sign, deliver	wrong data or version
catalog_sync	Normalize, map, distribute, verify	variant drift, API limits
incident_enrichment	Correlate, enrich, page, timeline	alert fatigue, wrong correlation
research_brief	Retrieval, synthesis, citations, review	source quality, review load

The complete assumptions are held in:

data/FDR-2026-04_workflow_archetypes.csv

2.1 Why the archetypes are scenarios

They are not anonymized customer cases. Every row deliberately contains visible assumptions about:

• actions/modules per attempt,
• retry multiplier,
• first-pass success,
• human review time,
• rework in case of errors,
• external API costs.

Any user of the data set can replace every value.

---

3. Three economic curves

3.1 Meter curve

business events
× attempts per event
× billable steps per attempt
= billing units

3.2 Reliability curve

events
× (1 - first-pass success)
× rework time
= error costs

3.3 Review curve

events
× review minutes
× labour cost rate
= human-in-the-loop costs

[INTERPRETATION] In simple, deterministic integrations the meter curve can dominate. In high-risk document, compliance or research processes, review and rework frequently dominate.

---

Part I - Vendor meters and baseline model

I.1 Research question

How does the definition of the billing unit change the cost curve of the same automated business process?

The report does not evaluate feature scope, stability, integration quality or usability. It isolates the economic effect of the meter.

---

I.2 The normalized business event

Process definition

An incoming qualified lead triggers the following sequence:

1. receive trigger
2. look up CRM record
3. create or update contact
4. create or update company
5. call enrichment service
6. store lead score
7. create deal
8. determine the responsible owner
9. send Slack/Teams message
10. log the activity in reporting

For the benchmark, steps 2 to 10 are modeled as nine successful external actions. In the simplified model, Make counts the incoming or reading module step plus nine further modules as ten Credits. Branches, loops, AI, errors and retries are excluded from the baseline model.

Why a business event?

“One workflow” is not an economic unit. The same workflow can run once a month or a hundred thousand times. A business event connects technical usage with operational meaning:

lead, order, ticket, invoice, application, incident
→ workflow run
→ technical steps
→ billable units

---

I.3 Vendor definitions

3.1 Zapier

[OBSERVED] Zapier describes a Zap as a trigger plus actions. According to the FAQ, a trigger consumes no Task. Every successfully executed action generally counts as its own Task. Certain built-in data tools - among them Filter, Formatter and Paths - are listed in the public FAQ as not Task-liable. The 2026 pricing page additionally points out that AI steps, code runtime and connector type can influence the Task rate.

Consequence:

Tasks ≠ Runs
Tasks ≈ successful billable actions × Runs × Rate

3.2 Make

[OBSERVED] Make counts module actions as Credits. Read, search, create, update, delete and certain transformations can each consume Credits. Routers and certain error handlers are exempt. Advanced AI functions can require more than one Credit.

Consequence:

Credits ≈ executed billable modules × Bundles × Runs

Bundles, iterators and search results can raise the number.

3.3 n8n

[OBSERVED] n8n publishes a pricing logic based on complete workflow Executions, independent of complexity and with unlimited steps. Cloud plans include fixed Execution allowances; a Community Edition can be self-hosted.

Consequence:

Executions ≈ started/counted workflow runs

The technical infrastructure still has to process the actual steps. “One meter” does not mean “no compute costs”.

3.4 Activepieces

[OBSERVED] Activepieces prices the standard plan by active flows. Ten active flows are publicly listed as free; above that, an active flow costs five US dollars per month. Runs are described as unlimited. The Community Edition is MIT-licensed and can be self-hosted.

Consequence in the standard plan:

billing ≈ number of active flows

The constraint shifts from volume to governance, number of flows and, where applicable, enterprise features.

---

I.4 Result of the billing unit model

Business events / month	Zapier Tasks	Make Credits	n8n Executions	Activepieces active 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

Machine-readable version:

data/FDR-2026-04_billing_unit_baseline.csv

Important limitation

The numbers are not an invoice forecast. They only translate the defined workflow topology into standard meters. In particular:

• Zapier can apply different Task rates for AI, code and certain connector usage.
• Make can generate additional Credits with Bundles, iterators, AI and multi-stage processing.
• n8n can count sub-workflows, retries and failed runs according to its respective Execution definition.
• Activepieces can incur additional costs for governance, hosting or enterprise requirements.
• external APIs cause their own fees.

---

I.5 Public price anchors at the data cut-off date

Platform	Public anchor	Meter
Zapier	Free: 100 Tasks; Professional from 19.99 USD/month; Team from 69 USD/month	Tasks / variable Task rates
Make	Free: 1,000 Credits; Core 9 USD at 10,000 Credits; Pro 16 USD; Teams 29 USD	Credits
n8n Cloud	Starter 20 EUR for 2,500 Executions; Pro 50 EUR for 10,000	workflow Executions
n8n Business	667 EUR for 40,000 Executions, self-hosted	workflow Executions plus own infrastructure
Activepieces Standard	ten active flows free, then 5 USD per active flow	active flows
Community Editions	n8n available; Activepieces MIT	infrastructure and operations instead of vendor meter

The table is a historical snapshot. Payment interval, region and dynamic selectors have to be captured again before publication.

Why no continuous price ranking?

With Zapier, the concrete price tier for 10,000, 100,000 or more Tasks is determined dynamically in the selector. A static figure without a documented UI selection would not be reproducible. The report therefore publishes no estimated high-volume prices.

This is a deliberate research decision:

A gap is more robust than an invented number.

---

I.6 Topology effects

6.1 Branches

With a router or path, not all paths always run. The costs depend on:

• number of paths
• share per path
• actions per path
• parallel paths
• error handling

6.2 Loops

A workflow with ten steps can execute hundreds or thousands of module actions on an array with 100 elements. The visible canvas complexity then underestimates the invoiced quantity.

6.3 Polling

A trigger can be free of charge and still load the infrastructure. Vendors treat polling differently. In addition, API limits arise at the source application.

6.4 Retries and errors

A failed step can:

• generate no billable action,
• have already had previous steps billed,
• run again automatically,
• trigger an error handler,
• require a manual repetition.

A cost model has to represent success, failure and retry paths.

6.5 AI steps

AI extends the cost function:

automation meter
+ model tokens
+ tool calls
+ retrieval
+ vector storage
+ evaluation and guardrail steps

An “AI agent” is therefore rarely just one additional workflow step.

---

I.7 Self-hosted TCO

Self-hosting is frequently described as “free” when the software licence is free of charge. Productive operation creates at least:

• compute
• storage
• database
• backups
• monitoring
• alerting
• TLS/DNS
• updates
• security
• incident response
• internal administration

The following profiles are [SCENARIO] and not an FW Delta price list:

Profile	Compute/storage	Backup/monitoring	Administration	Monthly TCO
Lean	€30	€20	2 h × €75	€200
Production	€120	€100	6 h × €75	€670
High availability	€400	€200	16 h × €75	€1800

Machine-readable version:

data/FDR-2026-04_selfhosted_ops_scenarios.csv

Interpretation

• The Lean profile can be plausible for non-critical internal workflows.
• The Production profile accounts for more operating time and observability.
• High availability requires redundancy, tests, on-call and more administration.

[INTERPRETATION] Self-hosting becomes economically interesting when volume grows strongly, when many steps per event exist, when governance matters or when the same platform bundles many workflows. With a few simple automations, SaaS can be clearly cheaper.

---

I.8 The better comparison: cost per successful business event

platform costs
+ external API costs
+ operations
+ error handling
+ administration
--------------------------------
successfully completed events

Exemplary metric:

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

This metric prevents two mistakes:

1. cheap platform costs with a high error rate,
2. low Task costs in unnecessarily bloated workflows.

---

I.9 Architecture decisions with economic effect

Reduce external actions

Consolidate data locally before writing to several APIs.

Use idempotent writes

Repetitions must not create duplicates or duplicated costs.

Separate orchestration and business logic

Move complex domain logic into testable code or services when canvas steps explode.

Batch instead of single action

Where the business case allows it, process several records in one API call.

Events instead of polling

Webhooks and queues reduce unnecessary checks and improve latency.

Observe the meter

Dashboard for:

• events
• billable units
• errors
• retries
• cost per workflow
• cost per business outcome

---

I.10 Decision matrix

Situation	Tendency
few, simple standard automations	SaaS plan often economical
many steps, high volume	evaluate Execution or self-hosted model
many small flows, low run count	active-flow model can become unfavourable
few flows, very high run count	active-flow model can be attractive
strong governance/SSO/audit	enterprise or own operations
frequent connector changes	managed platform reduces maintenance
proprietary domain logic	portable code/service layer
hard latency or data residency requirement	own operations or controlled runtime

---

---

4. Extended 12×3 benchmark

4.1 Billing units by volume

The file FDR-2026-04_billing_units_by_workflow_and_volume.csv contains, for every archetype:

• 1,000, 10,000 and 100,000 events,
• expected attempts,
• expected successful outcomes,
• Tasks,
• Credits,
• Executions,
• active flows,
• review hours,
• error rework hours,
• external API costs.

4.2 Example: lead routing, 10,000 events

Model	Platform costs*	Review/rework	External APIs	Total costs	EUR per accepted outcome
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] The platform costs use the disclosed illustrative rates from FDR-2026-04_cost_model_assumptions.csv. They are not vendor offers.

4.3 Example: invoice processing, 10,000 events

Model	Platform costs*	Review/rework	Total costs	EUR per accepted outcome
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] As soon as domain review requires several minutes per event, the platform meter is no longer the primary lever. Improving first-pass quality by a few percentage points can be economically more important than a cheaper workflow tariff.

4.4 Example: research brief, 10,000 events

In the scenario, the human review and rework component amounts to 235,000 euros. The differences between platform meters, by contrast, move in the low four-digit range or below.

That does not mean that 10,000 research briefs are realistic or sensible. The volume tier is a stress test that shows which variable scales.

---

5. Topology risks in detail

5.1 Fan-out

One event is distributed to many targets. The business figure stays at one, the technical work multiplies.

1 order
→ ERP
→ CRM
→ warehouse
→ finance
→ customer messaging
→ analytics

5.2 Iterators and Bundles

One visible step can internally run over hundreds of elements. The canvas complexity underestimates the meter and compute load.

5.3 Retries without idempotency

A retry is only safe if the same request can be processed several times without an unwanted double effect. Critical writes need:

• idempotency keys,
• dedicated event IDs,
• upsert semantics,
• deduplication store,
• deterministic retry policy,
• dead-letter queue.

5.4 Partial failures

A workflow can fail at the seventh step after six successful writes. The platform invoice and the business state are then both partial. A design has to define compensation or resumption.

5.5 Human exception handling

The exception rate is often not constant. It rises with:

• a new process,
• new data sources,
• seasonal peaks,
• API changes,
• incomplete master data,
• new AI models,
• regulatory changes.

A robust model therefore uses not just a mean value but P50/P90 exception rates.

---

6. Architecture rules with economic effect

6.1 Move business logic out of the canvas

When domain logic consists of dozens of visual steps, every execution becomes expensive and hard to test. Complex rules can make more sense in versioned, unit-testable services.

6.2 Define event contracts

Every event needs:

• a stable ID,
• a schema version,
• a creation time,
• a source,
• a business meaning,
• repetition semantics,
• a PII classification.

6.3 Batch where the business case allows it

Bulk APIs reduce round trips and meter usage. However, they increase batch radius and error complexity. Batch size and resumption therefore have to be tested.

6.4 Observability per outcome

Not just “workflow succeeded”, but:

• which business outcome was created,
• which records were changed,
• which external response was used,
• which retry/manual review followed,
• how high time and costs were.

6.5 Cost budgets as a guardrail

For volume-sensitive or AI-sensitive processes:

max_units_per_event
max_retries
max_external_api_cost
max_review_minutes
max_total_cost_per_outcome

On breach, the process has to stop, degrade or switch to human handling.

---

7. Decision model

Situation	model that tends to fit
few simple workflows, low criticality	SaaS meter often economical
many steps, high volume	evaluate Execution/flow model or self-hosting
many teams, governance requirements	assess enterprise features and operations jointly
high-risk AI/document processes	optimize human review and error costs first
strongly fluctuating volume	compare variable costs against capacity reserve
critical 24/7 process	include HA, on-call, DR and vendor support in TCO

---

8. Failure economics: the price of a technically successful but functionally wrong run

An automation can appear successful in the platform and still fail economically. The HTTP request answers with 200, the queue acknowledges the message and the workflow reaches its last node. In business terms, however, the wrong customer may have been updated, an invoice posted twice, a lead assigned to the wrong territory or a document created with an outdated template. This report therefore separates three definitions of success:

Level	Definition	typical measurement signal
technical execution	The workflow ran to the end without an uncaught technical error.	Execution status, exit code, queue ack
business acceptance	The result satisfies business rules and is accepted by the downstream process.	validation, approval, reconciliation
economic outcome	The result creates the intended value without disproportionate downstream or risk costs.	closing, posted payment, correct fulfilment

The difference is central to the unit economics. A vendor can report a 99.9 percent technical success rate while the organization corrects twelve percent of the results manually. This correction work does not appear on the platform invoice. It sits in finance, operations, support or engineering and is therefore easily excluded from the tool decision.

8.1 Expected failure costs

For a process with several failure classes, the expected failure load can be modeled like this:

Expected failure cost per event =
Σ (probability of failure class i × cost of failure class i)

Simple example for an invoice automation:

Failure class	assumed probability	assumed downstream cost	expected value per event
OCR field wrong, correctable internally	2.0 %	8 EUR	0.16 EUR
duplicate posting, detected before payment	0.3 %	45 EUR	0.14 EUR
wrong payment triggered	0.05 %	800 EUR	0.40 EUR
compliance/audit deviation	0.02 %	2,500 EUR	0.50 EUR
Total	-	-	1.20 EUR

The values are a scenario, not observed industry rates. They do show a frequent effect, however: rare, expensive errors can clearly exceed the visible platform costs. An automation that technically costs 0.05 euros per event is not automatically economical if its expected failure value amounts to 1.20 euros.

8.2 Retry is not recovery

Retries make sense for transient errors: timeouts, rate limits or temporarily unreachable endpoints. They are dangerous when the process is not idempotent or when the business state remains unknown. A retry can then trigger the same order again.

Every productive automation should at least distinguish:

1. transient technical error - repetition with backoff;
2. permanent technical error - dead-letter queue and handling;
3. business validation deviation - no retry, but clarification;
4. unclear commit status - reconciliation before writing again;
5. downstream success with local timeout - idempotency key or state query;
6. decision rejected by a human - a learning or rules process, not blind repetition.

The cost formula therefore has to account not only for the number of attempts but also for the distribution of retry causes. A flat multiplier of 1.10 is usable for a transparent scenario; a production process needs telemetry by failure class.

8.3 Error budget instead of a zero-error promise

A robust process defines in advance which errors are tolerable and which trigger an automatic stop. A possible error budget contains:

• maximum technical error rate per hour and per day;
• maximum business rejection rate;
• maximum number of unresolved events;
• maximum monetary exposure value;
• maximum queue ageing;
• maximum share of manually corrected outcomes;
• mandatory escalation for certain data or risk classes.

That makes cost and reliability manageable together. Without an error budget, the automation is usually only reviewed once support tickets or posting discrepancies become visible.

---

9. Capacity model: when generation scales faster than review

Automation frequently increases the arrival rate of cases without increasing the capacity of the review or exception process to the same degree. This is particularly relevant for AI-supported classification, document processing and research. The queue does not grow because the main workflow is slow, but because exceptions arise faster than humans can process them.

9.1 Minimal queue model

exception arrival rate λ =
events per hour × exception rate

review capacity μ =
reviewers × 60 / average review minutes

If λ ≥ μ, the queue grows structurally. A short-term peak load can be absorbed by buffers; a permanent ratio above one inevitably creates a backlog.

Example:

20,000 events/day
× 3 % exceptions
= 600 reviews/day

4 reviewers
× 7 productive hours
× 60 minutes
/ 4 minutes per review
= 420 reviews/day

In this scenario the process generates 180 more cases per day than it can clear. The technical automation can still be “green”. Economically, an ageing queue arises, then delayed handling and finally a second informal automation: people export data to Excel, prioritize manually or bypass controls.

9.2 Four levers against the exception queue

Lever	Effect	Risk
raise first-pass success	lowers the arrival rate	can create additional development or model costs
reduce review time	increases service capacity	risk of superficial review
route by risk	concentrates humans on critical cases	requires good classification and calibration
cap process volume	protects operations	reduces short-term throughput

The most sensible measure is not automatically more staff. Often a Pareto analysis of the exception causes pays off first: ten recurring data errors can cause a large part of the queue.

9.3 Mandatory metrics for review capacity

• exception rate by cause;
• queue age p50/p90/p99;
• review minutes per case;
• reopening or rework rate;
• share of automatically approved cases;
• share of manually overridden decisions;
• cost per accepted exception;
• errors after approval;
• reviewer utilization and concentration on individual people.

High reviewer utilization is not automatically good. At 95 to 100 percent sustained utilization there is no buffer for peaks, complex cases and incidents. The system becomes fragile.

---

10. Measurement protocol for a real 30-day benchmark

This report provides a scenario model. Before a migration or a platform change, an organization should run its own controlled measurement period.

Phase 1 - Define the process boundary

Document:

• start and end event;
• the outcome accepted by the business;
• all external systems;
• human decisions;
• data classes and legal bases;
• financial or operational failure classes;
• existing SLOs and escalation paths.

Phase 2 - Build an event ledger

Every business event receives a stable event_id. This ID accompanies trigger, workflow, external APIs, retries, review, target system and reconciliation. Without end-to-end correlation, a company cannot reliably connect technical executions to business outcomes and costs.

Minimum fields:

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 without architecture change

Record at least two normal operating weeks. Do not delete outliers, mark them. A benchmark taken only on quiet days underestimates rate limits, month-end closings, marketing peaks and seasonal effects.

Phase 4 - Parallel or shadow run

An alternative platform or architecture processes the same or representative events without productive side effects. For writing processes, mock endpoints, dry runs or isolated staging systems are necessary.

Phase 5 - Outcome reconciliation

What is compared are not only logs but business results:

• identical records;
• identical amounts;
• identical routing decisions;
• complete attachments;
• correct permissions;
• equal or defined latency;
• traceable deviations.

Phase 6 - Normalized cost accounting

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

Working time has to be valued with a disclosed fully loaded rate. Pure salary costs underestimate employer contributions, tooling, management and opportunity costs; a flat consultant day rate can overestimate them. What matters is less the “right” single rate than transparency and sensitivity.

Phase 7 - Decision with a confidence interval

Do not publish only a point value. With fluctuating volumes and error rates, at least low/base/high scenarios should be reported. With enough events, bootstrap intervals can be calculated for cost per outcome and success rate.

---

11. Procurement and architecture checklist

Meter and contract

1. What is the smallest billable unit?
2. Do triggers, filters, routers, iterators and internal transformations count?
3. Are failed steps, retries or replay billed?
4. Are there hard limits, soft limits or automatic overage?
5. How do team, environment and governance features change the tariff?
6. Can historical execution data be exported completely?
7. Which price change and renewal rules apply?

Reliability

8. Does the platform support idempotency keys or do they have to be built in-house?
9. Are there dead-letter queues, replay with versioning and deterministic reconciliation?
10. How are partial failures made visible?
11. Can workflows be versioned, tested and deployed reproducibly?
12. Are secrets, roles and production access separated?
13. How long is Execution data retained?

Economics

14. What does a successful business event cost at p50, p90 and peak volume?
15. How high are human review and rework costs?
16. Which external APIs have their own minimum commitments or overage?
17. What does an incident cost including recovery and customer impact?
18. Which costs arise on export or platform change?
19. Which share of the invoice is productive consumption and which is governance?
20. Which assumption changes the result the most?

Ownership

21. Can definitions, credentials, variables and history be exported?
22. Is the logic readable and testable outside the product?
23. Can another team take over operations based on the documentation?
24. Are runbooks, dashboards and alert rules part of the handover?
25. Is there a tested restore and Exit path?

A vendor does not have to be maximally open or portable in every line. The checklist does, however, force the cost decision not to be reduced to a monthly amount.

---

12. Worked example: why a cheaper Execution can end up more expensive

Two architectures process 50,000 support cases per month.

Architecture A

• platform and APIs: 1,200 EUR;
• first-pass success: 88 percent;
• 6,000 cases need 4 minutes of review each;
• fully loaded rate: 45 EUR/hour;
• rework on two percent of cases: 12 EUR on average.

Review = 6,000 × 4/60 × 45 = 18,000 EUR
Rework = 1,000 × 12 = 12,000 EUR
Total = 31,200 EUR
Cost per event = 0.624 EUR

Architecture B

• platform and APIs: 3,500 EUR;
• first-pass success: 96 percent;
• 2,000 cases need 3 minutes of review each;
• same fully loaded rate;
• rework on 0.6 percent: 12 EUR on average.

Review = 2,000 × 3/60 × 45 = 4,500 EUR
Rework = 300 × 12 = 3,600 EUR
Total = 11,600 EUR
Cost per event = 0.232 EUR

The scenario does not prove that a particular platform delivers higher quality. It shows why a tool decision without outcome and error data is economically incomplete. The platform price of B is almost three times as high; in the scenario the total costs are nevertheless around 63 percent lower.

---

13. Visualization specification

Chart 1 - Meter expansion

• Data: FDR-2026-04_billing_unit_baseline.csv
• X: business events
• Y: technical units
• logarithmic scale optional, label it clearly

Chart 2 - Workflow archetypes as a heatmap

• Data: FDR-2026-04_workflow_archetypes.csv
• Dimensions: steps, retry, success, review, rework
• no “best/worst” ranking

Chart 3 - Cost components per outcome

• Data: FDR-2026-04_cost_per_completed_event_scenarios.csv
• stacked bars: platform, review/rework, external API
• filter by workflow and volume

Chart 4 - Platform share of total costs

• calculated from the same file
• shows when tool price or human work dominates

Chart 5 - Retry multiplier

• Data: FDR-2026-04_workflow_archetypes.csv
• X: workflow
• Y: expected attempts per event

---

14. Reproducibility

Data files

• 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

Mandatory rules

1. Verify vendor meters live before publication.
2. Do not present scenario rates as vendor prices.
3. Count triggers, actions, Bundles, retries and failure paths separately.
4. Do not confuse first-pass success with technical Execution success.
5. Keep human review time visible.
6. Report external API and AI costs separately.
7. Calculate self-hosting with labour and standby included.
8. Define the outcome denominator in business terms.

---

15. Limitations

1. The twelve archetypes are synthetic.
2. First-pass success and review times are assumptions.
3. Illustrative meter rates do not represent actual contracts.
4. Vendor prices may not scale linearly.
5. Plan limits, overage, enterprise discounts and minimum commitments are absent from the scenario model.
6. External API and AI costs vary strongly.
7. Quality and risk costs are only partially modeled.
8. Self-hosted costs depend on criticality, team and architecture.
9. Feature scope and user experience were not evaluated.
10. A low cost per outcome proves neither compliance nor quality.

---

16. Citation notes

Permissible:

“The FW Delta model shows that the same process is measured as Tasks, Credits, Executions or active flows depending on the platform. The technical units are therefore not directly comparable.”

Not permissible:

“Activepieces is always cheaper than Zapier.”

Permissible:

“In the disclosed document and research scenarios, review and error costs dominated the platform costs.”

Not permissible:

“With automation, human review generally costs more than the software.”

---

17. Version history

• 1.0 · July 2026 · Public four-meter module consolidated with twelve workflow archetypes, three volume tiers and 180 scenario rows.
• Live version open · Re-check vendor prices, meter rules and help center documents before publication.

---

18. Sources

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

---

Disclosure and disclaimer

FW Delta implements n8n, APIs and custom automation. The publisher can profit economically from self-hosting and architecture projects. The report therefore separates public vendor observations from synthetic cost assumptions.

The report is not a binding price quotation. For a real project, the actual contract, workflow topology, data, error rates, review needs and operating model have to be established.