Defining automation requirements is an art form. Give a computer crappy instructions and it will do crappy things.

Three rules protect you: the 95/5 Rule (build for 95% of common scenarios, explicitly define the 5% exceptions), thinking forwards and backwards (what happens when you need to undo something?), and building with the end in mind (design for where your business will be in 3-10 years, not just tomorrow).

​Automation cares about logic, not emotion, so don't let current overwhelm cloud your design decisions.

In Part 1 of this series, we covered the three components of every automation: trigger, criteria, and outcome. That's the what. This article is about the how, specifically, how to define requirements that don't come back to bite you.

Here's the uncomfortable truth: if you give a computer crappy instructions, the computer is going to do crappy stuff. A bad automation doesn't just fail to help you, it can actively work against you. The computer doesn't question your intent. It simply executes what you told it to execute.

​To avoid those nightmares, I use three rules for defining requirements.

 Automation cares only about logic, not emotion. Don't let current overwhelmed feelings or circumstances cloud your design decisions.

Before diving into the rules, remember: requirements define when, why, and where things happen based on what your data looks like. This also means you need clean data. If your data is messy, your automation will be messy...garbage in, garbage out.

Requirements aren't just about what should happen. They're about what should happen under specific conditions, what should not happen, and what to do when something needs to be undone.


Rule #1: The 95/5 Rule
​
Build your automation for the 95% of common scenarios.

If you find that exceptions occur in multiple 5% segments, meaning you'd need to build five or six different variations to handle all the edge cases, automation might not be the answer for that particular workflow.

​Here's how to apply it:

 Join the Winning Business Vault to get instant access to the full Building Bulletproof Automations mini‑course.

Before finalizing any automation requirement, ask a colleague or team member to poke holes in it. Explain the trigger, criteria, and outcome in plain language. Their questions will reveal the edge cases you've normalized because you're too close to the process.

Building an automation is like painting a bowl of fruit. Every automation I've made is a different bowl of fruit, but the fundamentals: trigger, criteria, outcome...remain the same.

Requirements are where you decide exactly what your bowl of fruit looks like before you pick up a brush.

Get the requirements right, and implementation becomes straightforward. Get them wrong, and no amount of technical skill will save you from the mess.

What's Next:
​
Part 3 of this series covers the final piece: how to test your automation to make sure it's actually bulletproof. I'll share a horror story about a client whose automation was quietly deleting contacts for a year, and the testing approach that would have caught it.

Q: What if my process has more than 5% exceptions?

A: That's a signal that automation might not be the right solution—at least not a single automation. You may need to handle exceptions manually, build separate automations for distinct scenarios, or simplify the underlying process before automating it.

Q: How do I know if I'm building with enough flexibility for the future?

A: Ask: "If we changed [tool/product/team size], would this automation still work or would it break?" If the answer is "it would break," look for ways to reduce hard-coded dependencies.

Q: Should I document my requirements before building?

A: Absolutely. Written requirements—even a simple bullet list of trigger, criteria, outcome, and edge cases—give you something to test against and help others understand what the automation is supposed to do.

Q: What's the difference between hard-coded and flexible automation logic?

A: Hard-coded logic is specific to current conditions (specific product names, specific team members, specific field values). Flexible logic uses variables, categories, or rules that can adapt as those conditions change.

Q: When should I bring in a specialist versus building it myself?

​A: If the automation touches revenue (deals, billing, contracts), customer data, or multiple systems, consult someone who's seen similar setups across industries. The cost of getting it wrong usually exceeds the cost of getting help.