Process automation is easy to oversell and easy to under-scope. Teams buy a workflow tool, wire three Zaps, then discover the form fields were wrong, the ERP rejects half the payloads, and nobody owns the failed runs. The useful question is narrower: which processes on your WordPress and WooCommerce stack burn enough time or error cost to justify a build, and which runtime should carry them.
This guide is the long-form companion to the business process automation service page. Use it to score candidates, compare n8n, Make, Zapier and custom code with cited differences, place AI steps safely, and run a pilot against the automation ROI calculator. Concrete recipes live in the use-case library, including orders to ERP, form leads to CRM and abandoned-cart reactivation.
What process automation is vs integration, RPA and AI agents
Four labels get mixed in sales calls. Keep them separate when you write the brief.
System integration keeps authoritative records consistent. Stock, price, SKU and order state should match between WooCommerce and an ERP or wholesaler. That work is documented on the WooCommerce ERP integration pillar. Failures look like drift, duplicates and silent stock lies.
Process automation reacts to events and performs side effects: create a CRM contact, enqueue a courier label, send a consent-aware cart email, open a ticket with the right tags, drop a PDF into a finance folder. The source of truth may already be correct; the humans around it are still copying fields.
RPA drives a graphical UI because no API exists or the vendor will not open one. It is brittle under layout changes. Prefer API or file contracts when you can get them. Keep RPA for the stubborn legacy screen, not as the default architecture.
AI agents plan, classify or draft. They are probabilistic. They belong behind schemas and approval when the next step emails a customer or moves money. They do not replace the idempotent order export.
If you are already exploring machine-callable operations inside WordPress itself, read WordPress AI workflows with the Abilities API. That is a different layer from a Make scenario that fires on a webhook.
Which processes pay back and which do not
A process pays back when it is frequent, time-consuming or expensive when it fails. Write those three numbers down before anyone opens a workflow canvas.
Score candidates with:
- Frequency - how many times per month the process runs when the business is busy, not on a quiet week.
- Time - minutes of loaded labour from trigger to done, including waiting on someone else and rework.
- Error cost - refunds, stockouts sold, duplicate CRM records, missed SLAs, compliance incidents. Use a conservative unit cost you would defend in a finance meeting.
Monthly labour saving is roughly runs × minutes / 60 × loaded hourly cost. Add avoided error cost if you have a measured rate. Subtract the monthly tool fee and the hours someone will spend watching failed runs. What remains has to cover the one-off build.
Processes that usually clear the bar on a WooCommerce site:
- Order create or status change that must reach ERP or WMS the same day (orders to ERP).
- Form submits that should become CRM records with UTMs and consent flags intact (form leads to CRM).
- Abandoned carts that need a timed, consent-aware follow-up instead of an ad-hoc reminder (abandoned-cart reactivation).
- Invoice or document generation after payment when finance currently re-types line items.
- Courier label and tracking updates when support currently copies tracking numbers by hand.
Processes that usually fail the score:
- Annual board reports that need narrative judgement.
- One-off migrations dressed up as “automation” so nobody budgets a project.
- Flows that start from a broken Gravity Forms or CF7 setup with missing required fields. Fix the form first.
- Anything where two departments disagree on the definition of “done” and expect the workflow to settle the politics.
A broken input is not an automation opportunity. It is a data quality ticket. Automating it multiplies the mess at machine speed.
n8n vs Make vs Zapier vs own code
The market pitch is interchangeable connectors. The operational differences are not. Use the table as a shortlist filter, then confirm the current vendor page before you commit, because plan names move.
| Topic | n8n | Make | Zapier | Own code |
|---|---|---|---|---|
| Licence and hosting | Self-host the Community edition without a licence key; paid keys unlock Business/Enterprise features (hosting docs) | Cloud product with documented data zones | Cloud product; confirm region options on the plan you buy | You choose the runtime |
| Billing unit | Cloud: workflow executions; self-host: your infra | Operations: each module run consumes credits | Tasks: successful actions; triggers, Filter and Paths do not count as tasks | Salary and cloud invoices |
| Data location | Self-host keeps payloads under your control; n8n Cloud regions per plan | Make documents eu1, eu2, us1, us2 style zones in help materials | Check Zapier trust / enterprise docs for the product you use | Your VPC or host |
| Error handling | Error workflows and Error Trigger nodes; per-node retry settings | Error handlers and incomplete-execution tooling in Make | Autoreplay on Professional, Team and Enterprise, not Free | Queues, DLQ, metrics you design |
| Versioning | Workflow history: 24 hours for all users, 5 days on Cloud Pro, full history on Enterprise | Scenario versions in Make | Zap version history on supported tiers | Git tags and reviews |
When Zapier fits. You want the widest catalogue of SaaS connectors, your volume fits task pricing, and operators are comfortable editing Zaps. Watch task burn on loops and on multi-step enrichment.
When Make fits. You think in scenarios with routers and aggregators, and you want operation-level cost control. Model the operation count honestly before you promise finance a monthly ceiling.
When n8n fits. You need self-hosting for data residency or cost, you want error workflows as first-class citizens, and your team can run Node-based infrastructure. Read the Sustainable Use License and hosting docs before you assume every commercial use is free.
When own code fits. The flow is product logic, the vendor connectors are incomplete, latency or throughput exceeds what a general workflow runner guarantees, or you already operate a service that must own schema versioning. Own code is not “more professional” by default; it is more yours to maintain.
Hybrid setups are normal: WordPress fires a signed webhook, n8n or Make does SaaS glue, and a small PHP or Node worker handles the ERP dialect that no connector gets right. The ERP pillar covers that boundary when the store and ledger must stay aligned.
Where an AI step belongs and where it does not
Models help when language is messy and the cost of a wrong guess is a delayed human review, not a wrong shipment.
Good homes for an AI step:
- Classify inbound support text into tags before a human queue.
- Draft a reply that an agent edits.
- Extract fields from a semi-structured PDF into a JSON schema for a finance person to confirm.
- Suggest a CRM owner or priority from sparse lead text.
Bad homes:
- Silent stock adjustments.
- Silent price changes.
- Consent flag invention.
- Irreversible customer emails with no approval.
- “Fix the data” prompts that overwrite ERP identifiers.
Anthropic publishes guidance on reducing hallucinations through clearer instructions and constrained tasks on its platform docs. OpenAI documents structured outputs so downstream systems receive schema-valid JSON. Both still assume you decide what happens when the model is wrong. Pair every AI node with a schema check and, for customer or money impact, a human gate. Broader product AI inside WordPress sits on the AI integration page; Abilities API patterns are in the related Abilities guide.
How to estimate payback with the calculator
The automation ROI calculator expects inputs you can defend:
- Runs per month
- Minutes per run
- Loaded hourly cost (you type it; we do not publish a rate card here)
- Error rate and cost per error
- One-off build cost
- Monthly running cost (tool fee plus maintenance hours valued at the same loaded rate)
Payback months equal build cost divided by (monthly saving minus monthly running cost), when that denominator is positive. If it is not, the calculator is telling you to stop.
Worked example, labelled as hypothetical so nobody treats it as a case study. Suppose 800 order exports a month, 4 minutes of re-keying each, loaded cost 40 currency units per hour, error rate 2 percent at 25 units per error, build cost 4 000 units, monthly tool and maintenance 200 units.
- Labour hours saved:
800 × 4 / 60 ≈ 53.3hours - Labour saving:
53.3 × 40 ≈ 2 132units - Error saving:
800 × 0.02 × 25 = 400units - Gross monthly saving:
2 532units - Net monthly:
2 532 − 200 = 2 332units - Payback:
4 000 / 2 332 ≈ 1.7months
Change any input and the story changes. If minutes are actually one, or volume is 80, the same architecture stops making sense. That is the point of typing your numbers instead of copying a slide.
Pilot plan with baseline measurement
A pilot is a single flow with a kill switch, not a platform rewrite.
- Name the process and the owner. Example: “paid WooCommerce orders to ERP within 15 minutes, owned by ops.”
- Capture baseline for two weeks. Spreadsheet columns: date, run count, minutes, errors, error cost notes. Watch people; do not guess.
- Write acceptance criteria. Idempotent create, duplicate detection, alert on three failures, pause without deploy.
- Implement the happy path first. Add retries and a dead-letter path before you add AI flourish.
- Run for the same two-week window. Compare minutes and errors to baseline. Feed the measured saving into the calculator with real build time.
- Decide explicitly. Promote, redesign, or shut off. “Leave it running and see” is how zombie Zaps are born.
Scheduling deserves a hard look. WordPress WP-Cron on page load is fine for soft tasks on busy sites and unreliable on quiet ones. Prefer Action Scheduler for WooCommerce work, a system cron hitting wp-cron.php, or the scheduler inside n8n, Make or Zapier for anything with commercial SLAs.
On-page checklist for auditing one process
Use this as a plain audit list while you watch one process end to end:
- Trigger: webhook, cron, status transition or manual button, and who can fire it twice.
- Systems of record for each field in the payload.
- Personal data categories and lawful basis or contract for processing.
- Happy-path steps from trigger to “done” in the destination system.
- Failure modes already seen in the last month (timeouts, 422 validation, auth expiry).
- Current minutes and hand-offs, timed with a clock, not recalled in a meeting.
- Error cost examples with invoices or tickets attached.
- Existing tools that already touch the same objects (avoid double writes).
- Named human who will own alerts after automation ships.
- Kill switch or pause procedure that does not require a deploy.
- Log retention and whether payloads include secrets or raw personal data today.
- Consent flags that must survive into CRM or ESP without being inferred.
- Success metric for the pilot (time, error rate, or both) written before build starts.
If more than two items are “unknown”, stop designing the workflow and finish discovery.
Security and GDPR basics for automation
Automation moves personal data between processors. Treat that as a design constraint.
- Credentials live in a secret store or the workflow tool’s credential vault, not in a shared spreadsheet. Rotate them when people leave. n8n documents encryption keyed for credentials in its security docs; use it and back up the key with the same care as production database passwords.
- Article 28 GDPR requires a contract when a processor processes personal data on your behalf (Art. 28). Your n8n Cloud, Make, Zapier, CRM and ESP relationships need that paperwork, not only your hosting invoice.
- Article 32 expects appropriate technical and organisational measures. For automation that means least-privilege API keys, TLS in transit, access control on the workflow editor, and logs that do not become a second CRM full of addresses and card fragments.
- Logs should carry correlation IDs and status, not full payloads, unless you have a retention rule and a reason. Redact tokens and password fields at write time.
- Data location belongs in the vendor shortlist. Self-hosted n8n keeps the graph on your infra. Make publishes data zone choices. Confirm Zapier’s options for your plan before you promise a customer that nothing leaves the EU.
National supervisory vocabulary differs: UODO in Poland, AVV language with German DSK/BfDI materials, Datatilsynet databehandleravtale in Norway, CNPD in Portugal, AEPD encargado del tratamiento in Spain. The contract substance is still Article 28; the label on the PDF changes by market.
Closing the loop
Start from a counted process, not from a tool subscription. Score frequency, time and error cost. Choose n8n, Make, Zapier or code for hosting, billing and failure behaviour you can operate. Keep AI on supervised steps. Pilot one flow from the library against a baseline and the calculator. When the store and the ledger are the real problem, switch to the ERP integration scope. When the product needs models inside WordPress, use the AI integration scope.
The service wrapper and engagement path sit on business process automation. Bring baseline numbers to contact if you want a scoped pilot rather than another unused scenario.







