Maintenance and support plans for automations: what to include

A support plan for an automation has four items, each with a number: monitoring (who checks the runs and how often), a response time (how quickly a failure reaches a person), a change budget (how many small changes a month and how big each may be), and a monthly note (what ran, what broke, what changed). Everything outside those four is a priced add-on. Written this way, a retainer is a service the client understands, not a vague promise of availability, and it is the reason automations keep working after the build ends.

Why do automations break after the build?

Not because the logic was wrong, but because the world around it moved. A WhatsApp template gets rejected. A CRM changes a field name. An API key expires. A customer sends a message shape nobody saw in testing. Each failure is quiet: no error reaches the owner, leads just stop arriving, and someone notices two weeks later. The support plan is the answer to "who notices first".

Item 1: monitoring

Write down what is watched and how. At minimum: a daily check that the scenario ran and the error count, plus an alert to you when a run fails. In Make and n8n this is built in; wire the alert to your phone or a channel you actually read. State the check window in the plan: "business days, 09:00–18:00".

Item 2: response time

"Failures reported during business hours get a human response within four hours and a fix or workaround the same day" is a promise a client can hold you to and one you can keep. Be specific about hours and days; an automation that sends reminders on Sunday needs a plan for Sunday or a clear statement that it doesn't.

Item 3: change budget

Two small changes a month, each under two hours: a message template, a new field mapped, a threshold adjusted. Beyond that, a written add-on. The budget stops "can you also" from eating the retainer and gives the owner a clear sense of what's included.

Item 4: the monthly note

Five lines, sent on the same day each month: runs handled, failures and what you did, changes made, anything you noticed, what you'd suggest next. This is the most valuable item and the one most builders skip. It shows the owner the retainer working, and it is where the next fixed-price project usually comes from.

What is explicitly extra

Put this table in the plan. Ambiguity here is where relationships sour.

Pricing the plan

Price it from the hours the four items take in a typical month plus the value of the response promise; the pricing guide gives the method. Monthly in advance, cancellable with notice. A plan too cheap to honour will be honoured badly, and the owner will feel it.

Hand-over when there is no plan

Some clients decline any retainer. Then the hand-over must be complete: where everything lives, how to pause it, how to renew credentials, what to do when a failure alert arrives, and who to contact for paid help. Say plainly, in writing, that nobody is monitoring. Many of those clients come back after the first quiet failure.

Best fit and not a good fit

Best fit: any automation that touches customers or money and runs without a person watching. Not a good fit: one-off scripts the client runs by hand; document those and move on.

What to do this week

Write your standard plan on one page with the four items and their numbers, and the included/add-on table. Offer it at the end of your next pilot as a continuation of what the client already saw you do.