Zapier vs Make: the question usually comes up the day someone copies a form entry into a CRM and then into a spreadsheet for the tenth time that week. Both tools promise the same thing, no-code automation without a developer. Comparisons line up the number of connected apps and the plans. That is not where I see the real differences.
For a client, I set up no-code multichannel prospecting with Airtable, Zapier and email sequences. For my own content machines, I did the opposite: scripts and a configuration file. I have not run Make in production, and I will say so plainly: what I write about it comes from its documentation. Here is what I compare before choosing, and the cases where I would pick neither.
01What a no-code automation tool really does
The principle is the same on both sides. An event in one app (a form sent, a row added, an email received) triggers a chain of actions in other apps. Zapier calls that chain a Zap: according to its key concepts, a Zap is made of a trigger and one or more actions. Make talks about scenarios and modules.
The first practical difference is when the tool finds out that something has happened. Either the source app tells it straight away, through a webhook, or the tool checks at regular intervals. Make's documentation on webhooks explains it well: a webhook acts as an instant trigger, and when the app does not provide one, the trigger polls the app at intervals. At Zapier, the pricing page states a check every 15 minutes on the free plan, 2 minutes on Professional and 1 minute on Team.
Fifteen minutes is fine for filing invoices. It is a long time when you want to call back a prospect who has just asked for a demo. So this is the first question I ask: how long can this workflow wait?
02Tasks, operations, credits: what each one counts
This is the part people discover on their first invoice, so I always read it before building anything.
At Zapier, the successful action
The documentation on task usage is clear: only a successful action counts as a task. The trigger never counts, nor do filters and paths, nor formatting, delay or looping steps. When your plan reaches its limit, Zapier holds new runs until the billing cycle resets. On the free plan, the pricing page lists 100 tasks a month and two-step Zaps, without filters or paths.
At Make, the module and the bundle
Make counts differently. Its page on operations defines an operation as a single module run, and a module uses as many operations as the bundles it processes. The trigger is the exception: it counts once per check, however many bundles it returns. Operations consume credits, which Make's pricing page describes as its billing unit, with 1,000 credits a month on the free plan.
In practice, if a trigger returns ten new rows and three modules process them, you use one operation for the trigger and thirty for the rest. The same workflow at Zapier would count three tasks per row. Neither model is cheaper by design: it all depends on the volume and shape of the workflow. Before picking a plan, run the numbers on a real month, using last month's volumes.
03When a step fails
An automated workflow always runs into an error eventually: a disconnected account, a renamed field, an app that does not respond. What matters is what the tool does at that moment, and who notices.
At Zapier, the troubleshooting page says a Zap switches itself off if 95% of its runs in the last seven days end in errors. Automatic replay of errored runs exists, but not on the free plan, where you replay by hand.
Make goes further in what you can set. You attach error handlers to a module: skip the faulty bundle and carry on, retry later, substitute a value, commit what has been done, or roll everything back. Be careful with the last one: the documentation for the Rollback handler states that Make cannot undo what was done by modules that do not support transactions. An email that has gone has gone. The scenario settings also let you keep a failed run so its data is not lost.
Zapier's official video on multi-step Zaps shows a fairly complete lead workflow: a form, data formatting, two paths based on the budget entered, a loop over the services chosen, then personalised emails. The presenter tests each step before publishing. That is the right habit, but a test only covers the cases you thought of, and the production error still turns up.
In my content machines, a check that did not run counts as a failure, never as a pass. For a no-code workflow I apply the same logic: a named owner, and an error that sends an alert to someone who will read it. A workflow that breaks silently for three weeks does more damage than one that never existed, because everyone believes the work is being done.
04Zapier or Make, depending on the shape of your workflow
I do not choose the tool first. I sketch the workflow on a page, then look at its shape.
- A short, linear, low-volume workflow (a form into a CRM, then a notification): Zapier, because it is quick to pick up.
- A workflow with branches, loops over lists or fine-grained error handling: Make looks better suited on paper, because it shows the whole scenario and lets you set up each module.
- A workflow that handles many rows on each run: I would work out both counts before deciding, because that is where the gaps widen.
- A workflow that carries rules which must block: neither.
That fourth case is mine. My content machines have a brief that refuses to start the writing while a source is missing, and a final red, amber or green check before anything is published. I chose scripts and a versioned configuration: a rule written in the configuration really blocks, I can test it, and every change leaves a trace. In a visual tool, a condition can be changed with one click without anyone noticing. I explain this in the piece on my content machine with human review.
No-code is very good at moving data; it is less good at carrying a decision. For that client's prospecting, on the other hand, Zapier is what I used, with Airtable as the base.
One honest limit: a no-code tool is not free in terms of time. Someone has to know what each Zap or scenario does, update it when an app changes, and work out why a workflow has stopped. Without that person, automations pile up and nobody knows what each one is for.
05The personal data passing through
A prospecting workflow sends names, email addresses and sometimes phone numbers through one more tool. Under the GDPR, that tool is a processor. The CNIL, the French data protection authority, reminds us on its page on working with a processor (in French) that this processing must be covered by a contract with the controller, which means you.
If the tool, or one of its own processors, is based in the United States, another question arises. According to the CNIL's questions and answers on the US adequacy decision (in French), since the decision of 10 July 2023 a transfer to a US organisation certified under the Data Privacy Framework needs no extra transfer tool, provided you check that it is on the official list. Otherwise you need safeguards such as standard contractual clauses.
In practice, I would do three things before plugging in a workflow: read the tool's data processing agreement, record the workflow in the register of processing activities, and only pass the fields that are needed. A Zap that copies the whole contact record when it only needs the email address is carrying data for nothing.
06Where to start on Monday
Take the task that someone copies by hand most often. Write it as one sentence: when this happens in one tool, do that in another. Then answer four questions before opening Zapier or Make:
- how long can this workflow wait between the event and the action?
- how many runs a month, and how many rows on each run?
- what should happen if a step fails, and who will be told?
- what personal data goes through the tool, and which of it is really needed?
With those answers, the choice often makes itself. If your workflow then feeds a content base, the piece on Airtable for content shows how I structure one; if the bottleneck is getting things online, see why I automate publishing before producing more. And to connect a website form to a CRM, I have written up a HubSpot website integration.
If you would like to look at a specific workflow together, my automation and project direction work starts there, and the portfolio shows what I have already built. We can talk it through.