For teams building on Make, or weighing it against the alternatives

Make.com Consulting in Australia: Read the Credit Meter First

Make is the most pleasant of the mainstream automation platforms to build in. The visual canvas makes branching, iteration and data mapping legible in a way that competing tools do not manage, and a capable non-developer can get genuinely far with it. Its commercial model is also the one most likely to surprise you, because cost scales with the number of things processed rather than the number of automations you own.

We work across Make, n8n, Zapier and Power Automate and have no reason to prefer one. This page covers how Make’s credits are actually consumed, how to design a scenario so it stays readable in two years, what error routing and the incomplete executions queue really do, where Make sits on data residency for an Australian business, and the honest signals that you have outgrown it.

Book a Make Scenario Review (03) 9003 0111

Realistic ROI

Per credit

Is how Make meters, roughly one per module run

Credits replaced operations as the billing unit in August 2025. Routers and filters are free. Anything that actually calls a service costs a credit each time it runs

Times the item count

Is what an iterator does to your bill

A module after an iterator runs once per item, so a hundred line items through four modules is four hundred credits, not four

No Australian region

Make hosts in European and United States zones only

As at August 2026 the published zones are eu1, eu2, us1 and us2, and yours is fixed at sign-up. If Australian data residency is contractual, this needs raising before you build, not during a security review

1 to 4 weeks

Typical build window for a first scenario set

Make is quick to build in. The time usually goes on getting API access from third party vendors rather than on the canvas

Four Things That Decide Whether Make Is the Right Home

Make projects rarely fail on capability. They fail on credit arithmetic, scenario sprawl and nobody owning the failures.

Credit arithmetic decides your architecture

The headline plan number is not the useful figure. What matters is how many credits a single run of your process consumes, multiplied by how often it runs. A scenario that fetches an order, iterates twenty line items, and calls three modules per line consumes far more than most people estimate from looking at the canvas. Make’s own AI modules break the arithmetic further, because they bill against token usage rather than a flat credit per call. This is not a reason to avoid Make, it is a reason to model the arithmetic during design, because the same business outcome can often be built for a fraction of the credits by batching, filtering earlier, and using search modules that return many records in one call instead of looping.

The visual canvas is a genuine advantage until it is not

Make’s strongest feature is that a well built scenario can be understood by looking at it. Routers show branching, iterators and aggregators show where data fans out and comes back, and the data mapping is visible rather than buried in expressions. That legibility is real value for a business that wants staff other than the builder to understand its own processes. The failure mode is the sprawling scenario with nine routes, nested aggregators and forty modules, which is no more readable than the code it replaced. Split by responsibility, keep each scenario doing one job, and let scenarios call each other.

Error routing is the difference between a tool and a system

Make lets you attach an error handler to any module and choose what happens. The current directives are Skip, Retry, Resume, Commit and Rollback: skip the failing bundle, retry and park the run for later, resume with substitute data, commit what has already been processed, or roll it back. Used well, this turns a fragile chain into something that degrades sensibly, retrying a timeout while parking a genuine data problem for a human. Used poorly, and reaching for Skip to make a red error go away is very easy, you get a scenario that reports success while silently dropping records. Which handler goes on which module is a design decision that deserves as much thought as the happy path.

Data residency is the question Australian buyers forget to ask

Make grew out of a European product, Integromat in Prague, and now sits inside Celonis, which acquired it in October 2020 and operates from Munich and New York. It hosts in European and United States zones only, and your account is tied to the zone chosen when it was created. For most Australian small businesses that is unremarkable and entirely workable. For an organisation with government clients, health data, or contracts that specify where information may be processed, it is a conversation to have before the build, not after a client questionnaire lands. The practical outcomes are usually either accepting it with a documented data flow, restricting which fields ever leave your systems, or choosing a platform that can run on Australian infrastructure.

What a Production-Grade Make Setup Actually Includes

Anyone can build a scenario that works on a good day. These are the parts that make it survive a bad one.

A cost you can predict

Credit modelling

Before building, we count the credits a single run consumes and multiply by realistic volume, including the seasonal peak rather than the average month. That number drives design choices: whether to use a search module that returns many records instead of a loop, whether to filter before an iterator rather than after, whether a nightly batch is cheaper than a per-record trigger, and which plan tier you actually need. It also becomes the baseline you monitor against, so a scenario that starts consuming double what it should is noticed early.

