01What repeats
Copying data from one system to another, repeating the same task every week, fixing duplicates and chasing errors takes time and erodes trust in the data. Automation makes sense when the process is defined, repeats, the systems are accessible and the manual cost or error rate justifies the work. It does not make sense for a one-off send, as a replacement for a form, or for a flow nobody will supervise.
If the process has no clear steps, no owner and no rule for exceptions, the flow will replicate the ambiguity faster and with fewer people watching. Define it first; then automate what repeats.
02What it covers and what it does not
Includes
- Process map: steps, inputs, outputs and exceptions
- Identification of the process owner and who responds when it fails
- Review of current errors, volume and manual cost
- Flow design with triggers, conditions and retries
- Credential handling outside the repository
- Environment separate from production
- Tests with synthetic data and failure cases
- Rollback plan and criteria to switch the flow off
- Monitoring and error alerts
- Operations documentation
- Handover in the agreed environment
- Review of permissions and the legal basis for the data processed
Does not include
- Replacing the website form
- Automating a one-off send
- A flow with no owner and no supervision
- Processing live data without a legal basis and security
- Promising savings that have not been measured
03How we do it
-
01
Diagnosis
What is done today, how often, at what cost and which errors appear are reviewed. Without that data there is no way to decide whether automation is worth it.
-
02
Process map
Steps, inputs, outputs, exceptions and who owns each part are documented.
-
03
Decision
Automating, simplifying the process or leaving it as it is are compared. Sometimes the answer is a better form or a clearer rule, not a flow.
-
04
Specification
The trigger, the data, the systems involved, the expected errors and human supervision are defined.
-
05
Build and test
It is implemented in a separate environment and tested with synthetic data, including failure cases.
-
06
Deployment and monitoring
It goes live with a documented rollback, alerts and an owner who can switch it off. Ongoing maintenance is agreed separately.
04Price and scope
Quoted after diagnosis
What determines the costNumber of systems: how many have to be connected and how many steps cross between them. · Volume: how many runs and how many records move in each one. · API quality: whether they are documented, stable and what limits they impose. · Error handling: which failure cases have to be covered and who receives the alert. · Credentials: where they are held and how they are rotated outside the repository. · Monitoring and maintenance: alerts, review and adjustments when the process changes.
- Number of systems: how many have to be connected and how many steps cross between them.
- Volume: how many runs and how many records move in each one.
- API quality: whether they are documented, stable and what limits they impose.
- Error handling: which failure cases have to be covered and who receives the alert.
- Credentials: where they are held and how they are rotated outside the repository.
- Monitoring and maintenance: alerts, review and adjustments when the process changes.
05Timelines and response
Set after diagnosis; it depends on scope, integrations, access and API quality. How often the process changes and how many failure cases have to be covered also affect it.
Response policy: First response within 1 business day, Monday to Friday, Colombia and Spain time.
06Compatibility and access
To start, I need the process owner, access to the systems that have to be connected, the API documentation if it exists, a separate test environment and the person responsible for credentials. If the process has no owner or the access is unclear, that is resolved before designing the flow.
07What evidence we deliver
Declared capability. There are no publishable cases, metrics or verified savings with n8n, and evidence per technology is still pending. This page explains when automation makes sense and when it does not, not proven results.
08What you receive
| Deliverable | When |
|---|---|
| Process map | At the end of diagnosis |
| Flow specification | Before building |
| Implementation | At each delivery |
| Tests with synthetic data | Before deployment |
| Runbook | At handover |
| Credentials | At deployment |
09What happens next
At the end you receive the flow, the runbook and the credentials configured in your environment. After that come monitoring, error review and the agreed maintenance; adjustments for changes in the process are quoted separately. There is no permanent supervision or guaranteed response: what is covered is set out in the proposal.
See support and maintenance10Frequently asked questions
What can be automated?
Repetitive tasks between systems with accessible interfaces: moving data, creating records, sending notifications, syncing states or preparing reports. Anything that depends on undefined human judgement, happens once or has no clear owner is left out.
Is n8n required?
Not always. n8n is useful for orchestrating processes across tools when it fits and its operating cost is accepted. If the problem can be solved with a direct integration, a custom API or a better form, that is considered first.
What happens if it fails?
It is defined before building: which errors are expected, what retries exist, who receives the alert and how the flow is switched off. A flow without a failure plan is not delivered.
Who holds the credentials?
The client, in their own environment. Credentials are configured outside the repository and are not included in the documentation or the delivered code. The access needed to build and test is agreed and removed at the end.
Does it connect to WordPress, CRM or ERP?
Yes, if the system exposes a stable API or integration mechanism and there is permission to use it. The connection is tested in a separate environment before touching live data.
How is it priced?
Quoted after diagnosis. The price depends on the number of systems, the exceptions, the tests and the maintenance involved. There is no per-process rate or fixed package while the scope is not defined.