You finish another week with the same small jobs still taking up space: copying lead details, checking client inputs, updating project statuses. You could automate any of them. Choosing the first one is harder.
I recommend starting with five tasks from the week you just lived through. Twenty minutes is enough to make an initial shortlist and decide what to investigate. Building and validating the automation comes afterward.
The useful question is how much work a change could remove after you account for checking its output and maintaining it. That gives you a better starting point for a small test.
Start with a task you can describe
For the first five minutes, write down five recurring tasks. Keep each one specific enough that somebody else could recognize when it starts and when it ends.
“Client onboarding” is too broad. “Create a project from the approved scope and send the account manager a list of missing inputs” gives you a boundary you can test.
Record how often the task happens and how many minutes a person spends handling it. Use last week’s records if you have them. Otherwise, mark the figures as estimates and check them before building.
Here is an illustrative example for a content agency.
Task | Runs per week | Minutes per run | Weekly handling time |
|---|---|---|---|
Copy new lead details into the CRM | 12 | 8 | 96 min |
Prepare a client onboarding packet | 3 | 30 | 90 min |
Prepare follow-up reminders | 20 | 5 | 100 min |
Update project statuses from completed tasks | 40 | 3 | 120 min |
Assemble client reports | 4 | 45 | 180 min |
This agency has identified 586 minutes of weekly handling time. Those minutes include work that may still need a person’s judgment. They are a baseline for investigation.
Check whether the workflow is ready
Use the next five minutes to look at the inputs and the consequences of a mistake.
Can you find the information the task needs in a consistent place? Do the exceptions follow a recognizable pattern? Would an incorrect output be easy to notice and repair? Who will own the workflow once it is running?
For the status update task, the input might be a completed task in the project system. The output could be an internal status update. If the rule is clear and somebody can review the changes, that may be a manageable first experiment.
The report task takes longer, but its source data might be inconsistent. A draft could also require substantial checking before a client sees it. Put those conditions beside the time estimate so they remain part of the decision.
Anthropic’s guidance on effective agents recommends starting with the simplest solution that meets the need and increasing complexity when it improves the outcome. Applied here, that means checking whether a clear rule and an existing integration can handle the task before adding AI.
Estimate the time you would actually recover
Spend five minutes on the likely workload after the change. Estimate the share of handling time it could remove, then subtract weekly review and maintenance.
For the status updates, suppose the agency estimates that a rule could remove 85% of 120 minutes. That gives 102 minutes before overhead. Allow 20 minutes for checking updates and 15 for upkeep. The estimated net benefit is 67 minutes per week.
For reports, removing 60% of 180 minutes gives 108 minutes. If review takes 50 minutes and maintenance takes 35, the net estimate is 23 minutes per week.
These are planning assumptions. They help explain why the longest task may fall behind a smaller, more predictable one. Record build effort separately as a one-time estimate; it should inform whether the experiment is worth pursuing.
Evidence about AI productivity also needs context. In Generative AI at Work, Brynjolfsson, Li, and Raymond studied 5,172 customer support agents and reported a 15% average increase in issues resolved per hour, with differences across workers. That result concerns a particular support setting. Your workflow still needs its own baseline and test.
Status updates offer a manageable first test: consistent inputs, low variability, and an estimated 67 minutes recovered per week.
Give the first experiment a clear finish
Use the final five minutes to choose one candidate and define its trial.
For this example, the agency could review 20 internal status events before allowing any automatic updates. The proposed acceptance conditions are simple: every event maps to the correct project, no update appears twice, and uncertain cases go to the owner for review.
The accompanying scorecard includes a blank audit, the worked example, and editable estimates for time, effort, and overhead. Use it to compare candidates and choose the first task to test.
Before your next planning meeting, complete five rows. Choose one candidate, assign its owner, and write down what would make its first test acceptable.
Resources
You finish another week with the same small jobs still taking up space: copying lead details, checking client inputs, updating project statuses. You could automate any of them. Choosing the first one is harder.
I recommend starting with five tasks from the week you just lived through. Twenty minutes is enough to make an initial shortlist and decide what to investigate. Building and validating the automation comes afterward.
The useful question is how much work a change could remove after you account for checking its output and maintaining it. That gives you a better starting point for a small test.
Start with a task you can describe
For the first five minutes, write down five recurring tasks. Keep each one specific enough that somebody else could recognize when it starts and when it ends.
“Client onboarding” is too broad. “Create a project from the approved scope and send the account manager a list of missing inputs” gives you a boundary you can test.
Record how often the task happens and how many minutes a person spends handling it. Use last week's records if you have them. Otherwise, mark the figures as estimates and check them before building.
Here is an illustrative example for a content agency.
Copy new lead details into the CRM
Runs per week: 12
Minutes per run: 8
Weekly handling time: 96 min
Prepare a client onboarding packet
Runs per week: 3
Minutes per run: 30
Weekly handling time: 90 min
Prepare follow-up reminders
Runs per week: 20
Minutes per run: 5
Weekly handling time: 100 min
Update project statuses from completed tasks
Runs per week: 40
Minutes per run: 3
Weekly handling time: 120 min
Assemble client reports
Runs per week: 4
Minutes per run: 45
Weekly handling time: 180 min
This agency has identified 586 minutes of weekly handling time. Those minutes include work that may still need a person's judgment. They are a baseline for investigation.
Check whether the workflow is ready
Use the next five minutes to look at the inputs and the consequences of a mistake.
Can you find the information the task needs in a consistent place? Do the exceptions follow a recognizable pattern? Would an incorrect output be easy to notice and repair? Who will own the workflow once it is running?
For the status update task, the input might be a completed task in the project system. The output could be an internal status update. If the rule is clear and somebody can review the changes, that may be a manageable first experiment.
The report task takes longer, but its source data might be inconsistent. A draft could also require substantial checking before a client sees it. Put those conditions beside the time estimate so they remain part of the decision.
Anthropic's guidance on effective agents recommends starting with the simplest solution that meets the need and increasing complexity when it improves the outcome. Applied here, that means checking whether a clear rule and an existing integration can handle the task before adding AI.
Estimate the time you would actually recover
Spend five minutes on the likely workload after the change. Estimate the share of handling time it could remove, then subtract weekly review and maintenance.
For the status updates, suppose the agency estimates that a rule could remove 85% of 120 minutes. That gives 102 minutes before overhead. Allow 20 minutes for checking updates and 15 for upkeep. The estimated net benefit is 67 minutes per week.
For reports, removing 60% of 180 minutes gives 108 minutes. If review takes 50 minutes and maintenance takes 35, the net estimate is 23 minutes per week.
These are planning assumptions. They help explain why the longest task may fall behind a smaller, more predictable one. Record build effort separately as a one-time estimate; it should inform whether the experiment is worth pursuing.
Evidence about AI productivity also needs context. In Generative AI at Work, Brynjolfsson, Li, and Raymond studied 5,172 customer support agents and reported a 15% average increase in issues resolved per hour, with differences across workers. That result concerns a particular support setting. Your workflow still needs its own baseline and test.
Status updates offer a manageable first test: consistent inputs, low variability, and an estimated 67 minutes recovered per week.
Give the first experiment a clear finish
Use the final five minutes to choose one candidate and define its trial.
For this example, the agency could review 20 internal status events before allowing any automatic updates. The proposed acceptance conditions are simple: every event maps to the correct project, no update appears twice, and uncertain cases go to the owner for review.
The accompanying scorecard includes a blank audit, the worked example, and editable estimates for time, effort, and overhead. Use it to compare candidates and choose the first task to test.
Before your next planning meeting, complete five rows. Choose one candidate, assign its owner, and write down what would make its first test acceptable.