Zapier connects more apps than anything else, which is almost always why a business picks it. It also bills per successful action rather than per lead, and leaves a failing Zap switched on until nearly every run errors. We build Zaps that account for both.
Built against the tools you already pay for
Nobody sits down and designs a Zapier account. One person builds a Zap so they stop re-typing form submissions, somebody else builds three more, and two years later there are forty of them, half of them owned by people who have changed roles. It works, mostly, which is exactly why nobody opens it.
Then the bill stops matching the business. Zapier charges per successful action step, not per Zap run, so one enquiry that creates a CRM contact, adds a spreadsheet row, sends an email and posts to Slack is four tasks rather than one. Put a loop over the lines of an order in front of that and a single trigger can spend hundreds of tasks without anybody noticing.
None of this is an argument for leaving Zapier. The catalogue is the reason you chose it and it is still the largest in the category by a wide margin, which matters more than any feature comparison when the app you depend on is an obscure one. Zapier just repays being built deliberately: the free steps deciding before the paid steps write, errors landing in front of a person, and connections that do not belong to one employee’s login.
You are billed per successful action step and not per lead, so we read your Zap history and work out where the tasks are genuinely going. Triggers, Filters, Paths, Formatter and Delay cost nothing at all, which is why most bills come down by putting the free steps in front of the paid ones rather than by upgrading the plan.
Branching built inside Zapier’s real ceiling of one hundred steps per Zap, which counts everything nested inside every path towards the same total. When a path tree passes the point a human can read it, we lift the repeated parts into Sub-Zaps so each piece can be tested and changed on its own.
Zapier integrations are built by each app’s own developers on Zapier’s platform, so a vendor appearing in the catalogue does not mean the trigger, action or field you need was ever built. Where it is missing we go straight to that vendor’s API with Webhooks by Zapier or a custom action, and the rest of the Zap carries on unchanged around it.
Zapier’s default is to pause a Zap only once it has errored on 95% of its runs in the past week, so a Zap failing a third of the time keeps running and keeps dropping work. We add error handler paths that put the failure somewhere a person actually looks, and design around the fact that adding one switches that Zap’s autoreplay off.
Polling triggers ask the app on a schedule set by your plan, fifteen minutes on Free, two minutes on Professional and one minute on Team, so a Zap everyone calls real-time is often minutes behind. We move triggers onto webhooks wherever the vendor supports them, and tell you plainly which of your apps only offer polling.
App connections in Zapier belong to a user, and a Zap pauses the moment its owner loses access to one, so closing a leaver’s Google account can stop workflows nobody knew they owned. We reauthenticate through accounts the business itself controls, then hand over a foldered, named and documented account instead of a pile of Zaps called Copy of Copy of.
Because Zapier bills per successful action step, not per Zap run. One enquiry that creates a contact, adds a row, sends a welcome email and posts to a channel is four tasks, so a hundred enquiries is four hundred. The useful half of that rule is what is free: triggers never cost a task, and neither do Filters, Paths, Formatter, Delay or Looping. Most of the savings we find come from moving a filter above the actions it was sitting below, so you stop paying to write records you were about to discard.
Not on its own, and this is the assumption that costs people the most time. Zapier integrations are built by each app’s own developers, so a listing tells you the vendor built something, not that they built the trigger, action or custom field you actually need. We check the real trigger and action list before quoting anything. Where the gap is genuine we usually go direct to that vendor’s API with Webhooks by Zapier or a custom action, which is still cheaper than changing platforms but is a build rather than a click.
This is the weakest part of the platform and we will not pretend otherwise. Zapier’s default is to pause a Zap once it has errored on 95% of its runs in the past week, which means a Zap failing a third of the time keeps running and keeps losing records, and Zap history is only kept for a matter of weeks so the evidence expires too. Error handler paths help, but they carry a real trade-off: adding one switches off autoreplay for that Zap and stops the error emails, so you swap automatic retries for a branch you have to build properly. We route errors to somewhere a human reads and reconcile counts against the source system. If a workflow genuinely cannot tolerate silent loss, we will tell you Zapier is the wrong place for it rather than sell you a Zap.
There are three honest signals. The first is the shape of the cost: per-task billing rises in a straight line with volume, so the month you go from twenty orders a day to two hundred, the bill does the same, and no amount of tidying changes that. The second is the ceiling: a Zap stops at one hundred steps including everything inside its paths, each call out to another system has to finish inside about thirty seconds, and Code steps are a small sandbox rather than somewhere to process anything substantial. The third is data you would rather not route through somebody else’s cloud at all. If none of those apply to you, staying on Zapier is the right answer and we will say so.
They pause. App connections in Zapier are attached to a user, and when a Zap’s owner loses access to a connection the Zap stops until somebody reconnects it, so the account you disable on a leaver’s last day quietly takes its workflows with it. Shared connections exist, but only on the larger team plans. On any plan the practical fix is the same: authenticate through accounts the business owns rather than an individual’s login, and keep a written list of what is running before you need one.
Yes, using Looping by Zapier, and it is worth knowing the cost before you build it. The loop step itself is free, but every action inside the loop is charged once per iteration, so a loop over three hundred rows that writes two records each is six hundred tasks from a single trigger. Everything inside the loop also counts towards that Zap’s hundred-step limit. For short, predictable lists this is fine. For anything unbounded we would either batch the work outside Zapier or be straight with you that the volume makes another platform cheaper.
It depends on whether the trigger is instant or polling, and that is decided by the app’s developers rather than by you. Instant triggers are fed by a webhook and fire within seconds. Polling triggers ask the app on your plan’s schedule, which is fifteen minutes on Free, two minutes on Professional and one minute on Team and Enterprise. Polling also deduplicates on each record’s unique ID, so editing an existing record will not fire the Zap again unless the vendor also built a separate updated trigger. We check which kind you are getting before anyone promises a customer a response time.
Send us your Zapier task usage and the Zaps behind it. We will tell you where the tasks are going, which Zaps are failing quietly, and whether the answer is a rebuild, a tidy-up or leaving it alone.
Book a Free Demo