What was actually measured

In February 2026, a small experiment on automated lead processing with n8n appeared on arXiv. The authors compared a manual process with a linear workflow: create a customer inquiry record, store it in Airtable, send an email confirmation, and notify a responsible employee.

The headline result is striking. Average manual execution took 185.35 seconds, while automated execution took 1.23 seconds, a difference of roughly 151 times. One error was recorded across 20 manual runs, or 5%. No errors were observed across 25 automated runs.

This was not a deployment at a named company and not a production trial. The authors built a representative small workflow in a controlled environment. Lead data was generated programmatically, execution was triggered manually, and automated duration came from n8n logs. Actual delivery latency for email and messaging was not benchmarked separately.

The “151×” figure must therefore not be inserted into a business case as expected production performance. The experiment is still valuable because it exposes a boundary often blurred in AI projects: a language model is unnecessary for repeatable actions governed by known rules.

A process without AI — and why that is correct

The measured workflow contains deterministic steps:

  • receive structured lead fields;
  • assign an identifier and timestamp;
  • write data to a table or CRM;
  • send a templated confirmation;
  • notify the responsible employee;
  • store the technical execution result.

Each step has a known input, action, and expected output. Conventional automation is faster, cheaper, and more predictable than an LLM here. A model should not “reason” about how to store an email address or invent who should receive a notification.

Putting a model in every node adds cost and new failure modes: unpredictable output formats, inference latency, token expense, model availability, and extra validation. If a task can be expressed as a condition, data transformation, or API call, those should come first.

AI becomes useful where rules are hard to enumerate in advance. Examples include:

  • identifying the topic of a free-form inquiry;
  • extracting intent from a long email;
  • drafting a personalised response;
  • finding the relevant policy through RAG;
  • flagging urgency indicators for human review.

Even then, the model does not need control of the whole process. It can return a structured result — category, confidence, and a short rationale — before the workflow applies ordinary rules.

A practical architecture for a small business

An intake process for a website, email inbox, or messenger can be divided into five layers.

1. Intake. A form or API accepts the inquiry, validates required fields, limits text size, and creates a unique operation key.
2. Deterministic processing. The workflow normalises phone and email data, creates a CRM record, tags the source, and sends confirmation.
3. Intelligent step. Only unstructured text is sent to a model for classification or field extraction. Sensitive data is removed first or processed in a local environment.
4. Control. Low confidence, conflicting data, and material commitments are routed to an employee. The model cannot independently grant a discount or alter contract terms.
5. Observability. The system stores each step’s status, duration, error type, and final business outcome.

Local AI is appropriate when inquiries contain contractual, medical, HR, or otherwise sensitive information. The model and RAG layer can then run in a protected environment, and the workflow sends only the minimum necessary passage. Local deployment does not replace access controls, audit logs, or retention rules.

Data and integrations required

The minimum pilot does not require copying the entire CRM into a vector database. It needs:

  • 50–100 anonymised examples of real inquiries;
  • a list of required fields and allowed values;
  • routing rules between teams;
  • business-approved confirmation templates;
  • test credentials for CRM, email, and notifications;
  • a table of expected outcomes for evaluation.

If a model classifies text, the dataset also needs labels: the correct category, acceptable alternatives, and cases requiring refusal or human review. RAG needs an actively managed collection rather than a raw archive, with an owner, version, validity date, and access metadata for every document.

Integration accounts should have minimum permissions. A lead-creation workflow must not be able to delete customers, export the full database, or change commercial terms. Secrets should be stored outside workflow definitions and rotated regularly.

What the numbers show — and what they do not

The experiment is useful because it is transparent, but its limitations are material.

  • It compares 20 manual runs with 25 automated runs, too few to estimate rare failures.
  • Manual time was measured with a stopwatch and automated time with n8n logs, so measurement boundaries differ.
  • Email and messaging delivery latency was excluded from automated duration.
  • The test used n8n Cloud and one Airtable setup; self-hosting, another database, and concurrent load will behave differently.
  • Security, maintenance, total cost of ownership, and recovery were not evaluated.
  • Zero failures across 25 runs does not mean zero production risk.

ArXiv is also a preprint repository: appearing there does not itself imply independent peer review. This article therefore treats the paper as a reproducible small experiment, not conclusive evidence for a platform.

Russian market context

CNews reported that a ready-to-deploy n8n image became available through a Russian cloud catalogue for inquiry processing, data synchronisation, notifications, RAG, and LLM workflows. This indicates that the stack is accessible to Russian small and midsize businesses, but it does not establish an economic result because the report is based on a vendor announcement.

The choice between cloud and local deployment depends on data and skills. Cloud reduces the operational burden at the start, while self-hosting provides more control over networking, secrets, and logs. Either option needs a business process owner, not only the person who assembled the visual workflow.

Official n8n documentation supports filtering executions by status and retrying failed workflows with the original or currently saved definition. Production design must go further and decide which actions are safe to retry. Resending an email may be acceptable, while recreating an order or charging a payment can produce a duplicate. Those actions require idempotency keys.

How to calculate economics

Workflow runtime is not the same as company savings. The calculation should focus on employee time released and cost per successfully processed lead.

Consider a modelled example: a company receives 100 inquiries per working day. If registration and notification genuinely take 185 seconds each, the workload is about 5.1 hours. If automation leaves only 20% of cases for one minute of manual exception handling, the manual workload falls to roughly 20 minutes per day.

This is an assumption-based example, not a result from the study. Setup time, error control, infrastructure, integration maintenance, and exception handling must be deducted. An LLM also adds token or GPU expense, quality monitoring, and human review.

A two-week pilot

  • Select one repeatable process with three to five steps.
  • Measure 30–50 manual executions from intake to business outcome.
  • Separate deterministic steps from ambiguous ones.
  • Automate the rules without an LLM and add an operation key to prevent duplicates.
  • Connect a model to only one text step and define a threshold for human review.
  • Test API failures, timeouts, and retries.
  • Compare not only seconds, but successful lead rate, employee corrections, and total cost.

The management lesson is simple: the best AI-agent design sometimes begins by deciding not to use AI where a reliable workflow is enough.

Translated and adapted by the editorial team.