Documents
- Invoices and orders read out of an inbox
- Line items checked against the order
- Mismatches routed to a person to approve
- An archive that can be searched by content
Data moves between systems on its own, so nobody retypes it.
I connect the tools a company already uses and take the repeated typing off people: invoices, enquiries, orders, reports. Anything with a consequence stays a human decision. The work starts with one process, mapped on paper before any tool is chosen.
What gets automated
Four places where repeated work usually collects.
Enquiries and sales
- Form submissions into the CRM
- Classified and assigned to a person
- Replies drafted for approval
- Reminders on threads nobody answered
Catalogue and stock
- Catalogue synchronised with the storefront
- Stock and prices from one source
- Product descriptions and variants
- Orders exported to the warehouse system
Reporting
- Summaries assembled without anybody assembling them
- Dashboards over data from several systems
- Alerts when something moves out of range
- Delivery at a fixed time
How it starts
Four steps. A model, if one is involved at all, appears no earlier than the third.
Pick one process
One where the stake is visible: time, volume, the cost of an error, or what the customer experiences.
Map it
The data, the tools, the decisions and the exceptions. Exceptions are what break an automation later, so they get written down before anything is built.
Build a small flow
Input, context, action, a human in the loop and a measure of quality, running in production on a small scale.
Extend after measuring
I test it on real cases and add to it only once the base flow works on them.
What it is built with
Two tools, and which one a job gets is settled in step two above.
n8n, by default
It does more than a catalogue of ready-made connectors, and where no integration exists I write a node straight against the API. It can also be installed on your own server, so the data stays inside your infrastructure, and that is a difference no clause in a contract with a cloud provider makes up for. At high run volumes it costs less as well, because you pay for the server, however many operations run on it.
Make, where building anything would be too much
Two ready-made tools joined together, a form into a spreadsheet, a notification into Slack. Nothing gets written in those cases, and I tell you that up front.
Starting, and the refusal
Where to start
One or two sentences about work that comes back every week is enough. You do not need to know whether it is a job for a model, for a rule or for an integration between two tools. That is the first question I answer. A first automation, meaning the single process with a visible stake described above, is eight to ten hours of work once that process is described well enough to build against. That figure is the entry point and nothing wider: automating a whole department is a sequence of these, each with its own scope and its own date. I work from Wrocław, and business process automation works well remotely: a process is described in conversation and through access credentials, so I do not need to be on site.
When I say no
If a rule with three conditions does the job, a model would be a more expensive version of that rule, and I will tell you so. If two ready-made tools can be joined in Zapier or Make, nothing gets written. And if the form itself produces the errors, I fix the form before automating anything behind it.
Worth reading first
How to choose the process for a first automation, what to write down before asking for a quote and what the first month looks like are set out in an article on the blog.
Selected work
Four projects that run every day. Each write-up shows what was built and how it works.
Automation quote
Say what somebody at your company does by hand today and how long it takes. I will reply with a price and a date within one working day.