Small scenarios that do one thing

Scenario decomposition

Rather than one large scenario handling every branch, we split by responsibility and let scenarios trigger each other over webhooks. One receives and validates, one enriches, one writes to the system of record, one handles exceptions. Each is readable on a single screen, each can be tested and re-run independently, and a failure in one does not require re-running everything. It also means a change to one part of the process does not put the whole chain at risk on the day you deploy it.

Failures parked, not lost

Error handlers and the incomplete executions queue

Transient failures such as a timeout or a rate limit get a Retry handler so they recover on their own. Genuine data failures, a missing required field or a customer that does not exist, get routed to a handler that records the case and notifies a human rather than being skipped silently. Incomplete execution storage is off by default, so it has to be turned on deliberately. With it enabled, parked runs can be inspected and resumed after the underlying data is fixed, which is far better than reconstructing what was lost. Someone still has to look at that queue, which is why it belongs to a named person.

Safe to re-run

Idempotency and duplicate protection

Scenarios get re-run: a webhook fires twice, a parked execution is resumed, someone clicks run once while a scheduled cycle is already going. If your scenario creates invoices, sends payment reminders or posts to an accounting system, running it twice is a real problem for a real person. The protection is unglamorous: store an external reference on every record you create, search before you create rather than creating blindly, and use the target system’s own duplicate detection where it offers one.

Predictable behaviour under load

Scheduling and concurrency control

Scenario scheduling, sequential processing and the maximum number of cycles per run are not defaults to leave alone. A scenario polling every minute against a slow API will start overlapping runs, which produces duplicates and confusing logs. Sequential processing prevents that at the cost of throughput. Where a third party rate limits you, deliberate pacing and batch sizing keeps you inside their limit instead of collecting errors. These settings are part of the design, not a tuning exercise for later.

Recoverable and owned

Blueprints, ownership and the 2am question

Scenario blueprints export as JSON and belong in a repository your business controls, so a broken edit is a restore rather than a rebuild from memory. Connections should be created on accounts the business owns rather than an individual’s personal login, because a departure otherwise takes your automations with it. And the question everyone skips in the sales conversation: when a scenario fails at 2am on a Sunday, who is told and who fixes it. If there is no answer, the automation is an unattended process with a delayed fuse on it.

Where Make Fits Well, and Where It Starts to Strain

Task	Traditional	Built properly in Make	Notes
Form submission to CRM and notification	Manual entry and forwarded emails	Handled in a handful of credits	Make is excellent here and easy for your own team to adjust later.
Multi-branch routing on business rules	Nested conditions nobody can follow	Visual router with labelled paths	The clearest branching of any mainstream platform, provided you keep the scenario small.
Reshaping awkward data between systems	A spreadsheet and a person	Aggregators, iterators and mapping panel	Genuinely strong. Watch the credit multiplier once iteration is involved.
Bulk processing of thousands of records	Overnight batch script	Works, but credits add up fast	This is the usual trigger for moving to an execution-priced platform. Model it before you commit.
Calling an API with no ready module	Needs developer help	HTTP module with your own authentication	Fine for most Australian mid market systems. Awkward authentication schemes need care.
Long-running or multi-day processes	A calendar reminder and hope	Better split into scheduled scenarios	Make prefers short runs. Waiting inside a scenario for days is the wrong shape.
Data must be processed in Australia	Local system, manual process	Not currently achievable on Make	Zones are European and United States. If residency is contractual, this is a platform decision.
Heavy custom logic and unit-tested code	A real application	You have outgrown the canvas	When most modules are code and the scenario needs tests, build software instead. We will say so.

Where Australian Make Projects Come Unstuck

Credit consumption discovered in month three

The pattern is consistent: a scenario is built and tested against a handful of records, everything looks cheap, then real volume arrives and the plan is exhausted mid-month with the scenario stopped and nobody watching. Model consumption per run during design, multiply by peak volume rather than average, set an alert when consumption tracks ahead of plan, and know in advance what the upgrade costs. Most overspend is fixable by design, usually by filtering earlier or replacing a loop with a single search or batch call.

Reaching for Skip to silence an error

