Process automation: replacing repetitive manual work
Transfer data instead of retyping it, match documents to the right case, handle notifications and approvals, produce reports without collating them by hand. We automate the steps that repeat in the same shape every week — and leave the cases that need judgement and experience with your people.
Per automation · net plus VAT
- One clearly scoped workflow per measure instead of a single large rebuild
- Functional specification and rules written down before development starts
- Error handling, audit trail and manual fallback are part of the fixed price
- Handover with documentation and a briefing for the people involved
A clearly scoped automation starts at 4,900 € net — as a fixed price that is set after the process analysis and describes the scope in writing. The analysis itself starts at 1,900 € net and determines which workflow goes first. For monitoring, fault clearance and adjustments, ongoing support starts at 190 € net per month. All prices net plus VAT; third-party licences and fees are shown separately. The full breakdown is on the pricing overview.
Prices as of September 2026. Ongoing services are booked individually and can be cancelled monthly; there is no minimum term.
Automation sounds like a large undertaking. In practice it consists of many small steps that somebody currently performs by hand: copying an order number from an email into a program, matching a delivery note to the right case, chasing an approval that has been sitting untouched, pulling figures from three programs into a spreadsheet at month end. Individually, none of these steps stands out. Together, in the companies we work with, they regularly consume several hours per week per person (project experience). That is exactly where we start — not with another program, but with a rule that performs the step from now on.

