Building Business Automation with Make.com

The fastest way to waste an afternoon with an automation tool is to open it and start connecting things. The tool is rarely the problem; the process usually has not been written down yet.

Write the process first

Before touching Make or n8n I want the current process in plain language: trigger, steps, decisions, outputs, and what happens when any of it fails. If that cannot be written on one page, it is not ready to automate — automating an unclear process just produces unclear results faster.

Split rules from judgement

• Rules: if a lead has a work email and a company size above X, route it to sales. Automate this.
• Judgement: whether this particular message deserves a personal reply. Keep a human on it.

AI fits in the gap — narrowing a fuzzy input into a defined output that a rule can then act on. What it should not do is make the final call on something nobody can review afterwards.

Design the failure path first

trigger → validate → act → confirm
                 │        │
                 │        └── on error → retry → alert #ops
                 └── on invalid payload → park + notify

An automation without error handling is not automation — it is a new way to lose data quietly. Every scenario I build has an explicit failure branch and somewhere for a human to see it.

Make vs n8n

Make is faster to a working scenario and easier to hand to a non-technical team. n8n gives more control and self-hosting when the workflow is business-critical or the data should not leave your infrastructure. I choose on those grounds rather than preference.

Document the invisible part

Nobody thanks you for the automation that runs correctly for six months. Then one API changes its field name and it stops — and the only record of what it does is a graph of twelve modules nobody named properly.

Naming, comments and a one-page description of intent are part of the deliverable, not a courtesy.