Workflows that run on spreadsheets, email and three departments hold up until volume grows or someone is off sick. I replace them with systems wired into the software you already run, with permissions, a traceable log, and no tool chain sitting in between that belongs to nobody.
The process survey is a self-contained one to two week engagement. Implementation follows process by process, so the first benefit lands early.
Remote from Germany. Straight with me, no agency in between.
Grown workflows are rarely documented. Someone exports a list, someone checks it, someone types the result into a second system. That works while volume stays small and the people stay put. Both of those change.
The obvious answer is a chain of automation tools. It stands up quickly and holds until an interface changes, an access key expires, or someone asks who triggered which change. I build a service that belongs to the rest of your system landscape instead: versioned, monitored, and with permissions that match the ones you already have.
Typical symptomsI look at what actually happens, not what the handbook says. Who does which step, how often, how long it takes, and where the errors appear that someone corrects later. That tells us which part is worth automating and which part is better left to a person.
Inventory management, ERP, shop, CRM. There is usually an interface, sometimes only a database or a file export. I connect to what is there instead of making a system replacement a precondition. Where an interface is missing, it gets built properly rather than worked around.
The automated process becomes a service like any other: in Git, in the pipeline, with tests and a deployment. Event-driven so individual steps can be retried, and idempotent so a second run does no damage.
No process is a hundred per cent automatable. Exceptions do not disappear into nowhere, they land in a queue with clear ownership. Where a decision needs a person, it gets presented to them with the context they need to make it.
Free text, receipts, unstructured documents. This is where a language model is the right tool, embedded in the workflow, with a confidence threshold and a fallback to manual review. The rest of the process stays deterministic, because it should be.
Every run is logged: what came in, what was decided, what went out. Plus monitoring on throughput and error rate, so a process that starts drifting becomes visible before the department reports it.
The first process goes live early. You decide on everything after it once you have seen the benefit.
Which workflow eats the most time or causes the most errors. 30 minutes is enough to place it.
Volumes, interfaces, exceptions. The result: what can be automated, with effort and savings attached.
One workflow completely rather than five halfway, including error handling, logging and monitoring.
Further processes on the same foundation. Each one after the first is cheaper than the first.
Repetitive handwork disappears. The department handles exceptions instead of routine cases.
Holiday, illness or a resignation no longer bring the process to a halt.
For every run it is documented what happened and why. Months later as well.
For a bounded workflow with stable interfaces, quite possibly, and I will tell you so. I come in when the process is business critical, when it has to reach systems with real permissions, or when it has to be traceable who triggered what and when. The difference does not show up on day one. It shows up the first time an interface changes.
No. I connect to what is there: an interface, a database or a file export. Making a system replacement a precondition would push the automation out by years and put the benefit at zero until then.
From the volume figures in the process survey: how often the workflow runs, how long it takes, how much rework it generates. If the numbers do not add up, I say so. The more honest recommendation is then to simplify the process, or leave it alone, rather than automate it.
Only where rules run out: free text, receipts, unstructured documents. The rest stays deterministic, because a workflow that should do the same thing every day ought to do the same thing every day. A language model is a tool inside the process, not the process.
In the projects I know, they end up handling the cases that genuinely need a decision instead of working through routine ones. What that means in your company is your call. My job is to put the numbers on the table.
The infrastructure behind AI systems that actually ship: MCP servers, controlled tool access, LLM integration with real permissions and cost control.
Learn moreI find where your AWS budget leaks away, and cut it measurably without giving up performance or availability.
Learn moreFrom your own data centre or another cloud onto AWS, with a cost model before the move and a rollback path for every step.
Learn moreModernizing grown systems step by step: strangler fig instead of a rewrite, operations untouched, every step reversible.
Learn moreBackends for SaaS and platforms that hold under real load: Go and PHP 8, event-driven, with tenant isolation and recovery designed in.
Learn more