Maintenance
After the build: what automation maintenance involves
Why an automation needs upkeep after launch, and what Workflow Care covers: monitoring, small fixes, monthly review, and current documentation.An automation is software running against systems it does not control. A form-to-CRM workflow depends on the form provider, the CRM, and the email service behaving the way they did on launch day.
When one of them changes, a workflow that ran cleanly for months can start dropping records.
Nobody notices until a lead complains. A build that was correct on launch day can go quietly wrong, and the drift starts in four places.
After launch
Why automations drift.
Four things move after a build ships, and each one breaks the workflow at a different seam.APIs and tools change
A CRM updates a field name, a form platform revises its webhook format, an email provider tightens its sending rules. A workflow built against specific endpoints and data shapes breaks at that exact seam, often silently.
The business's rules change
Routing logic that made sense in January stops matching how the company qualifies leads by June. A new product line needs its own tag, a field that was optional becomes required, and the automation keeps following the January rule, which is now the wrong thing.
New edge cases surface
Live traffic produces the inputs testing cannot imagine: a duplicate submission, a name with characters the CRM rejects, a blank field a validation rule expected to carry a value. These appear only after the workflow meets real data.
Volume grows
A workflow scoped for 40 records a day behaves differently at 400. Rate limits that were never close become the constraint, and the timing gets tight.
Workflow Care
Monitoring comes first, then the fixes that follow.
The point is to catch a break before the client does, then resolve it and keep the workflow current.Workflow Care is the next step after a build lands, and it addresses those four sources of drift directly. Monitoring is the core of it: alerting on failed runs and on the quieter failures, such as a workflow that completes but processes zero records when it should have handled several. The alert goes to a chat channel the business already watches, so a failure surfaces without anyone thinking to check on it.
Once monitoring surfaces a break, the rest of the retainer resolves it and keeps the workflow current. The monthly review catches a rule change before it produces weeks of quietly wrong output.
Small fixes
Reconnecting an integration after a tool update, adjusting a step an API change knocked over, and patching a newly discovered edge case.
Monthly review
A look at what actually ran: its volume, error rates, the steps that failed and recovered, and whether the workflow still matches how the business works now.
Minor improvements
A new tag, a tightened validation rule, or a small extension that keeps the workflow current without a fresh build.
Priority support
A break in a workflow the business depends on gets attention ahead of the queue.
Current documentation
Each fix updates the process map and the notes on what connects to what, because notes describing last quarter's workflow send the next fix in the wrong direction.
Scoping upkeep
How maintenance gets priced.
A single report and a multi-tool build carry very different upkeep.A single report
A spreadsheet-to-email summary touches one system and one schedule, so it needs far less attention.
A workflow across several tools
A build spanning a form, a CRM, and three notification channels has more seams that can move, and each one is another place upkeep lands.
The retainer is quoted with the build, because the real upkeep load depends on how many integrations the workflow touches and how often those tools change.
After the build