Operations and maintenance so your workflows keep running
An automated workflow is not a piece of furniture. Connected systems receive new versions, field names change, credentials expire. Ongoing support monitors the interfaces, reviews error messages, applies updates and adjusts rules whenever something around the workflow moves. From 190 € net per month, cancellable monthly.
24/7
automated checks on the monitored workflows
1
named contact instead of a rotating queue
2
operations reports per year with metrics and open items
10
service areas from analysis through to operations
Ongoing support · net plus VAT
- Monitoring reports a stoppage before anyone in the department notices it
- One named contact who knows your workflows instead of an anonymous queue
- Adjustments to changed field names, approval limits and credentials within the agreed scope
- Cancellable monthly at the end of the agreed period, no multi-year commitment
Included are monitoring of the workflows in place, review and triage of error messages, updates to the components we operate, and small adjustments to rules and fields within the agreed scope. The monthly fee rises with the number of workflows under support and the agreed response framework. Larger extensions are quoted as a separate measure from 4,900 € net. All amounts net plus statutory VAT. The full breakdown of our pricing sits on the pricing overview.
Prices as of September 2026.
An automated workflow is finished once it runs — and it stays finished as long as its surroundings hold still. They rarely do: software vendors ship new versions, field labels change, credentials expire, mailboxes are migrated, and day-to-day operations throw up cases nobody considered at rollout. Ongoing support makes sure such changes surface before somebody in the business quietly goes back to doing the work by hand. It requires at least one implemented measure: we support what we built together.
Operations overview: what the monitoring shows day to day
What ongoing support actually covers
The word maintenance covers very different things in this industry, from a bare promise of reachability to an all-inclusive package with no visible boundary. That is why we set out in writing, before any engagement, which workflows are monitored, which messages we handle, which adjustments the monthly fee includes and from which point a change is quoted as a separate measure. The following six areas form the core of every support agreement.
Interface monitoring
Every transfer in place reports back when it stops running, when records pile up or when a target system fails to answer. The checks run automatically in the background, not only when somebody in the department raises a hand.
Reviewing error messages
Not every alert is a problem. We look at what actually sits behind it, reprocess the records left behind, and come back to you when a decision has to be taken on the business side.
Updates and patches
The components we operate receive security and feature updates. Before larger version jumps we verify on a test environment that the connected workflows still behave the way the documentation describes.
Adjustments when things change
A new field, a changed approval limit, an additional recipient on a distribution list, a renamed status value: small changes within the agreed scope run through support without becoming a new project.
A contact for incidents
You report to a fixed address and speak to someone who knows your workflows. No re-explaining the background at every contact, no handover between support tiers.
Operations report and documentation
Twice a year we summarise which alerts came in, what became of them and which points remain open. The process documentation is kept current as part of that.
Monitoring: what is measured and what triggers an alert
Interfaces rarely fail with a bang. The quiet failure is far more common: the transfer keeps running technically but has not delivered a record since yesterday afternoon, because the source system now rejects the login. Anyone who only checks whether a service responds sees none of this. So we monitor the workflow rather than the service: how many items have passed through in recent hours, how old the most recent transferred record is, how many entries sit in the error list and how long the queue has been standing.
The thresholds are agreed with you, because they depend on the workflow. An order import that receives data every few minutes during business hours must not sit still for two hours. A nightly handover to accounting, by contrast, is meant to be quiet all day and only has to show a result in the morning. Badly chosen thresholds are the most common reason monitoring gets switched off again: anyone who receives daily alerts that turn out to be nothing eventually stops looking.
- Throughput per workflow against an expected corridor rather than a fixed number
- Age of the most recent transferred record per direction and target system
- Queue length and the number of entries in the error list
- Response behaviour of connected systems, including rate limits on frequent access
- Expiry dates of credentials and certificates with lead time instead of on the day
- Result checks on scheduled runs: not merely started, but finished cleanly
When something stops: the path of an incident
There is a fixed path for the case where a workflow stops. It is deliberately short, because in these situations coordination costs more time than the actual work. The order matters: the backlog is secured first, the cause is investigated second. Records created during an incident must not be lost, and they must not arrive twice once the transfer resumes.
The alert comes in
Monitoring detects that a workflow has left the agreed corridor and notifies us. Your team sees the alert in parallel where that has been agreed. For selected workflows we inform you even when the matter is already in hand.
Secure the backlog
Before we investigate, we make sure no data is lost. Open items stay in the queue, partially transferred records are flagged, and the resumption is prepared so that a repeated transfer does not create duplicates.
Narrow down the cause
We read the logs and narrow down where the workflow is stuck: an expired login, a renamed field, a record that breaks a rule, or a system that is not answering right now. The finding is recorded, not merely fixed.
Fix it or route around it
If the cause sits with us, we fix it. If it sits in a connected system, we word the report to your software vendor so it can be handled there without further questions — with timestamp, sample record and error text. Until it is resolved we set up an interim route where that is feasible.
Reprocess and report back
Once resolved, the records left behind are reprocessed and we sample-check that they arrived correctly in the target system. You receive a short written summary: what happened, what came of it, and what we changed so the same case does not slip through unnoticed again.
Monitoring detects that a workflow has left the agreed corridor and notifies us. Your team sees the alert in parallel where that has been agreed. For selected workflows we inform you even when the matter is already in hand.
Before we investigate, we make sure no data is lost. Open items stay in the queue, partially transferred records are flagged, and the resumption is prepared so that a repeated transfer does not create duplicates.
We read the logs and narrow down where the workflow is stuck: an expired login, a renamed field, a record that breaks a rule, or a system that is not answering right now. The finding is recorded, not merely fixed.
If the cause sits with us, we fix it. If it sits in a connected system, we word the report to your software vendor so it can be handled there without further questions — with timestamp, sample record and error text. Until it is resolved we set up an interim route where that is feasible.
Once resolved, the records left behind are reprocessed and we sample-check that they arrived correctly in the target system. You receive a short written summary: what happened, what came of it, and what we changed so the same case does not slip through unnoticed again.
A response framework, not an availability figure
Updates and changes in the connected systems
Two out of three incidents that reach us through support do not originate in the interface itself but in a change to a connected system (project experience). A new version of the industry software renames a field, a vendor retires an older interface version, an approval limit is adjusted internally, a mailbox is moved. To the interface this looks like a fault, even though nobody in the business did anything wrong. Applying security updates promptly is among the baseline recommendations of the German Federal Office for Information Security (BSI) — in a connected system landscape it is also the most frequent trigger for adjustment work.
Announced version changes
When your software vendor announces a new release, we check in advance which of the supported workflows may be affected and schedule the test before the switchover date rather than after it.
Credentials and certificates
Credentials, keys and certificates expire. We track them in monitoring with lead time, so the rotation happens as planned instead of surfacing on a Friday afternoon.
Changed field usage
New mandatory fields, renamed status values or additional options in a picklist change the mapping. The field mapping is brought up to date and the documentation updated with it.
Security and access rights
Integration accounts hold only the rights the respective workflow needs. When staff or permissions change, we check that the workflows still run under the account intended for them.
Small adjustment or separate measure?
The line between the two is a frequent source of argument in support agreements, which is why we put it in writing up front. A small adjustment stays inside the existing logic: an additional field in an existing transfer, a changed threshold, one more recipient. As soon as a new workflow appears, another system joins or the business rules change fundamentally, it becomes a separate measure with its own fixed price. You then receive a short estimate and decide for yourself.
- Included: extending a field mapping, adjusting thresholds, changing recipients, correcting texts
- Included: reprocessing records left behind after an incident
- Separate measure: a new workflow, another system, changed business logic
- A written estimate before every measure; without your approval, no work and no charge
Response framework and reachability
Not every alert needs the same speed. An order import that has stalled during business hours carries a different urgency than a field request for a report. We therefore sort messages into classes and agree a framework per class. Which framework applies to you is written into your support agreement and depends on the scope you choose. The table below shows the usual grouping as orientation, not as a general commitment.
| Type of alert | Example | Usual response framework | What happens first |
|---|---|---|---|
| Workflow has stopped | Orders have not been handed over since this morning | Response the same working day | Secure the backlog, narrow the cause, check an interim route |
| Records left behind | Some documents land in the error list, the rest run through | Response the next working day | Review the pattern, reprocess records, tighten the rule |
| Change announced | Your software vendor announces a new release | Session before the switchover date | Identify affected workflows, schedule the test |
| Small adjustment requested | An additional field should be transferred as well | Assessment within a few working days | Size the effort, implement in scope or estimate |
| Question from the team | Why has this item been on hold since yesterday? | Answer during ongoing operations | Read the log, explain the state, record the cause |
| Reporting request | One more metric should become visible | Added to the list of open items | Size the effort, weigh it up in the operations report |
Not sure which scope fits your workflows?
Tell us which workflows run automatically at your company and how critical they are day to day. We will propose a support scope that matches — without components you do not need.
What ongoing support costs
The monthly fee follows the number of workflows under support, the number of systems involved and the agreed response framework. A single nightly reconciliation between two systems sits at the lower end; several same-day transfers with a tight response framework sit above it. Licence, hosting and third-party costs are shown separately from the support fee, with provider and recurring amount, so it stays visible which part goes to third parties permanently. The components we build are operated on servers in Germany.
Three levels of support
All amounts net plus VAT. At least one implemented measure is required. The fee is agreed according to the actual scope and set out in writing.
Basic support
For one or a few workflows that are not minute-critical in daily business.
- Monitoring of the workflows in place with notification on stoppage
- Review and triage of incoming alerts
- Updates to the components we operate
- Small adjustments to fields and thresholds within the agreed scope
- One named contact and responses on working days
Extended support
For several workflows across different systems that run on a same-day basis.
- Everything from basic support, for several workflows and systems
- Tighter response framework for the transfers you flag as critical
- Announced version changes verified on a test environment
- Reprocessing of records left behind included in the fee
- Half-yearly operations report with metrics and open items
Support with further development
For companies working through the list of measures from the analysis step by step.
- Everything from extended support
- A fixed quarterly session on status, metrics and next steps
- Prepared estimates for the next measures on the analysis list
- Guidance on replacing legacy systems in stages
- New measures still implemented at a fixed price from 4,900 € net
All amounts net plus statutory VAT. Support is optional and not a precondition for an implementation. It can be cancelled monthly at the end of the agreed period; the workflows in place and the documentation remain yours.
Three ways to keep an automated workflow running
A plain comparison so you can judge what fits your size and your risk.
Operated by your own team
- Included: Short paths, because knowledge and responsibility stay in house
- Included: No recurring cost for an external agreement
- Not included: Needs someone who reads logs and triages alerts
- Not included: Holidays, illness or a departure leave no cover
- Not included: Interface know-how has to be maintained continuously
React only when it breaks
- Included: Costs arise only when there is actually something to do
- Included: Often sufficient for low-frequency, non-critical workflows
- Not included: The outage surfaces only once work has piled up
- Not included: The backlog has to be cleared afterwards, often by hand
- Not included: Handled by effort and availability rather than an agreed framework
Support with monitoring
- Included: Alerts are raised automatically, not by chance during daily business
- Included: A named contact who knows your workflows and systems
- Included: Predictable monthly fee from 190 € net plus VAT
- Included: Documentation stays current, including after staff changes on your side
- Not included: Recurring cost even in months when little happens
Typical operational cases
Illustrative scenarios from typical project histories (project experience), anonymised and without client details. Transferability to other companies is not assured.