Routine work disappears from your team’s day

What to automate first

The temptation to start with the most complex, most visible process is strong, but the opposite approach pays off. Take the tasks where three traits meet first: they repeat many times a week, they follow a clear rule, and they cost somebody real time.

• Moving data between systems — from a form to the CRM, from the CRM to a spreadsheet, from the spreadsheet to accounting.
• Producing documents: contracts, invoices, statements, template-based proposals.
• Reports somebody assembles by hand every Monday.
• Reminders and approvals that rest on somebody’s memory.
• Routing leads and tasks by rules everyone already knows by heart.

Those tasks are boring, and that is exactly why automating them returns the investment fastest: the result shows up in the first week and the risk of error is minimal.

Describing a process before automating it

You can only automate what has been described. Most often the process exists as “Marina knows how it is done”, and the first honest step is getting that knowledge out into the open.

1. What starts the process: an email, a lead, a date, an action in the CRM.
2. What data is needed as input and where it comes from.
3. Which decisions are made along the way and by what rule.
4. What counts as successful completion — and how to verify it.
5. What to do on an exception: missing data, service failure, an edge case.

The last point is skipped most often, and it is the one that decides whether the automation will be reliable. A scenario with no failure path will one day quietly stop working, and you will find out a week later from an unhappy customer.

n8n, Make or custom code

The tooling question is settled not by taste but by three things: how complex the logic is, what the data requirements are, and who will maintain it a year from now.

• Make — a fast start for linear scenarios with popular services. Great when the logic is simple and rarely changes.
• n8n — when there are many scenarios, the logic branches, and the data must not leave your infrastructure: it can be self-hosted.
• Custom code — when the load is high, the integration is non-standard, or the required behaviour would take ten workarounds in a visual builder.

In real projects it is nearly always a mix: heavy logic in code, wiring and integrations in n8n. We try to keep most of the system in a visual form — so somebody other than its author can read it.

Reliability: what happens when it breaks

Every automation eventually breaks: a third-party service changes its response format, a token expires, somebody renames a column in a spreadsheet. The question is not whether it happens but whether you find out within the hour.

• Retries with backoff — most failures are network hiccups and resolve on their own.
• A notification to a responsible human on failure, not an entry in a log nobody reads.
• A queue of unprocessed jobs: when the service comes back they get through instead of being lost.
• A manual fallback for critical processes — so the business does not stop entirely because of one broken scenario.

Data and access

Automation by definition gets access to a company’s working data, and this is not the place to economise on care. We stick to simple rules: keys and tokens are created on the client’s side, access is granted at the minimum needed, and each service gets its own key that can be revoked without breaking the rest.

When the work is done, access is handed to the client along with documentation of what sits where. A situation where a company cannot maintain its own automation without the contractor is not acceptable to us.

How to calculate the payback

Do the maths before the deployment, otherwise there is nothing to compare the result against. The formula is simple: how many times a month the operation runs, times the duration of one run, times the hourly cost of the employee. That is the upper bound of the saving.

To that you should add what usually goes uncounted: the cost of manual-entry errors, the cost of delays in approvals, and the cost of a qualified employee copying rows instead of doing the work they were hired for.