One repeating step, before and after
Which manual work is worth automating
Not every manual step is worth automating. It becomes worthwhile where four conditions meet: the step repeats regularly, it follows a rule that can be put into words, the data required sits in a system that can be read out, and a mistake at that point has noticeable consequences. If one of these conditions is missing, the effort usually outweighs the benefit. That is why the process analysis comes first: it records how often a step occurs, how long it takes, who performs it and which systems are involved. Only with those figures can you judge whether an implementation pays off.
The order matters, because automation amplifies an existing workflow. A workflow that runs untidily by hand will run untidily once automated — only faster and across more records. So we clarify the rule first and build it afterwards. It often turns out that a step does not need automating at all but can be dropped, because nobody uses the result any more. A cancelled task is the cheapest form of automation, and we say so even when it makes the project smaller.
What we typically automate
The following six areas appear in almost every project, whether the company is a trade business, a manufacturer, a service provider, a wholesaler or a public administration. They can be commissioned individually and build on each other sensibly: once data is transferred cleanly, documents can be matched, and once documents are matched, reports can be generated from them.
Transfer data instead of retyping
Order, customer and item data moves between the programs involved without anyone entering it a second time. The basis is either interfaces or a controlled file exchange where a system offers no interface at all.
Match and file documents
Incoming invoices, delivery notes and order confirmations are captured, read out, matched to the right case and filed traceably. The detailed route is described under document digitisation.
Trigger notifications
When an order changes status, a deadline approaches or a stock level falls below an agreed threshold, the information reaches the responsible person — instead of waiting for somebody to go and look.
Map approvals
Who approves from which amount upwards, who stands in during absences, and what happens when an approval is left sitting? The route is defined once and is then followed, chased and logged by the system.
Generate reports automatically
Capacity for the coming weeks, open items, material consumption: reports are produced from the source systems and are ready at the agreed time. More on this under metrics and reporting.
Keep master data aligned
Address changes, new items and revised prices are maintained in one place and distributed to the other systems, so three programs do not hold three versions. The groundwork is covered under data integration.
Where automation reaches its limit
Automation replaces repetition, not judgement. A workflow with many exceptions, rare special cases or a trade-off that draws on experience belongs in human hands. We say so openly, even when it costs us revenue: if a case occurs twenty times a year and looks different every time, a well-written work instruction is the sounder answer than a rule in the system. An over-ambitious rule set produces special cases that nobody can survey later — creating exactly the mistrust that automation was meant to remove.
Three attitudes towards automation
Between the ambition to automate everything and the decision to keep doing it by hand lies the route we consider workable.
Automate everything
- Included: Even rare special cases are held in the system
- Included: The workflow is described in full and can be repeated
- Not included: The rule set grows until nobody can survey it
- Not included: Every exception creates yet another special rule
- Not included: Effort and maintenance grow faster than the time saved
Carry on by hand
- Included: No changeover and no rollout costs
- Included: Every case is decided individually
- Not included: Duplicate entry and transfer errors remain in place
- Not included: Knowledge depends on individuals and their availability
- Not included: Reports still have to be collated by hand
Automate selectively
- Included: Start with the steps that repeat often and in the same shape
- Included: Exceptions are deliberately routed to manual handling
- Included: Error handling and audit trail belong to every measure
- Included: Fixed price per measure from 4,900 € net after the analysis
- Not included: Requires a clear decision on which case counts as an exception
What deliberately stays with people
Error handling and logging are part of the job
An automation that only knows the normal case is not a finished automation. A target system is temporarily unreachable, a file arrives in an unexpected format, a mandatory field is empty, a document belongs to no known case. These situations do not occur by exception but regularly — and they decide whether the result is still trusted six months later. We therefore plan the handling of faults with the same care as the workflow itself.
Retry with backoff
If a run fails because a system briefly does not respond, the automation retries at growing intervals — instead of giving up straight away or looping endlessly and writing the same data several times over.
Errors with an owner
Anything that cannot resolve itself lands in a visible list with an owner and a deadline — not in a shared mailbox nobody looks into. Whoever handles the case sees the cause and the record in one place.
A traceable audit trail
Every run is recorded with timestamp, trigger, volume processed and outcome. That makes it possible to answer later why a record looks the way it does — and whether a case was skipped or altered.
Manual operation stays possible
Every automation can be paused, and the affected step can be carried out by hand. That is the fallback for maintenance windows, faults at third parties and special cases outside the rule.
These four points are part of every implementation and not a surcharge. They are also the reason why we are reluctant to hand over automations without accompanying operations: audit trails only help when somebody looks at them, and error lists only when somebody works through them. Where you prefer to take that on yourselves, we set up responsibilities so your team can act without us, and record it in the process documentation.
An example: taking over order data instead of retyping it
An order arrives by email, is noted in the calendar, typed into the job software and additionally kept in a list so scheduling keeps an overview. Four entries for one case, three places where things can drift apart. Automation turns that around: the order is captured once and distributed from there to the other systems. Appointments derive from the order, scheduling reads the same status, and invoicing draws on the same line items. Anything that cannot be matched unambiguously — an unknown customer, a missing line item — goes into the clarification list instead of becoming a silent mis-posting.
- Starting point: the same case is captured and maintained in four places
- Implementation: one leading entry, controlled hand-off, clarification list for exceptions
- Result: one status for scheduling and invoicing, fewer queries day to day
How an automation runs with us
Record the workflow
We follow the workflow where it actually happens and note every step, every hand-off and every waiting time. What counts is what people really do, not what an old procedure document says. The recording shows which steps repeat and how often.
Write the rule down
Before development, we write down what should happen from now on: which data comes from which system, which field maps to which field, what happens when details are missing, and which case deliberately stays an exception. We agree this specification with everyone involved.
Build on a test environment
Implementation happens separately from daily operations, using copies of real data. That way the result can be checked without a failed attempt changing documents, stock levels or appointments in the live system.
Test with real cases
Acceptance takes place on cases from everyday work, explicitly including the awkward ones: incomplete details, cancellations, subsequent additions, duplicate documents. The workflow only counts as finished once those cases end cleanly.
Go live and stay close
The start happens in a quiet time window, initially under close observation. During the first weeks we review the audit trails together, clarify anything unusual and adjust thresholds and timings to reality rather than to assumptions.
Hand over and develop further
At the end there is understandable documentation, a briefing for the people involved and an agreement on who will watch the error list and the audit trail. On request we take that part on through training and rollout and ongoing operations.
We follow the workflow where it actually happens and note every step, every hand-off and every waiting time. What counts is what people really do, not what an old procedure document says. The recording shows which steps repeat and how often.
Before development, we write down what should happen from now on: which data comes from which system, which field maps to which field, what happens when details are missing, and which case deliberately stays an exception. We agree this specification with everyone involved.
Implementation happens separately from daily operations, using copies of real data. That way the result can be checked without a failed attempt changing documents, stock levels or appointments in the live system.
Acceptance takes place on cases from everyday work, explicitly including the awkward ones: incomplete details, cancellations, subsequent additions, duplicate documents. The workflow only counts as finished once those cases end cleanly.
The start happens in a quiet time window, initially under close observation. During the first weeks we review the audit trails together, clarify anything unusual and adjust thresholds and timings to reality rather than to assumptions.
At the end there is understandable documentation, a briefing for the people involved and an agreement on who will watch the error list and the audit trail. On request we take that part on through training and rollout and ongoing operations.
since 2013
experience with business IT
50+
projects delivered (project experience)
2-6 weeks
typical duration per automation (project experience)
1
named contact throughout the project
Automation without creating another island
A common failure starts with good intentions: a workflow is automated with an extra tool that nobody else knows. A year later the person who set it up has moved to another area, the tool has a new version, and the workflow quietly stops running. We therefore start with the systems already in the house and only build something extra where a genuine gap remains. Whatever we do build runs on servers in Germany and is documented so that others can take it over.
| Aspect | Automation as a standalone tool | Our approach |
|---|---|---|
| Starting point | The tool is chosen, the workflow adapts to it | The workflow is recorded, then the means is chosen |
| Scope | As many steps as possible in one go | One clearly scoped workflow per measure, with its own benefit |
| Exceptions | Added as special rules over time | Named upfront and deliberately routed to manual handling |
| Faults | Only noticed when somebody misses a result | Retry, error list with an owner, audit trail per run |
| Knowledge | Sits with the person who set it up | Documented and briefed, operations from 190 € net per month |
- Which system owns the information when two versions drift apart?
- What happens when mandatory details are missing: stop, ask, or park the case?
- Who works through the error list, and within what deadline?
- Which cases deliberately stay manual, and how does the system recognise them?
- How long are audit trails kept, and who is allowed to view them?
- What does the way back look like if the automation has to be paused?
What an automation costs
The price of an automation depends on three factors: the number of systems involved, the depth of the rules and the condition of the data. A workflow between two systems with well-maintained master data sits at the lower end; a workflow across four systems with inconsistent number ranges sits noticeably above it. Because we know the scope after the analysis, we quote a fixed price instead of an open estimate. All amounts are net plus VAT; third-party licence and usage fees are shown separately so the invoice stays easy to follow.
Price components for your automation
All prices net plus VAT. The amounts shown are entry-level prices. The binding fixed price for the implementation is set after the process analysis.
Process analysis
Stocktake of your workflows and a decision on what gets automated first.
- Recorded on site or in a video session, depending on the workflow
- Frequency, duration and people involved captured per working step
- Findings list covering duplicate entry, media breaks and waiting times
- Prioritised measures with effort ranges and a suggested sequence
- Written report you may use freely, even without a follow-up order
Implementation per automation
One clearly scoped workflow, built in full and taken into operation.
- Functional specification with field mapping and rules before development
- Implementation on a test environment using copies of real data
- Error handling with retry, clarification list and an audit trail per run
- Acceptance on real cases, including the exceptions
- Handover with process documentation and a briefing
Ongoing support
So what has been built keeps running steadily and grows with you.
- Monitoring of the automated workflows with an alert when they stall
- Small adjustments to rules, fields and thresholds within the agreed scope
- Checks before updates to the systems involved
- A named contact instead of rotating ticket handling
- Cancellable monthly at the end of the agreed period
All prices net plus VAT. The binding fixed price for the implementation is set after the process analysis. Third-party licence and usage fees are shown separately from the fixed price.
Which manual step repeats every week in your company?
Tell us briefly which step takes up your time and which programs are involved. You will get an assessment of whether automation pays off and where we would start.
Typical starting points from projects
Illustrative scenarios from typical project situations (project experience), anonymised and without client details.
