If you run RevOps or own the automation stack at a Series A–C SaaS shop, you already know the pattern.
Event volume in Salesforce or HubSpot climbs. Enrichment, stage syncs, and outbound research fire more often. The automation invoice climbs with it.
This is usually not a “wrong plan” problem. It is a metering problem.
What the meter actually counts
The major orchestration tools do not bill the same unit. They bill the same shape.
Zapier bills tasks. A task is a successful action step in a third-party app. Triggers, filters, and paths do not count. Every completed write, update, or lookup still does. A five-action Zap run 10,000 times is 50,000 tasks — before you touch AI steps or branching complexity elsewhere in the stack.
Make bills credits (the unit formerly called operations). For standard modules, one module run is roughly one credit. Triggers, filters, and routers generally count. Iterators and paginated loops consume one credit per record. Native AI and code modules consume more than one credit per run. Complexity and volume both move the needle.
n8n (cloud) bills executions: one full workflow run equals one charge, regardless of node count. Self-hosted n8n removes the SaaS meter and replaces it with your own compute, storage, and ops cost. The unit changes. The need for a unit does not.
Different labels. Same cost function for high-volume CRM automation:
monthly automation cost ≈ event volume × billable units per run × price per unit
When opportunity updates, lifecycle transitions, and research callbacks scale, that product scales. You are not buying a larger feature set. You are buying more of the meter.
Why “just upgrade the plan” fails
Plan tiers buy you a larger bucket of the same unit.
That helps until:
- A single scenario adds steps (each step multiplies units per run on task/credit meters)
- An iterator fans out across a list (Make: per-record credits)
- You wire AI modules into the path (variable credit burn on Make; extra tasks or external API cost elsewhere)
- Marketing or sales ops turns up webhook / polling frequency
None of that requires a new product decision. It requires more of the existing meter. Finance sees a line item that tracks pipeline activity instead of capacity.
If you can read a Terraform plan, this should feel familiar: you already separate control plane cost from data plane volume in AWS. Per-task automation SaaS collapses them. Volume is the bill.
The capacity model
There is another way to pay for the same class of work — CRM workflows, forecasting jobs, churn / expansion agents, outbound research — without a vendor task or credit counter attached to each CRM event.
Run the agents as compute in your account:
- LangGraph + Claude Sonnet agents
- ECS Fargate tasks inside your private VPC
- Provisioned with one Terraform apply (~22–29 minutes on a typical first deploy)
- Data stays in your AWS account
The bill you watch is AWS capacity: CPU, memory, egress, model API usage you configure. It is not a Make credit or a Zapier task minted per Salesforce update.
That is the mechanism, not a slogan.
| Model | What scales the bill |
|---|---|
| Zapier tasks | Successful action steps × runs |
| Make credits | Module runs (and extras for iterators / AI / code) × volume |
| n8n Cloud | Workflow executions × volume |
| Your AWS capacity | Provisioned Fargate / related infra (+ model usage), not a per-CRM-event orchestration tax |
“The control of DIY. The speed of SaaS. The data never leaves your AWS account.”
The true alternative for teams that outgrow click-ops orchestration is not a cheaper task pack. It is owning the runtime: same class of agentic workflows, metered like infra.
Who this is for
You are a RevOps Director or an Engineering Lead who can read a Terraform plan.
You already run Make, Zapier, n8n, or a homegrown glue layer. You have hit the wall where the per-operation (or per-credit / per-task / per-execution) bill tracks event volume. You are actively looking at what to switch to — not whether the pain is real.
If that is you, the decision frame is narrow:
Is automation cost a function of how often the workflow fires, or of how much compute you reserved?
If it is the first, growth taxes you twice: once in CRM volume, again on the automation meter.