How to Write an Automation Brief That Gets Results (With Template)

The quality of an automation project correlates almost exactly with the quality of the brief. A vague brief produces an automation that works in the demo but breaks on the first real-world edge case. A specific brief — one that describes the current process step by step, names the exact fields and systems involved, and defines success in measurable terms — produces an automation that does what it's supposed to do.

Writing a good brief isn't complicated. It requires the same discipline as writing a good specification for anything: be specific where specificity matters, name the exceptions, and define what done looks like.

The 6 sections every brief needs

• Current state: describe the process step by step as it runs today, including who does each step
• Trigger: what starts the process? An email, a form submission, a schedule, a database event?
• Systems involved: list every tool the process touches, including what data goes in and comes out
• Edge cases: what are the exceptions to the normal path? How should the automation handle them?
• Success metrics: how will you know the automation is working? What does the outcome look like?
• Error handling: what should happen when something goes wrong? Who gets notified? What's the fallback?

The edge case problem

The most common failure in automation briefs is treating the main path as if it's the only path. In reality, most processes have 3–7 meaningful edge cases that affect 15–30% of volume. An invoice from a new vendor not in the approved list. A form submission with a missing required field. A customer record that exists in two systems with conflicting data.

“The edge cases aren't edge cases to the people who encounter them. They're the main path for those specific situations. Design for them deliberately.”

Example: a brief for invoice processing automation

Trigger: invoice arrives as PDF attachment to ap@company.com. Current state: finance team member downloads PDF, opens ERP, creates new payable, enters vendor name, invoice number, amount, line items, due date, and GL codes. Approves if under £2,000, escalates to finance manager above that. Systems: Gmail (source), ERP (destination, Xero API). Edge cases: (1) vendor not in Xero — flag for manual vendor creation; (2) amount more than 20% above last invoice from same vendor — flag for review; (3) PDF not parseable — alert finance with original attachment. Success: 80% of invoices processed without human data entry, zero missed payment deadlines.

Notice what this brief has that most don't: specific field names, specific systems, a specific error threshold, specific success criteria. A developer can build to this. A brief that says 'automate our invoice process' cannot be built to — it can only be guessed at.