When Zapier or Make automations became the system

A form feeds a sheet. A Zap copies the row into the CRM. Another creates the invoice in Xero, another emails the customer, another posts to Slack when it's paid. Each one took an afternoon. The chain grows that way until nobody can list it, all in one person's account, with the business logic in the filters and formatter steps.

It shows up as a system when something fails. A step errors for a week before anyone notices. A rate limit stops half the orders. A task or operation allowance runs out mid-month and the bill jumps. The connected Google account belongs to someone who's left. And nobody can answer the question "what happens when an order comes in?", because the answer is spread across every one of them.

• The definitions. Zapier exports every Zap as a JSON file from the account settings, and Make exports each scenario as a blueprint. Both describe triggers, steps and settings. Neither runs anywhere else, and neither imports into the other, so a move between platforms or into a system is a rebuild from the map.
• The history. Both platforms keep a run history, which tells us the real volumes, the real failure rate and which automations haven't fired in a year.
• The data. It isn't in Zapier or Make at all; it's in the sheets, the CRM, Xero and the mailboxes the automations connect. That's the point: nothing owns it.
• The connections. Every app account the automations log in as, and who those accounts belong to.

• A record. There's no single place where an order, a job or a customer exists with its status. There's a row in a sheet, a card in the CRM and an invoice in Xero, and they disagree.
• Rules in one place. The same decision is made in three Zaps slightly differently.
• Failure handling. A step that errors stops the chain, quietly. Replay is manual.
• A test environment. Every change is made on the live automations.
• Ownership. One person's login, one person's app connections.
• A log a human can read. The run history shows a step failed; it doesn't say which customer didn't get their invoice.

Keep them for the edges. Zapier and Make are good at connecting two apps that don't know about each other, and a system we build will still use them for that, or call the same APIs directly.

Build a system for the process. When there's a thing the business tracks through stages, with rules about who does what and when, it needs a record and one place the rules live. That's a small application with a database, and the automations become its inputs and outputs rather than its logic. The general keep, finish or replace reasoning applies, and the assessment makes the call from the inventory.

1. Inventory. The assessment lists every Zap or scenario: trigger, steps, filters, code steps, the accounts it uses, who owns them, the last time it ran and how often it fails. Exports and run history make this factual rather than remembered.
2. Map the process. From the inventory, what happens to an order, a job or an enquiry from start to finish, and which automations touch it. This is the specification.
3. Move ownership. Connections and accounts into ones the business owns, before anything else changes.
4. Build the system that owns the record and the rules, with a log, a test environment and staging.
5. Run it alongside. The system shadows the automations on live volume, and the results are reconciled. Then automations are switched off one at a time as the system takes each step.
6. Keep the edges. The Zaps or scenarios that still make sense stay, now triggered by the system or feeding it.

It lives in the connected apps, so the first job is reconciliation: the sheet against the CRM against Xero, to find which is right. The system is loaded from the agreed source, tested against a copy in a test environment, then run in staging alongside the live automations with results reconciled, before anything switches. The automations stay switchable back on until you're confident.

The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For an automation estate it produces the inventory and the process map, and prices the system as fixed numbers, alongside what the platforms cost a year at current volumes. What drives the price and the payment terms each have a page.

Inventory first, then a system for the process and automations for the edges. Marc Allington builds the systems these automation chains grow into, and integrates with the same apps directly. Everything we build runs on open technology in your own accounts, with full source code and ownership transferring to you on final payment.