How to write a scope of work for an automation vendor
By Precipitate · 1 November 2026
A scope of work for an automation vendor should define the business process, boundaries, decision rights, acceptance tests, failure handling, and operating ownership. Write it around the work that must happen, not a preferred tool or a vague promise to automate operations.
Start with the operating outcome
Name the process in plain language. Describe what starts it, what should happen, and what marks completion. A useful statement might cover an inbound request from receipt through qualification, assignment, response, and status recording. It should not begin with a product name or a request to add AI.
ScienceDirect's Automation Scope overview defines scope as the business activities selected for automation based on project goals and use cases. It also separates those activities from work that remains outside the project. That boundary matters because most scope disputes begin with an unstated assumption about what the system owns.
Record the current process before describing the new one. Note each system touched, each decision made, and each place where work waits. Our guide to what a good automation discovery phase should uncover explains how to turn daily work into a usable process map.
Define the boundaries with real cases
Write down what enters the system and what does not. For lead handling, the scope might include website forms and a shared inbox while excluding phone calls. For scheduling, it might cover standard appointments but send unusual requests to a person.
Separate normal cases from exceptions. A normal case has enough information, follows known rules, and can move without judgment. An exception has missing data, conflicting records, an unusual request, or a decision with material consequences. The scope should say where each exception goes and what context the person receives.
Do not ask the vendor to automate every variation from the start. Rare cases can consume much of the design effort and create fragile rules. A sound scope identifies the common path, protects the boundary, and records excluded cases for later review.
Specify authority, not just tasks
An automation can draft a message, send it, change a record, issue a refund, or merely recommend an action. Those are different levels of authority. The scope should state which actions happen automatically and which require approval.
Set limits around money, commitments, customer promises, record deletion, and access to sensitive data. A person should retain decisions that depend on context the system cannot observe. The vendor should explain how the system pauses, requests approval, and resumes after the decision.
These limits should exist in the software, not only in a policy document. Our guide to setting limits on what an AI agent can do alone covers permissions, approval gates, and escalation paths in more detail.
Turn expectations into acceptance tests
Words such as accurate, fast, and reliable are too vague for acceptance. Describe test cases with known inputs and expected outcomes. Include ordinary work, missing information, duplicate records, unavailable systems, and requests that fall outside policy.
Acceptance should cover behavior as well as output. Check whether the system writes to the correct record, leaves an audit trail, avoids duplicate actions, and alerts the right person after a failure. Define what evidence the vendor must provide during testing.
Do not demand perfect performance across undefined work. Instead, agree on the cases the system must complete, the cases it must reject safely, and the cases it must escalate. A safe refusal can be a correct result when the system lacks authority or information.
Assign ownership for failures and changes
Automation touches systems that change. Passwords expire, APIs change, fields move, policies are revised, and staff create new workarounds. The scope should identify who monitors failures, who receives alerts, and who has authority to repair each part.
Define incident handling before launch. State how the system stops unsafe actions, preserves evidence, retries temporary failures, and sends unresolved work to a person. The vendor should also explain how completed actions can be reviewed or reversed when reversal is possible.
Change control needs the same clarity. Decide who can request a rule change, who approves it, how it is tested, and when it enters production. Without that process, informal requests can alter important behavior without a clear record.
Separate deployment from operation
A working demonstration is not the same as an operated system. The scope should cover deployment, monitoring, maintenance, access management, incident response, and changes to connected tools. If the vendor leaves after launch, name who assumes each responsibility.
Ask what remains usable if the vendor relationship ends. Clarify ownership of code, configuration, accounts, prompts, process documentation, and operational records. Also identify any platform dependency that could make transfer difficult. These questions belong beside the technical requirements when you evaluate an AI automation vendor.
Commercial terms should follow the accepted scope, authority limits, operational duties, and risk allocation. At Precipitate, we quote each engagement based on the system's business responsibility. We build, deploy, and operate a small number of systems at a time, so operating duties are part of the scope rather than an afterthought.
Check the scope before signing
Read every sentence as an owner who must handle the failure. If the scope says the system will process requests, ask which requests, through which channels, under which rules, and where rejected work goes. Replace broad promises with observable behavior.
Look for silent gaps between the business process and the technical deliverables. A list of integrations does not explain who monitors them. A dashboard does not define who acts on an alert. An AI model does not establish what it may decide.
This week, choose one recurring process and record its trigger, completion state, exceptions, approval points, and current owner. Any missing answer is a scope decision that must be settled before a vendor starts building.
Sources
Want this answered for your own business?
Get a straight answer →