How to decide which tasks to automate

The decision to automate is mostly arithmetic, and the arithmetic is less generous than it feels. The xkcd comic Is It Worth the Time? works out how long you can spend making a routine task faster before you have spent more time than you save across five years: shaving 5 minutes off a daily task is worth about 6 days of work, and shaving 30 minutes off a weekly task is worth about 5 days. A Zap that takes a day to build and an hour a month to babysit eats most of that budget.

The second filter is repetition. Vivek Rau's chapter on toil in the Google SRE book draws the line bluntly: "If you're performing a task for the first time ever, or even the second time, this work is not toil." A task you have done twice is a task you do not yet understand well enough to automate.

How much time does an automation have to save?

Use the xkcd chart as a budget, not a verdict. Each figure is the total build and maintenance time you can spend before the automation loses time over five years:

How often you do the task	Time saved each time	Time you can spend automating it (five years)
5 times a day	1 minute	6 days
Daily	5 minutes	6 days
Weekly	30 minutes	5 days
Weekly	1 hour	10 days
Monthly	1 hour	2 days

The limit of this math is that it counts only your time. It ignores errors a manual process makes, the speed a customer sees, and the attention cost of a task that interrupts deep work at 9 AM every day. Those can justify an automation the chart says no to. They rarely justify one that fails the next test, though.

Which tasks pass the test?

Score a candidate against five questions before planning anything:

Question	Automate if	Keep manual if
Does it repeat on a schedule or a clear trigger?	Yes, weekly or more	It happens when someone remembers
Can you write the rules down?	A new teammate could follow them	"It depends" is the honest answer
Are the inputs stable?	Same fields, same source every time	Formats change, data arrives by chat message
What does a mistake cost?	An internal note is wrong for an hour	A customer gets a wrong price or a wrong email
Can a mistake be undone?	Delete the row, resend the message	Money moved, contract sent

A task that passes all five is a good candidate. A task that fails the rules question is usually a process problem wearing an automation costume: fix the process by hand first, then automate the fixed version. The toil test in AI for product ops is a useful companion filter for recurring reporting work.

What goes on the planning canvas before you build?

Write four boxes on one page, in this order, and do not open an automation tool until all four are filled.

1. The problem, stated as a cost. Not "automate trial follow-ups" but "customer success misses trial accounts that go quiet, and we find out after they expire." A problem stated as a cost tells you what success looks like and whether the automation worked.

2. The normal cases. Every path the workflow should handle when everything is as expected. Most workflows have two or three, not one.

3. The edge cases. Every input that is technically valid but not normal: missing data, duplicates, records in an unexpected state, people who should be excluded, time zones. For each, decide the behaviour now: skip it, route it to a person, or handle it.

4. The tools, chosen last. Only now pick the trigger source, the tool that moves the data, and where the output lands. Fewer tools is better, since every added app is another connection that can expire or change its fields.

Boxes two and three are where most of the value is. An automation that handles the normal case and ignores the edge cases does not fail loudly. It keeps running and produces wrong output for weeks, and nobody notices until a customer does.

What does a filled-in canvas look like?

Take a B2B product with a 14-day free trial. The customer success lead wants a task created whenever a trial account looks like it is going quiet.

Box	What the team wrote
Problem	CS finds out a trial went quiet only after it expires. Goal: a task for the account owner by day 10 for every trial with low activity.
Normal case 1	Trial on day 10, fewer than 3 active users last week: create a CS task with account name, owner, activity summary.
Normal case 2	Trial on day 10, healthy activity: do nothing.
Edge case	Trial was extended manually by sales: use the new end date, not signup date plus 14.
Edge case	Account already converted to paid on day 8: skip it, even though it is "day 10 of the trial."
Edge case	No account owner assigned: route the task to the CS lead instead of dropping it.
Edge case	Same company signed up twice with two emails: check the company domain and create one task, not two.
Edge case	Activity data missing because tracking failed that day: flag as "unknown," do not treat as low activity.
Tools	Scheduled trigger once a day, CRM as the source of trial dates and owners, analytics tool for activity, task created in the CRM where CS already works.

Five edge cases for a workflow whose normal case fits in one line. The last one matters most: without it, a tracking outage would flood the CS team with false alarms, and within a week they would learn to ignore the tasks entirely. The edge-case list is what makes the automation trustworthy enough to keep.

When should a person stay in the loop?

Keep a person between the automation and anything irreversible or external. In the trial example, the automation creates a task; it does not email the customer. A version that sends a "we noticed you haven't logged in" email directly would be faster, and it would also email the customer whose trial sales extended on the phone yesterday. The human-in-the-loop pattern is the general rule: automate the gathering and the drafting, and let a person approve the send.

The honest counterpoint is that approval steps have a cost too. An approval queue nobody checks is worse than no automation, because work now waits on a person who thinks the machine is handling it. Add approvals only where a mistake is expensive, and give each queue a named owner.

Which tool should you use once the canvas is done?

Match the tool to what the canvas says, not the other way round. A two-step workflow between apps that already have integrations fits Zapier's simplest setup; the comparison in Zapier vs Make for product managers covers when branching and data mapping push you toward Make. For worked examples of what to build first, see Zapier automation ideas for product managers, and for where AI steps fit inside a workflow, see AI workflow automation.

Where to learn to plan and build automations properly

Automate Workflows with AI is a 1 week Builders Camp bootcamp with 2 live sessions, taught by Andre Albuquerque and part of the AI Agentic Builders Expert Track, the Growth Specialist Track and the Product Delivery Specialist Track. Its published topics start with workflow mapping and ROI selection, picking the right tasks to automate and defining success metrics, and cover triggers, actions and error handling so workflows do not silently break, plus human-in-the-loop approvals for high-stakes steps. Its practical challenge asks you to diagnose and repair a support ticket automation that ran for two weeks and produced bad output.

See the Automate Workflows with AI bootcamp