With no handler attached, Make’s own behaviour is that the run stops on the error, which is loud and recoverable. The silent version is a choice somebody made: attaching a Skip handler makes the red error go away, and it is then very hard to notice that records are being dropped. A scenario that reports success while quietly discarding one order in fifty is worse than one that fails loudly, because the business trusts it. Decide deliberately for each module whether an error is transient and worth retrying or a data problem that must reach a human, and never use Skip as a way to make a dashboard look clean. Turn on incomplete execution storage as well, because it is off by default and a failed run is not parked for you until it is enabled.

One enormous scenario that only its author understands

Make rewards starting small and then keeps letting you add. Two years later there is a scenario with dozens of modules, several routes, nested aggregators and mapping that references outputs from twenty steps earlier. Nobody will touch it, including the person who wrote it. Split scenarios by responsibility from the beginning, name every module for what it does rather than leaving the default, add notes on the canvas explaining why the odd decisions exist, and treat a scenario that no longer fits on a screen as a signal to refactor.

Connections owned by an individual

A connection created with a staff member’s personal Google, Xero or CRM login stops working when they leave, change their password under a policy reset, or lose their access during a role change. Use dedicated integration accounts or service accounts wherever the vendor supports them, record who owns each connection and when its token expires, and treat access to the Make organisation itself as privileged, because anyone inside it can see and use every connected system.

No blueprint export, so no way back

Make keeps some version history, but relying on a vendor’s interface as your only recovery path is a thin plan. Export scenario blueprints as JSON on a schedule into a repository your business owns. That gives you a diff when behaviour changes, a restore path after a bad edit, and, just as importantly, portability: a blueprint plus documentation is what lets you move platforms or change providers without starting again.

Nobody watching the incomplete executions queue

Parked executions are only useful if someone resolves them. The failure we see most often is a queue with two hundred items going back four months, each one a customer record that never reached the accounting system, discovered when the books do not reconcile. Give the queue a named owner, a daily habit, and an alert when it exceeds a threshold. An exception process without a person attached is not an exception process, it is a slower way of losing data.

How Yes AI Works With Make

We model the credits before we quote

You get the expected consumption per run and per month, at peak rather than average, along with the design choices that reduce it. If the arithmetic says another platform is materially cheaper for your volume, that is what the recommendation will say.

Built, documented and monitored

Scenarios split by responsibility, every module named, error handlers chosen deliberately, blueprints exported to a repository you own, and failure alerting that reaches a monitored inbox rather than the builder’s personal notifications.

Handover that survives staff turnover

A written runbook per process covering what it does, what triggers it, what it touches, how to tell it has failed, and how to complete the job manually if the platform is unavailable. That is what stops your automation becoming a black box owned by whoever built it.

Honest about the ceiling

If your volume, your residency obligations or your logic complexity mean you have outgrown Make, we will tell you and help you move. Equally, if you are being sold a custom build for something Make handles cleanly in an afternoon, we will tell you that too.

From Process to a Scenario You Can Rely On

Five steps. The credit model comes before the build, because it changes the design.

Map the process and confirm platform fit

We document how the process runs today, list every system and credential involved, estimate volume, and confirm whether Make, n8n, Zapier or Power Automate is the right home. Residency and governance constraints are raised here, not later.

Model the credits and choose the shape

Credits per run at realistic volume, with alternative designs compared: batch versus per record, search versus loop, filter placement. The cheapest correct design is chosen before anyone opens the canvas.

Build in small, named scenarios

Split by responsibility, every module named for what it does, notes on the canvas for the non-obvious decisions, connections on business-owned accounts, and blueprints exported to a repository from day one.

Design the failure paths and test them

Error handlers chosen per module, retries for transient failures, parking and alerting for data failures, duplicate protection on anything that creates records, then testing against real historical cases including the awkward ones.

Go live watched, then hand over properly

One process live and monitored daily for a fortnight, consumption tracked against the model, exception queue owner named, runbooks written, and a documented support arrangement covering after hours failures.

FAQ

How does Make pricing actually work, and why does my bill move around?

