n8n automation quote: scope, costs and acceptance tests

Buying an automation means commissioning an operational workflow: an event comes in, gets validated, triggers an action and leaves a record. Counting nodes in the editor does not describe that work. A short workflow can depend on a difficult ERP integration; a longer one may use connections that are already available.

If you are evaluating an n8n consultant, request a proposal that your operations lead and IT team can review together. Use this checklist to start that conversation. Volumes, timelines and commercial terms need to be agreed for your actual requirements.

A useful scope might be: when operations approves a customer record in the CRM, validate the required fields, check whether the customer exists in the ERP and create a draft if needed. A person reviews the result before activating the record. This is an illustrative scope, not a client case or a promise to integrate with every ERP.

This first workflow excludes historical migration, cleaning the entire database and automating every department. Those tasks may be necessary, but they need their own scope. When a proposal says “integrate the CRM and ERP,” ask which objects it moves, in which direction and under which rules.

Before choosing n8n, check whether your systems already offer a connector that handles that exact workflow. Our guide to integrating with Argentine ERPs can help you explore available access options. Your installation’s version and permissions still need a separate check.

There is no single amount that can price every workflow. Effort depends on system access, data quality, exceptions, approvals and how the system will be operated. Comparable proposals explain what is included and who pays for each component.

The official n8n plans page defines an execution as one complete workflow run and publishes different conditions for each plan. Check the current plan when buying: nodes, records processed and executions measure different things.

Self-hosted means running n8n on infrastructure your company chooses. The official hosting documentation distinguishes Community from licensed editions. Hosting it yourself still requires ownership of operation, updates and recovery; it does not make the whole project cost-free.

Request a usage estimate based on your operation: trigger frequency, event volume and other services involved. A working demo does not establish savings or payback. To evaluate outcomes, first record the manual work and later compare the same process after automation.

“The ERP has an API” is not enough to close a quote. Verify that your edition can use it, that it exposes the required operation and that a test environment exists. Usage limits, permissions, identifiers and vendor rules also matter.

Without an API, a scheduled export may work for some batch processes. It does not guarantee writing back to the system or immediate synchronization. The proposal should identify the verified alternative and outstanding dependencies. Treating an unverified integration as settled hides work.

For an architectural reference, our ecommerce product onboarding build describes a source system without an API and a human review stage. It illustrates a specific alternative; it does not establish that every system supports the same approach.

An acceptance test is the agreed evidence that the workflow meets its scope. For the CRM–ERP example, this matrix turns “it is integrated” into behavior business and IT can verify. These outcomes are proposed requirements, not measured project results.

To avoid duplicates, the design should identify each event and check the destination before repeating a write. A late ERP response can hide an operation that actually completed. Ask the provider to explain how that situation is verified.

n8n supports error workflows, as described in its error handling documentation. This provides a mechanism for notifications; alerts, recipients and recovery still need to be designed and tested for your workflow.

Acceptance should include a test with the business owner, an issue record and approval to move into production. Agree on what happens if an ERP dependency prevents completion of the test.

Before signing, define who administers the instance, receives alerts and can change rules. Request that your team receive the agreed workflows, documentation and access, with the relevant accounts and licenses identified.

Support should distinguish a defect in the original scope from a later change: another ERP, object or business rule can require additional work. The proposal should also explain what happens when an external API changes.

If you buy maintenance, agree on coverage, how to report incidents and response time. A response time is different from a guaranteed resolution time. If your IT team will operate the system, include handover in the scope and verify that they can recover a failed execution.

Share the same brief with the providers you are evaluating. Use anonymized examples and access documentation. Credentials can be coordinated later through the channel agreed by your IT team.

If information is missing, mark it “pending” and ask the provider what they need to investigate before committing to a price and timeline. You do not need to solve the architecture to start a conversation, but you do need to identify the process you intend to buy.