Process automation: where someone copies the same thing every day
How do you recognise that something should be automated?
Three symptoms, from practice:
- The "copy-paste" colleague. Every morning someone opens two systems and moves data from one to the other. Orders from the store into the invoicing system. Stock from a spreadsheet into the admin. Rows from emails into a spreadsheet. That is not a job description, that is a missing script.
- The month-end report that takes days. Anything assembled by hand from several sources is not just slow — it also makes mistakes. An automated report writes itself, always the same way.
- The "we only found out two weeks later" failure. An order got stuck, an invoice never went out, a disk filled up — and nobody said a word. Half of automation is not doing the work but the alerting: if something jams, you get an email immediately, instead of hearing it from the customer.
What exactly do I build?
- System connections. Store ↔ invoicing, store ↔ inventory, form ↔ CRM ↔ email, bank ↔ accounting export. If your system has an interface or an API, it can be connected; if there is no API, there is still a way: scheduled export-import, or driving the interface.
- Scheduled processing. Overnight price updates, stock sync, weekly reports, automated backups. Written once, running under supervision — this is what it looks like in production at the tool that manages a full catalogue, which replaced hours of daily manual work.
- Language-model-based processing — where it genuinely pays off. Classifying incoming email, structuring free-text orders, extracting data from documents. Not magic: with a verification step, logging, and a human approval point wherever being wrong is expensive.
- Alerting and logging. Every automation logs, and speaks up on failure. That is the difference between "I wrote a script" and "a system that can be kept running".
What does it cost, and how do you calculate the payback?
For smaller tasks, hourly billing: $50 per hour (net), within a budget agreed in advance. For larger, well-bounded tasks, a fixed-price quote.
The payback calculation is simple: (minutes saved per day × working days × the colleague's hourly wage cost) minus the cost of development. A task taking 30 minutes a day is roughly 125 hours of wages a year — most automations turn positive within a time measured in months. In the first conversation we run this calculation together with your numbers; the formula and a worked example are here: half an hour of daily copy-paste = 125 hours a year.
What does this connect to?
Automation rarely stands alone. If the incoming data comes from a form or a page, that is a custom website; if it comes from an order, it is the post-order stretch of the web store. The same project — just the part a person has been standing in for.
Frequently asked questions
Our system is very old, or very unusual. Does this still work?
Usually yes. As a first step I look at what connection points it has (API, export, database, interface), and I tell you honestly if it is not worth it.
What happens when an automation fails?
It logs and it alerts. Critical steps — money, invoices, outgoing communication — get a human approval point, until you trust it.
Will I be dependent on you?
No. The code, the documentation and every access credential are yours; I build on established technology so any developer can take it over.
How soon do results show?
A well-bounded connection is typically a matter of days, a process spanning several systems a matter of weeks. The first step is always the most painful, most measurable task — so the payback shows at the start of the project, not at the end.