Most automations that fail were doomed before anyone opened a builder, so run through these ten before you start.
Clarity
A no here means you're not ready to design the thing yet. You'll end up automating the wrong steps, or steps that don't actually repeat.
Can you describe the task you want to automate as the exact steps you do by hand today?
If you can't write the steps down, a tool can't follow them, and it will break the first time reality doesn't match your head.
Does this task happen often enough that automating it is worth the build time?
Automating something you do twice a year costs more than it saves, because automation pays off on repetition.
Can you describe exactly what a successful run looks like?
If you can't picture the finished result, you'll either keep tweaking a workflow that's already working, or ship one that looks done but isn't checking the right thing.
Does this task follow the same steps every time, or does it change often?
Automation is literal, so if the steps change every week you'll rebuild it more often than you ever ran the task by hand.
Access
A no here means you can design it perfectly and still not be able to finish building it. This is where projects stall for weeks waiting on a login.
Do you have admin access to every tool this automation will touch?
A read-only login or a limited seat stops you halfway through, so find out before you design around access you don't have.
Do the tools you want to connect offer a real way in, like an API, a webhook, or a native integration?
If a tool offers no supported connection, no amount of building gets the data out, and you need a different plan.
Do you have the API keys, credentials, and connected accounts gathered before you start building?
It's easy to confirm a key exists and forget to actually go get it. Stopping mid-build to track one down breaks your momentum and usually takes longer than you'd think.
Maintenance
A no here doesn't stop you from building it. It means the thing will fail quietly later, and you won't be the one who catches it.
Do you know who is responsible for this automation once it is running?
An automation with no owner is the one nobody notices when it fails, so name the person now, even if it's you.
Do you have a plan for what happens when it breaks?
It will break eventually, usually when a connected tool changes, so know where to look and how to run it by hand meanwhile.
Will you know if it stops working quietly?
The failure that hurts is the quiet one that stops while you assume it's still running, so build in a way to catch it.
What a no means
A no in Clarity means go define the task more before you touch a builder. A no in Access means go get the login, the key, or the integration sorted before you design around access you don't actually have. A no in Maintenance doesn't block you from starting, but it means you're building something that will eventually fail with nobody watching, so decide now who owns it and how you'll know if it stops.
Three or more no's across the board usually means the idea is right but the timing is early. That's not a bad outcome. Better to know now than after three days of building.
Grab the fillable PDF version to work through the checklist on your own.