How to Write an Automation Requirements Doc (With Template)

A practical field guide from Automation Ace.

The short answer

An automation requirements doc is a one-page spec that a client (or business owner) and a builder both sign before work starts. It covers the trigger, inputs, step-by-step business rules, outputs, edge cases, non-functional needs like alerts and security, named owners, and a checklist that defines “done.” It turns a vague request into something testable, and it is the single best way to prevent scope creep and “that is not what I meant.”

Part of the automation planning playbook. Write it after process mapping and the exception inventory.

The one-page template

AUTOMATION REQUIREMENTS DOC (one page)

1. Summary
   Name: ____________________   Business owner: ____________   Builder: ____________
   Purpose (one sentence): ____________________________________________________

2. Trigger
   What starts it: ____________   System: ____________   Expected volume: ____/day
   Instant or scheduled? ____________   Duplicate trigger handling: ____________

3. Inputs
   Field | Source system | Required? | Format / example | If missing...
   ______|_______________|___________|__________________|_______________

4. Steps and business rules
   1. ______________________________________________________________
   2. ______________________________________________________________
   Rule: IF ____________ THEN ____________ ELSE ____________

5. Outputs
   What is created/updated/sent | Where | Who sees it

6. Edge cases and exceptions
   Scenario | Expected behavior | Automated or routed to a person?

7. Non-functional requirements
   Speed: ________  Error alerts go to: ________  Logging: ________
   Security/privacy notes: ______________________________________

8. Owners
   Business owner: ________   Technical owner: ________   Backup: ________

9. Definition of done (acceptance criteria)
   [ ] Happy path works for __ real test records
   [ ] Each listed edge case behaves as specified
   [ ] Alerts reach the named person on failure
   [ ] Documentation and runbook saved at: ________
   [ ] Baseline captured; success metric: ________

10. Sign-off
   Business owner: ________ Date: ____   Builder: ________ Date: ____

Section-by-section guidance

• Trigger: be specific: “new deal moved to Closed Won in HubSpot,” not “when we win a deal.” Note whether it is instant or polling and how duplicates are handled. See event-driven vs scheduled automations.
• Inputs: list every field, its source, format, and what happens when it is blank. See blank and missing values.
• Business rules: write them as IF/THEN/ELSE statements. If the owner cannot, the process is not ready; see the readiness assessment.
• Outputs: what changes in which system, and who is notified.
• Edge cases: pull directly from the exception inventory, with a decision for each: automate or route to a person.
• Non-functional requirements: speed, alerting, logging, and data privacy. See the security checklist.
• Owners: a business owner who decides behavior and a technical owner who maintains it.
• Definition of done: testable checkboxes, not “it works.” Include a baseline metric from defining success metrics.

A filled-in example (abbreviated)

• Trigger: new Typeform submission on “Request a Quote,” about 40 per week.
• Inputs: name, email (required), company, budget range, project details.
• Rules: IF budget is $10k or more, assign to senior rep; ELSE round-robin to the team. IF the email already exists in the CRM, update the contact instead of creating one.
• Outputs: CRM contact and deal created or updated; Slack alert to the assigned rep; confirmation email to the prospect.
• Edge cases: missing company, so use the email domain; spam submission, so filter by honeypot field; rep on vacation, so fall back to team lead.
• Done: 20 test submissions pass; alerts reach ops on failure; runbook saved.

See lead routing automation for the full pattern.

Tips for getting sign-off

• Keep it to one page; link to the process map and exception inventory for detail.
• Use the business owner's language, not tool jargon.
• Show the before-and-after with a current vs future state map.
• Treat changes after sign-off as change requests, with impact on time and cost.
• Store the signed doc with the automation's documentation. See documentation and handoff.

Frequently asked questions

What is an automation requirements document?

A short spec, ideally one page, that defines an automation's trigger, inputs, business rules, outputs, edge cases, non-functional needs, owners, and acceptance criteria, signed by the business owner and the builder.

What should an automation spec include?

Trigger, inputs with sources and formats, step-by-step business rules, outputs, edge cases and how each is handled, alerting and security needs, named owners, and a testable definition of done.

How do I define done for an automation?

Use testable acceptance criteria: the happy path works for a set number of real test records, each edge case behaves as specified, failure alerts reach a named person, documentation is saved, and a baseline metric is captured.

Why do automation projects need sign-off?

Sign-off creates a shared definition of scope and success, prevents misunderstandings and scope creep, and gives a clear basis for change requests.