2 tables · 10 columns
Workflow process map template
One row per handoff: who does it, what goes in and out, the system, touch time and wait time.
AI project requirements template and SOW checklist
This AI project requirements template doubles as a statement of work checklist. It covers outcome, workflow, data, quality thresholds, security, delivery terms and support. It is for the buyer writing a brief, or reviewing a vendor's proposal. Fill in each item, mark the gaps, and settle them before anyone signs.
At a glance
- Format
- 1 table · 35 items
- Best for
- Buyers writing a brief for an AI project, or checking a vendor's proposal
- Copy as
- CSV, tab-separated for Sheets, or Markdown
- Last updated
- October 16, 2026
The template
Work down the list and write an answer for every item, or mark it open. Use the vendor security questionnaire for section 5.
AI project requirements template and SOW checklist
Free to copy. No email and no download.
- Project
- Short name.
- Business owner
- Signs off scope and acceptance.
- Vendor
- Leave blank while you are writing the brief.
- Version and date
- Brief v1, then each revision.
Requirements and SOW checklist
Fill inWrite your answer for each item. An item you cannot answer yet is a finding, so write "open" and an owner.
| ID | Item | What to write down | Often missed | Your answerOr "open" with an owner. |
|---|---|---|---|---|
| 1. Outcome and scope | ||||
| 1.1 | Problem and workflow | The workflow in one sentence, who runs it today and what goes wrong. | Scope written as a technology ("build an agent") instead of an outcome. | |
| 1.2 | Success measures and baseline | Two to four measures, each with today's number and how it was measured. | A target with no baseline, so nobody can show improvement. | |
| 1.3 | In scope | Document types, channels, entities, languages and regions. | Edge cases that one side assumes are included. | |
| 1.4 | Out of scope | What is explicitly excluded, including later phases. | Silence, which turns into change requests. | |
| 1.5 | Users and owners | Who uses it, who owns it after launch and who signs off. | No named business owner after go-live. | |
| 2. Workflow and decisions | ||||
| 2.1 | Steps the system performs | Each step with its trigger and output. Attach the process map. | Steps people do today that nobody wrote down. | |
| 2.2 | Decisions it makes alone | Rules, thresholds and limits it can apply without a person. | Limits expressed as intentions, not numbers. | |
| 2.3 | Approvals and who gives them | Actions that wait for a named approver, and the time limit. | No backup approver for leave or sickness. | |
| 2.4 | Exceptions and fallback | Where unsure cases go, and what happens if the system is down. | No manual fallback for the day it fails. | |
| 2.5 | Actions it must never take | For example, changing bank details, deleting records or messaging customers without review. | A prohibition left to the prompt, not to permissions. | |
| 3. Data and systems | ||||
| 3.1 | Systems to connect | Each system, read or write, the access method and who grants it by when. | Access requests that take longer than the build. | |
| 3.2 | Data sources and quality | Where inputs come from, formats, volumes and known problems. | Volumes quoted as averages, with no peaks. | |
| 3.3 | Test and production environments | Whether a sandbox exists for each system. | Testing against production data by default. | |
| 3.4 | Sensitive data | Personal, financial or health data, and what must be masked or kept out. | Fields discovered late in the pilot. | |
| 3.5 | Past cases for testing | How many, from where and who labels the correct outcome. | Nobody owns labeling, so it waits. | |
| 4. Quality and acceptance | ||||
| 4.1 | Test set | Who builds it, from what, and how much is held back. | A test set made by the vendor from clean examples. | |
| 4.2 | Pass bar | Thresholds per field or decision, agreed before the pilot starts. | One blended accuracy figure that hides the costly errors. | |
| 4.3 | Pilot design | Shadow mode or live, duration, volume and who reviews the output. | A pilot too short to see the month-end peak. | |
| 4.4 | Acceptance criteria | What the customer signs to accept each milestone. | Acceptance by "looks good". | |
| 4.5 | Re-test triggers | Changes that require rerunning the tests, such as a new model version. | Silent model upgrades. | |
| 5. Security and compliance | ||||
| 5.1 | Hosting and data region | Where the system runs and where data is stored, by component. | Backups and logs in another region. | |
| 5.2 | Model providers and data handling | Which providers, what they retain, and whether anything trains on your data. | Provider terms that changed after signing. | |
| 5.3 | Access control and audit log | Who can see data, how access is reviewed and what is logged. | Logs the customer cannot export. | |
| 5.4 | Laws and policies that apply | Privacy, sector rules and your own policies, named for each region. | Assuming the vendor knows your sector's rules. | |
| 5.5 | Security review | The questionnaire and evidence you require before go-live. | Starting the review after the contract is signed. | |
| 6. Delivery and commercial terms | ||||
| 6.1 | Milestones and deliverables | Each deliverable and date, such as process map, prototype, pilot, go-live and runbooks. | Deliverables described as activities, not outputs. | |
| 6.2 | Customer responsibilities | Access, subject-matter experts, test data and decisions, each with a date. | Vendor delays blamed on late customer inputs. | |
| 6.3 | Change control | How a change is requested, estimated and approved. | No rule for what counts as a change. | |
| 6.4 | Fee structure | Fixed, time and materials or retainer, what triggers each payment and what is included. | Payment tied to dates rather than accepted milestones. | |
| 6.5 | Running costs | Model usage, hosting and licenses, who pays, and any cap or alert. | Usage-based costs with no ceiling. | |
| 6.6 | Ownership and exit | Who owns workflows, prompts, code and data, and what handover looks like. | Exit terms agreed only at exit. | |
| 7. Run and support | ||||
| 7.1 | Monitoring | What is tracked, how often and who sees the report. | Monitoring that stops after the pilot. | |
| 7.2 | Support and response | Hours, channels, severity levels and response targets. | A severity scale with no response times. | |
| 7.3 | Maintenance and updates | Who handles model, API and system changes. | Nobody owns the third-party API change. | |
| 7.4 | Review cadence | How often quality, exceptions and costs are reviewed, and by whom. | A review that happens only when something breaks. | |
Scroll sideways to see every column.
How to fill it in
6 steps, in the order that saves rework.
- 1
Start with section 1 and write the outcome as a workflow
Describe the work the system takes over. "Read, match and route supplier invoices" gives a vendor something to price, and "build an AI agent" does not.
- 2
Attach your process map and test cases
Add the workflow map and a sample of real past cases to section 2 and section 4. They turn a vague brief into something a vendor can scope and you can test.
- 3
Put numbers on the pass bar before the pilot
Write thresholds per field or decision, and say which errors are never acceptable. A threshold agreed after the results arrive is a negotiation.
- 4
Name who approves what
Fill section 2.3 with named roles and time limits. The system's autonomy is only as clear as this list.
- 5
Mark every open item with an owner
An unanswered item is not a failure of the brief. It tells you which discussions must happen before a signature.
- 6
Have your counsel review the final document
This is a checklist of what to settle. Liability, intellectual property and data protection terms belong in a contract that your lawyer has read.
A worked example
A made-up case, so you can see what a filled-in version looks like. None of the numbers are real.
Illustrative
Five filled items for an invoice workflow
Illustrative. The numbers and limits below are made up for the example.
| ID | Item | Example answer |
|---|---|---|
| 1.1 | Problem and workflow | Supplier invoices arrive by email, are keyed into the ERP by two clerks and wait for approval. We want them read, matched and routed without keying. |
| 1.2 | Success measures and baseline | Touch time per invoice (6 minutes today, from a timed sample of 40), share needing rework (about one in eight today), days from receipt to posting (4 today). |
| 2.2 | Decisions it makes alone | May post an invoice that matches its purchase order within 2% on price and quantity. Anything else goes to a person. |
| 4.2 | Pass bar | Supplier, invoice number, date and total correct on at least 98% of the test set. Any wrong bank detail counts as a failed run. |
| 6.5 | Running costs | Model usage billed at cost to the customer's own cloud account, with a monthly cap and an alert at 80% of it. |
Scroll sideways to see every column.
How to read it. Each answer can be checked. The measures have a baseline, the decision has a limit and the pass bar names the error that is never acceptable. Anyone could price this or test it, and that is the standard to aim for.
Use it with
- TemplateAI vendor security questionnaireThe evidence to require under section 5.
- TemplateWorkflow process map templateAttach the map to section 2.
- BlogAI implementation roadmapA 90-day plan from first workflow to live.
- BlogAI agent development costWhat to budget to build and run an agent.
- BlogBuild vs buy AIA decision matrix before you write the brief.
- PageHow a project runs with usAudit, build, pilot and run, with approvals at each stage.
Questions about this template
What goes in an AI project requirements document?
The outcome and scope, the workflow and which decisions the system makes alone, the data and systems it uses, how quality is tested and accepted, security and compliance needs, delivery terms, and who runs and supports it after launch. The checklist above follows that order.
What is a statement of work for an AI project?
The part of a contract that sets scope, deliverables, schedule, acceptance criteria and fees. For AI it also needs test thresholds on your data, access to your systems, where models run and what happens to the system after launch.
Should an AI project be fixed price?
It can be, when the scope is clear and the pilot thresholds are agreed. Where the data is unknown, split the work: a paid assessment first, then a fixed-price build. That is how we run projects, with a workflow audit first and a written proposal after it.
How do I write acceptance criteria for an AI system?
Use thresholds on a test set made from your own past cases, set before the pilot, and name the errors that are never acceptable. Add the approval gates that must work, and say whether the pilot runs in shadow mode or live.
Is this a legal template?
No. It is a list of what to settle before you sign. Terms on liability, intellectual property, data protection and termination belong in a contract that your own counsel reviews.
More free templates
All 6 templates3 tables · 12 columns
Automation opportunity scoring template
Score each candidate workflow on five criteria, weigh it against hours spent, and pick the first pilot.
3 tables · 8 columns
RAG evaluation test set template
Questions, gold answers, sources and expected behavior, plus a run log for every release.
1 table · 9 columns
Month-end close task inventory template
A master list of every close task with owner, reviewer, due day, evidence and automation fit.
40 questions · 7 columns
AI vendor security questionnaire
Forty neutral questions to ask any AI vendor, on data, models, approvals, logging, testing and exit.
Bring your draft brief. We will tell you what is missing.
A 30-minute call with an engineer. You will leave knowing what a system could do for that workflow and what it would take to build.
What happens next
- 1
Strategy call
We learn how the workflow runs today and what a good outcome would be.
- 2
Workflow audit
We map the process and measure where a system would save the most time.
- 3
Proposal
A written scope, timeline and fixed price for your first system. No obligation to build.