How to Write an AI Automation Requirements Document: Six Key Sections

Why Most AI Automation Projects Begin with Disappointment

Many companies kick off AI automation projects by describing their needs verbally in a single meeting, and the vendor "generously" fills in the blanks based on their own interpretation. Three months later, the system goes live, but no one is satisfied—and it seems no one is clearly at fault.

The root of the problem: between "we want to automate this" and "a system that actually works," there is a missing written requirements document. Most teams have never written one.

A good requirements document only needs to be one page. The following six sections each have their reason for existing.

Section 1: Describe the Task as a Task

Don't write "use AI to improve customer service." Write out the specific thing, as if you were explaining it to a new hire on their first day.

When an order status inquiry email comes in, find the order in Shopify, check whether it has shipped, and reply with the tracking link. If the order is more than thirty days old, or the customer is asking about a refund, do not reply—flag it for Ana.

This paragraph is worth more than a page of goal statements. It contains the trigger, the systems involved, the action to take, and the boundary conditions. A vendor can quote based on this.

The key difference: a vague vision statement gives the vendor enormous room for interpretation, while a specific task description pulls both parties to the same verifiable starting point.

Section 2: Volume and Time Requirements

How many times per day? What are the speed requirements? Nine hundred times a month with a four-hour tolerance for delay is a completely different system from thirty times a day that must go out within two minutes—and the price is completely different too.

Teams often omit this, then are surprised by the quote. Volume determines architectural choices—high throughput allows batch processing, while low latency demands real-time response. Stating these parameters upfront avoids disputes later when performance falls short.

Batch processing vs. real-time response are two fundamentally different processing modes in automation architecture. Batch processing means the system handles a batch of tasks on a fixed cycle (such as hourly or daily), suitable for scenarios that are not latency-sensitive but have high throughput—for example, nine hundred queries per month with a four-hour delay tolerance. This mode is simpler to implement and lower in cost, but cannot meet immediacy requirements.

Real-time response requires the system to complete processing within seconds or minutes of a triggered event, typically requiring event-driven architecture, always-on services, or message queues—all of which carry higher engineering complexity and operational costs. A scenario of thirty times a day that must go out within two minutes must adopt a real-time approach.

Volume and time tolerance therefore directly determine architecture selection and pricing. If the requirements document does not specify these two parameters, the vendor can only guess—and the guess tends to favor the solution they are most familiar with, ultimately leading to performance shortfalls or cost overruns.

Section 3: Three Things That Must Never Be Decided Alone

This is the key section that distinguishes a requirements document from a wish list. Explicitly write out the operations the automation is forbidden to perform on its own: issuing refunds, promising delivery dates, contacting customers who have already complained, changing prices.

Any operation involving money, making commitments to customers, or carrying legal binding force should appear on this list. If the vendor does not proactively ask about these boundaries, they most likely will not build these limits into the deliverable.

This is not a technical issue—it is a governance issue. An automation system without boundaries is essentially handing amplified risk to a machine to execute.

Section 4: Where the Data Is and Who Can Authorize Access

Write the system names, and write who has the authority to provide access keys. This one line prevents the most common delay in the entire process—not a technical problem, but a project stalling for two weeks because no one knows who owns the API credentials.

If the data is in PDFs, specify whether they are native documents or scanned images, because the latter is a fundamentally different problem. Scanned files require OCR processing, format tolerance, and higher validation costs. Stating this upfront allows the vendor to factor this workload into their quote.

OCR (Optical Character Recognition) is the technology that converts text in scanned images or photos into editable, searchable text. Unlike native PDFs (where text is stored directly as character encoding), scanned files are essentially images and must go through OCR before content can be extracted.

In automation projects, this means additional engineering burden: OCR can make errors due to skewed images, low resolution, handwriting, or complex layouts, requiring format cleaning, field validation, and human review steps. Native PDFs can be parsed directly for text and table structures, while scanned files involve a longer processing chain and higher error rates. If a vendor does not know whether the data is native or scanned, they will often underestimate the workload, leading to later price increases or reduced delivery quality. Stating the physical form of the data upfront is an important step in controlling project cost and expectations.

Section 5: The Definition of "Working" Must Be Testable

Don't write "runs well." Write something checkable:

Out of one hundred real emails from last month, it should handle at least eighty autonomously, and all unhandled items should appear in Ana's queue with a reason attached.

This gives you an acceptance test, and both parties know what "done" looks like. Without it, you get an argument about whether it's finished.

A testable acceptance criterion has another hidden benefit: it forces the requester to clarify their own expectations before the project begins, rather than expressing dissatisfaction only after delivery.

Section 6: Who Is Responsible for Handling Exceptions

Designate one person. Every automation system produces cases it does not handle. If no one is responsible for that queue, the work has simply been moved, not eliminated. This is the most common way a technically successful automation fails commercially.

The human cost of exception handling is often underestimated. An automation system that handles 80% of cases means the remaining 20% requires human intervention—if there is no clear owner, that work scatters across the team, ultimately causing overall efficiency to go down rather than up.

An exception queue is a to-do list in an automation system that collects cases that cannot be handled automatically. Every automation system has its capability boundaries—for example, orders older than thirty days, customers asking about refunds, abnormal data formats—and these situations are flagged by the system and moved to the exception queue to await human intervention.

Key design points for an exception queue include: each case must come with a reason note (such as "overdue order" or "refund inquiry") so a human can quickly assess it; the queue must have a clearly designated owner, otherwise cases pile up or scatter. If no one is responsible for the queue, automation merely shifts work from one person to another, or even increases the overall burden due to unclear handoffs. A system that handles 80% of cases, with the remaining 20% unmanaged, will have its efficiency gains canceled out—or even reversed. Therefore, the owner of the exception queue must be specified in the requirements document, along with corresponding handling time limits and escalation mechanisms.

What a Good Vendor Will Do

A good vendor will give a fixed quote, or come back with questions that make the requirements document better. They should not come back asking for a "discovery call to understand the requirements," because you just wrote the requirements down.

They should occasionally also tell you not to build the thing. For a document that scores poorly on volume, or falls entirely into the realm of subjective judgment, a reliable vendor will decline or narrow the scope. If a vendor has never told you that a task is not worth automating, you are dealing with a salesperson, not a technical partner.

The One-Page Template

Six headings, one page:

1. The task, written as instructions to a new employee
2. Volume and time tolerance
3. Three things that must never be decided alone
4. Systems involved, and who can authorize access
5. The definition of "working," written as one testable sentence
6. Who is responsible for exception handling

The value of this template lies in its simplicity. It does not require you to master technical details—only to write clearly what you already know. And the act of writing things clearly often improves the team's understanding of the process more than the automation project itself.