How to price ongoing automation maintenance.

The build is quoted, delivered and paid for. Three weeks later the client emails because a workflow stopped overnight, and nobody agreed in advance who fixes that or what it costs. Most agencies absorb the first few of these, then quietly resent them, then eventually have an awkward conversation.

Maintenance is a separate commercial product from the build, and it prices differently because you are selling availability rather than output. Here is how to structure it.

Separate the three things clients lump together.

“Support” usually means three distinct commitments with very different costs. Price them separately or you will end up giving two of them away.

Keeping it running is monitoring, responding when something breaks, and fixing failures caused by the integration itself. This is the actual retainer.

Absorbing external change is reacting when a vendor deprecates an endpoint, rotates an auth method or changes a payload. You do not control the timing and it can arrive as a week of work with no notice.

Changing what it does is new fields, new routing rules, an extra system. This is project work and should be quoted as project work every time, even when it is small.

Clients hear all three as “support”. Writing the distinction into the agreement is the single highest-value thing you can do here.

Price the retainer against response, not hours.

Hourly maintenance retainers create a bad incentive on both sides: the client counts the hours they did not use, and you feel obliged to invent work to justify the invoice.

Price against a response commitment instead. What the client is buying is that somebody looks, and looks quickly, when something breaks. A workable structure has three components.

Component	What it covers	How to price it
Monitoring	Alerting, heartbeat checks, someone receiving them	Fixed monthly, small
Response	A stated time to acknowledge and begin work on a failure	Fixed monthly, scaled to the promised speed
Included remediation	A capped number of hours for fixing breakages	Fixed monthly, with overflow at a stated rate

The response tier is where the real variation sits. Next business day is a very different product from four hours, and four hours on weekends is different again. Do not offer a speed you are not staffed to meet, because the first time you miss it the retainer is worth less than nothing.

Work out the floor before you name a number.

A retainer that does not cover the cost of paying attention is worse than no retainer, because it obliges you without funding you.

The floor is the sum of what you spend regardless of whether anything breaks: hosting if you run the infrastructure, monitoring tooling, the time somebody spends reviewing alerts and run history, and the cost of holding capacity available for the response time you promised. Add the expected remediation work, which you can only estimate honestly after a few months of running the system.

Below that floor, decline. It is entirely reasonable to tell a client that a workflow this small does not justify a retainer, and to offer time-and-materials instead. Turning down a retainer you would lose money on is a stronger commercial position than accepting one.

Say what is excluded, in the agreement.

Exclusions prevent more disputes than inclusions do. The ones worth naming explicitly:

• Changes to what the workflow does, including fields, rules and destinations
• Failures caused by the client changing a connected system without telling you
• Vendor deprecations that require substantial rebuilding, which are quoted separately
• Data cleanup on records that were already wrong before the automation existed
• Anything in a system you were never given access to
• Volume materially above the level the system was built and tested for

The vendor deprecation exclusion is the one agencies forget, and it is the one most likely to produce an unfunded week of work.

Handle the third-party change problem honestly.

You cannot prevent a vendor changing an API and you cannot price the unknown. Two workable approaches.

A change allowance

The retainer includes a stated number of hours per quarter for adapting to external change. Unused hours do not roll over. Anything beyond the allowance is quoted. This is predictable for the client and bounded for you.

Quoted on occurrence

The retainer covers monitoring and breakage only, and vendor changes are quoted when they happen. Cheaper monthly, but every incident becomes a commercial conversation at exactly the moment the client wants speed rather than a quote.

The first suits clients who value predictability. The second suits simple integrations against stable vendors. Choose deliberately and say which one applies.

Review the number, on a date.

Set a review point when you sign, typically at six or twelve months, and actually use it. By then you have real how many failures occurred, how long they took, how much of the allowance was consumed, whether the volume grew.

That conversation is much easier when it was scheduled at the start than when it is triggered by you feeling underpaid. It also cuts both ways. A system that has run for a year without incident may honestly deserve a lower number, and offering that unprompted buys more goodwill than most marketing does.

What to do when the client will not pay for maintenance.

Some will not, and that is a legitimate choice. Do not respond by providing it informally.

Hand over properly instead: the exported workflow, the documentation, the credential list, the alerting configuration and a written statement that nobody is monitoring it. Point the alerts at the client rather than at you. Then when it breaks in month four, the conversation starts from an agreed position rather than an assumed one.

If you are putting together a maintenance arrangement for a client system and want a second view on what it should cover and what it should cost you to hold, send us the details of what is running. We will tell you where the recurring cost actually sits. Describe it here.