Skip to content

Process automation

Business process automation

Business process automation takes over the tasks your team repeats every week: moving data, reconciling lists, sending reports, keeping colleagues informed. We build workflows that run without manual steps in between – with explicit error handling and an audit log for every run. The code, credentials and documentation are handed over to you in full.

Perspective

When process automation pays off – and when it does not

Automation pays off for work that is frequent, uniform and error-prone. For everything else, we will tell you.

Business process automation is the right answer when a task recurs regularly, follows fixed rules and takes up time that is needed elsewhere. Typical examples are data imports, reconciling stock or customer records between systems, monthly reports, or approvals passed along by email. Automating a business process rarely requires a new application – often a well-built workflow is enough, one that runs in the background and speaks up when something is wrong.

Many teams know the signs: every Monday someone exports a list, tidies it up in a spreadsheet and uploads it to another system. Somewhere a script moves data overnight – and whether it succeeded only becomes clear when something is missing. Workflows like these hold up as long as the right person is around. During holidays or sick leave they stall, and errors surface late.

Honesty applies here too: if a task only comes up a few times a year, doing it by hand with a good checklist is often cheaper. If your systems already include built-in automation, or an established workflow tool covers your case, we will recommend that. And if a process still changes every week, it should settle before anyone automates it. Custom workflow automation pays off where standard tools fall short on your data, your error handling or your need for traceability.

Services

What we build in business process automation

If you want to automate repetitive tasks, the building blocks are usually the same – always with error handling, an audit log and documentation.

Scheduled jobs

Workflows that run at fixed times: the overnight data sync, the Monday-morning report, the month-end reminder. We schedule them with cron or a job scheduler, prevent overlapping runs and make missed runs visible.

Event-driven workflows

Instead of waiting for a schedule, the workflow reacts to an event: a new order, a submitted form, a changed file. Webhooks and queues make sure nothing gets lost when a system is briefly unavailable.

Data import and export

We read data from files, mailboxes, databases or APIs, validate and clean it by fixed rules and write it to the target system – data import and export between systems without re-keying. Faulty records are not silently skipped but collected and reported.

Notifications by email, Slack or Teams

The workflow reports where your team already works: by email, in Slack or in Microsoft Teams. With clear rules on who hears about what, and when – so that notifications get read instead of disappearing into the noise.

Error handling and retries

Any step can fail – a counterpart is unreachable, a file is incomplete. We build retries with increasing back-off, detect duplicate processing and report persistent failures to a named person instead of swallowing them.

An audit log for every run

Every run leaves a traceable record: when it started, which data it processed, what failed and why. Metrics and alerts come with it.

Sequence

How an automation project runs

The same four steps as in all our projects – with the focus on how the process really runs today, exceptions included.

  1. Analysing today's process

    Over one to two weeks we walk through the process with the people who handle it today: which steps are there, which systems and files are involved, which exceptions come up? The exceptions in particular decide what can sensibly be automated and what cannot.

  2. A plan that covers failure

    In about a week we define what runs automatically, where a person decides and what should happen when something fails: who is notified, what is retried, what is paused. You see in advance which part gets automated first.

  3. Building alongside the manual process

    We work iteratively and, where possible, run the automation alongside the existing process at first. That way results can be compared before the manual version is retired. Every step is tested, versioned and writes to the audit log from the start.

  4. Handover and operations

    You receive the code, credentials, documentation and runbooks for the usual incidents: what to do when a run fails or a file arrives in the wrong format? Your team takes over after a walkthrough – or we keep operating the automation if you want us to.

Example

A typical case: price lists keyed in by hand every Monday

An assumed scenario, of a kind that comes up often in this or a similar form.

Not a client project

Suppose a trading company receives price and stock lists from several suppliers every week – as spreadsheets or CSV files attached to emails, each supplier with its own layout. One employee opens the attachments, adjusts the columns, corrects obvious mistakes and imports the data into the inventory system. Afterwards she sends sales a summary of the price changes.

What typically follows is that the process depends on one person. When she is on holiday, prices stay a week out of date. When a supplier changes its file format, nobody notices until wrong prices appear in a quote. And whether an import was complete is hard to tell afterwards, because there is no log. The real question is not technical but organisational: which deviations may the workflow correct on its own, and which must a person check?

In a case like this we would first write those rules down together, then automate step by step: for example reading the attachments from a mailbox and validating each supplier format first, then the import into the inventory system, and finally the summary for sales by email or Teams. Unclear records go to a review list instead of into the system. Whether this pays off at that scope is shown by the analysis – not by this example.

Technology

Simple building blocks, run transparently

For workflow automation we pick the simplest technology that holds. Often that is a scheduled job run by cron, or a small service that reacts to webhooks; multi-step workflows add queues so that steps can be retried individually. We mostly write the logic in TypeScript on Node.js, in Go or in Python, with intermediate state in PostgreSQL or Redis. If your organisation already uses a workflow tool, we first check whether the task can be solved inside it.

Every run produces logs, metrics and traces via OpenTelemetry. That way you see not just that a workflow failed, but where and with which data. The automation runs in containers – on your own servers, in your cloud or, if you prefer, operated by us.

  • Workflows
  • Queues
  • Event-driven
  • Cron
  • Webhooks
  • TypeScript
  • PostgreSQL
  • OpenTelemetry

FAQ

Frequently asked questions about process automation

What people actually ask about automating their workflows in first calls.

How much does business process automation cost?

The effort depends mostly on the number of systems involved, the quality of the data and the exceptions the workflow has to cover. Smaller tools and automations start in the four-figure range, from around €1,000; full applications, for example with their own user interface, typically land in the five figures depending on scope, larger platforms above that. After the analysis you receive an estimate with a price range.

Which processes are suitable for automation?

The best candidates are tasks that happen often, follow fixed rules and work with digital data: imports, reconciliation between systems, reports, reminders, routing. Less suitable are processes that keep changing, or where nearly every case needs an individual decision. Often, though, part of a process can be automated while the decision stays with a person.

Custom automation or an off-the-shelf workflow tool?

For simple connections between common cloud services, ready-made workflow tools are often the faster and cheaper choice – and then we recommend them. A custom solution pays off when your systems are not supported there, the data logic is complex, data should not leave your organisation, or you want to decide on error handling and logging yourself.

What happens when an automation fails?

It tells you. Temporary failures, such as a counterpart that is briefly unreachable, are retried automatically at increasing intervals. Persistent failures trigger a notification to the responsible person, by email, Slack or Teams. The audit log shows which run failed, at which step and with which data – so the case can be fixed precisely and the run repeated.

Can process automation be built in a GDPR-compliant way?

We put the technical groundwork in place: operation inside the EU or on your own servers, access with narrowly scoped permissions, only the data the workflow genuinely needs, and logs containing as little personal data as possible. The legal assessment stays with your data protection officer or legal counsel.

More services

Web applications & business tools

Internal tools and customer portals that mirror how the work is actually done, instead of complicating it.

  • TypeScript
  • React
  • Next.js
  • PostgreSQL

APIs & system integration

Interfaces that connect existing systems cleanly – specified, versioned and documented.

  • OpenAPI
  • REST
  • Webhooks
  • OAuth 2.0

AI assistants & LLM integration

Assistants and chatbots that work on your own data and can show where an answer came from.

  • LLM
  • RAG
  • Vector search
  • MCP

Which task takes up most of your team's time today?

Briefly describe what is currently done by hand and which systems are involved. You get an honest assessment of whether automating it is worth it.

Reply within 24 hours on business days