Free — No Email Required

The automation checklist.

Ten questions that tell you which of your workflows is worth automating first — and, more usefully, which ones will burn money if you try. This is the same screen we run in a paid audit, minus us.

Ten questions · about six minutes · nothing to sign up for

How to use it: pick one workflow that annoys you — a specific one, not “admin” — and answer for that workflow only. Then run it again for the next one. Comparing two workflows against the same ten questions is what makes the right answer obvious.

Is this workflow even a candidate?

If a workflow fails most of this group, no amount of clever engineering will save it. Move on to the next one.

It repeats on a schedule or a predictable trigger.Every Monday, every new order, every time a form comes in. One-off work has nothing to automate — the value comes from the repetition.
You could write the rules down on one page.Not perfectly, and not every edge case. But if the person doing it can explain their decisions out loud, an agent can follow them. If the answer is "you just get a feel for it", start somewhere else.
The inputs are already digital.Emails, spreadsheets, database records, PDFs, API responses. If step one is someone reading a piece of paper, that is a scanning problem to solve before an automation problem.
It moves information between systems that do not talk.The copy-paste between two tools is the single most common shape this work takes, and usually the fastest win.

Will it actually pay for itself?

This is where most automation projects quietly fail — not technically, but because they automated something that did not matter.

It costs more than three hours a week, measured rather than guessed.Ask the person who does it to time it for one week. The number is almost always higher than management thinks and lower than the person doing it feels. Below about three hours a week, the build rarely returns the effort.
It is landing on someone expensive or someone senior.The same two hours cost very different amounts depending on whose two hours they are — and what that person is not doing instead.
Something real breaks when it is late or wrong.A missed invoice, a customer who waits two days, a number that goes into a decision wrong. Cost of failure is as much of the return as hours saved, and it is the part people forget to count.
The process has been stable for at least a few months.Automating a process that changes every month means rebuilding it every month. Let it settle first, or automate the stable part and leave the rest alone.

Can it be done safely?

Answer these before anyone writes code, not after. Retrofitting safety onto a running agent is expensive and rarely complete.

You know the worst thing it could do if it ran unsupervised.Send a wrong email to a client list. Pay the wrong invoice. Delete a record. Write it down explicitly — that sentence decides which steps need a human approving them and which can run on their own.
You can give it narrow access without handing over the keys.A service account scoped to one folder, one label, one table. If the only way to give access is to share a person’s real login, fix that first — it is a problem whether or not you automate anything.

Reading your answers

8–10 ticked: This is a strong first candidate. A workflow like this is usually live inside two to three weeks and pays back inside a quarter. Start here rather than with the one that is most annoying.
5–7 ticked: Worth doing, but not first. Look at which boxes are empty — unticked boxes in group 2 mean the return is thin, and unticked boxes in group 3 mean there is groundwork to do before it is safe to build.
Under 5 ticked: Leave it alone for now. This is the honest answer nobody selling automation wants to give you, and it is the one that saves the most money. Either the process is not settled enough, or the payoff is not there yet. Pick a different workflow and run the list again.
Any box in group 3 unticked: Treat this as blocking regardless of your total. Not knowing the worst-case action, or not being able to scope access, is how automation projects turn into incidents.

← Back to the site