Core service
Automation is not a one-off purchase
The build is the cheap part. Platforms deprecate nodes, APIs change their contracts, credentials expire, volumes grow past what the original architecture assumed. A retainer is what keeps a working system working.
The problem
What this usually looks like
An automation was built, it worked, and then one day it quietly stopped — or worse, kept running and produced wrong output. Nobody noticed for a fortnight because nothing was watching it.
What you get
- Monitoring, with notification to a named person when a run fails
- Break-fix: restoring the agreed behaviour when something stops working
- Credential and token rotation support before things expire
- Adapting to third-party platform changes, within the monthly allowance
- Minor adjustments: thresholds, recipients, wording, schedules, field mappings
- A monthly summary — runs, failures, hours used, and anything needing your attention
How the work runs
01
Inventory what is covered
A written list of the systems under support. Anything not on the list is out of scope until it is added — which is the point of listing them.
02
Set severity and response
S1 down, S2 degraded, S3 minor. Each with a target response measured from when we are notified, inside the agreed coverage window.
03
Monitor
Failures notify automatically. A workflow that fails loudly is a small problem; one that fails silently is the expensive kind.
04
Report monthly
What ran, what failed, what was fixed, hours used against the allowance. An invoice that matches a report nobody wrote is how retainers quietly overrun.
Stack
What we build it with
Honest limits
What this is not
- New workflows, new integrations, or new steps in an existing one — those are quoted as work, not absorbed into a retainer.
- Changes to business logic, pricing rules or approval chains.
- Recovery of data lost through your own systems or a third-party outage.
- Work caused by changes made to connected systems without telling us.
Systems we have already built like this
Every entry documents the business problem it solves, what it does and the architecture behind it. Not for sale — they are what we build for you, adapted to your systems.
Straight answers
What counts as a fix versus a new piece of work?
A fix restores the behaviour that was agreed. An enhancement changes or extends it. Restoring a broken integration is a fix; adding a new recipient rule is an enhancement. This boundary is written into the retainer explicitly, because it is where maintenance agreements most often go wrong for both sides.
A platform shipped a breaking change. Is that covered?
Adapting to it is included, drawn from the monthly hours. If the adaptation amounts to rebuilding the integration, it is quoted as a Change Order instead — and we will tell you which it is, with an estimate, before starting rather than after.
Do you maintain automations you did not build?
Sometimes. It depends on whether the existing build is documented and comprehensible. We will review it first and give you an honest answer: taking over an undocumented system nobody understands is often more expensive than rebuilding it, and we would rather say that than discover it three months into a retainer.
What happens if we cancel?
On notice, and once invoices are settled, you get current exports of the supported systems, up-to-date documentation and a list of the credentials we held, then we surrender or delete our access. Nothing is held hostage. Handover work beyond that is chargeable, which is stated up front.
Describe the process, get an honest read
Thirty minutes, no obligation, and a written quotation if it is worth doing. Repomanta Information Technology Services issues every engagement in writing.