Most automation engagements fail at the handover, not the build. The system works in the demo, the invoice gets paid, and six months later nobody internal can touch it because the credentials live in a contractor’s personal account and the only documentation is a Slack thread. An automation contract checklist exists to stop that, and it has almost nothing to do with the technology. It is about who holds the keys when the relationship ends.
The automation contract checklist, in full
Four things belong in writing before a single workflow ships: credential ownership, documentation, a support window, and IP terms. Leave any one of them to “we’ll sort it out later” and you have signed an automation vendor contract that quietly obligates you to the same vendor forever, regardless of what the invoice says. None of these four items require legal sophistication. They require someone on your side to ask the question before the kickoff call, not after the first outage.
Credentials and documentation are the same problem
Credentials and documentation fail together, because both are about whether the system survives the person who built it. Every API key, service account, webhook secret, and admin login created during the build should be provisioned under credentials your organization owns, not the consultant’s personal tooling account. That sounds obvious and it is routinely ignored, because rotating credentials mid-project is annoying and nobody wants to be the one who asks.
Documentation is the part vendors skip because it takes time they’d rather bill elsewhere. The minimum bar is not a wiki page describing what the system does in general terms. It’s a record of every non-obvious decision: why a schema field is typed the way it is, what the fallback does when an API call fails, which thresholds trigger a human review. If the output of any step is a structured payload passed to another system, that schema is a contract in its own right, and treating it as an interface rather than an incidental detail is what makes the documentation worth reading six months later. A build without this record is not documented, it’s just described.
The support window has to be a clock, not a promise
A support window written as “ongoing support included” is not a support window, it’s a trap. It needs a start date, an end date, and a definition of what counts as a covered issue versus a new feature request. Post launch support should mean: for sixty days after go-live, the vendor fixes anything that behaves differently from what was specified at acceptance, at no additional cost. After that window closes, any further work is a new statement of work, priced and scoped separately. Vendors who want to leave this vague usually want to leave it vague because ambiguity is billable. That’s one of several red flags in an automation pitch worth watching for before the contract is signed, not after.
Acceptance itself needs a test, not a feeling. If you cannot define what “working” means in measurable terms, the support window has no trigger, because nobody can say when the covered period actually started. This is the same discipline behind evaluating an agent before launch rather than after it ships, and it belongs in the contract as an acceptance clause, not just an internal checklist.
IP terms decide who owns what you paid for
Intellectual property automation clauses decide whether you own the thing you funded or merely licensed a right to keep using it. Default contract language from a lot of agencies and freelancers assigns ownership of custom code, prompts, and workflow configurations to the vendor, with you holding a license to use it. That’s a reasonable structure for a product the vendor sells to many clients. It’s an unreasonable structure for a system built specifically for your business, with your data, on your dime.
Source code ownership should transfer to you on final payment, in full, including prompts, orchestration logic, and any configuration that isn’t part of a third-party platform you’re licensing separately (an n8n instance you host is yours; the n8n software itself obviously isn’t). If the vendor built on a reusable internal framework they maintain across clients, that’s worth knowing upfront, because it changes what you’re actually buying: a bespoke system, or a configured instance of someone else’s product.
What happens when you skip all this
Skipping the checklist doesn’t make the engagement cheaper, it just moves the cost to a point where you have less leverage. The missing credentials show up as an emergency when the original contact stops answering emails. The missing documentation shows up as a new vendor quoting a full rebuild because nobody can explain the existing one. The vague support window shows up as a dispute about whether a bug is covered. None of this is a technology risk. It’s a paperwork risk that technology people routinely underprice, because the contract conversation feels like it belongs to someone else’s job. On a project this size, it’s yours.