Make bills in credits. Credits have been the billing unit since August 2025, when existing operations were converted across at one for one, and the word operation now simply describes an individual module run. For ordinary modules the arithmetic is unchanged: one module run costs one credit. Routers, filters and the error handler modules themselves do not consume credits, but every module that calls a service does, and it does so once for every bundle of data it processes. That last part is where estimates go wrong. Put an iterator in front of three modules and feed it fifty line items, and those three modules have just consumed a hundred and fifty credits rather than three. There is one further exception, and it matters to anyone putting AI in the loop: Make’s own AI modules bill against token usage rather than a flat credit per call, so an AI-heavy scenario consumes far more than its module count suggests. Your bill therefore moves with business volume rather than with the number of automations you own, which is why a quiet January and a busy June can look like different products. Model the arithmetic before you build and design to reduce it, usually by filtering earlier and replacing loops with batch or search calls.

Where is our data processed if we use Make, and does that matter in Australia?

Make hosts in European and United States zones, and the zone is fixed when your organisation is created. Its published zones are eu1, eu2, us1 and us2, and there is no Australian region as at August 2026. For a typical Australian small business automating enquiries and admin, that is usually acceptable and easily documented. It matters when you hold health information, work under government contracts, or have client agreements that specify where data may be processed and stored. In those cases you have three honest options: accept it with a documented data flow and a privacy assessment, restrict the automation so sensitive fields never leave your own systems, or choose a platform that can run on Australian infrastructure. Raise it before the build, because it is a platform decision rather than a configuration setting.

When has a business outgrown Make?

There are four reliable signals. First, credit cost at your volume is now larger than the cost of running an execution-priced or self-hosted alternative, including someone to operate it. Second, your scenarios have grown so large that changing one is a risk nobody wants to take. Third, most of your modules are code modules, which means you are writing software in a canvas that cannot run tests. Fourth, a residency or governance requirement has arrived that Make cannot satisfy. Any one of those is worth a review. None of them means Make was the wrong choice originally, and moving one high volume process while leaving thirty low volume ones in place is usually the sensible answer rather than migrating everything.

What happens if a scenario fails halfway through?

That depends entirely on how you designed it, which is the point. With no error handling, the run stops and whatever had already happened stays done, so you can end up with a record created in one system and nothing in the next, which is the hardest state to clean up. With error handlers, you decide: retry the module for a transient failure, resume with a substitute value and continue, or use the Retry handler to park the execution so it can be inspected and resumed after the data is fixed, which needs incomplete execution storage switched on because it is off by default. Where two systems must stay consistent, design the sequence so the risky step happens last and can be safely repeated. Assume every scenario will fail mid-run at some point, because they all do eventually.

Can we build in Make ourselves and only bring you in when it breaks?

Yes, and for a lot of Australian small businesses that is the right arrangement. Make is genuinely learnable, and a capable operations person can build useful automations without a consultant. Where we usually add value in that model is at the start, agreeing an architecture and naming convention so things stay maintainable, and at the awkward edges: an API with unusual authentication, a credit bill that has run away, a scenario that fails intermittently for reasons nobody can reproduce, or a handover when the person who built everything is leaving. We are happy to review what you have and give you a list rather than take it over.

Who supports our scenarios when something fails outside business hours?

This is the question that decides whether automation is an asset or an incident waiting to happen, and it is almost never asked during a build. The technical part is straightforward: failure alerts routed to a monitored channel rather than one person’s notifications, a scheduled check that scenarios which must run have actually run, and an owner for the incomplete executions queue. The commercial part is a named person with a stated response expectation, whether that is your own team or a support arrangement with us. If the true answer today is that a customer would tell you before your systems did, fix that before you automate anything else.

Is Make better than Zapier, n8n or Power Automate?

They suit different businesses and we build on all four. Make is usually the best value for automations with real branching and data reshaping, where the visual canvas earns its keep and volume is moderate. Zapier is simpler and claims the broadest connector coverage of the four, over 9,000 apps on its own published numbers, so it wins for straightforward two-step automations, particularly for teams who want to self-serve. n8n wins on high volume iteration because it prices per workflow execution rather than per credit, and it is the only one of the four you can self-host on Australian infrastructure you control. Power Automate also keeps data in Australia for Australian-provisioned tenants, though on Microsoft’s infrastructure rather than yours. Power Automate wins inside a Microsoft tenant where governance and identity matter more than features. The right question is not which is best but which constraint binds you: cost at volume, connector coverage, residency, or governance.

Get the Credit Maths Before You Get the Build

Book a call. We map the process, model what it will actually consume, and tell you whether Make is the right home for it. If it is not, you will hear that first.