Most businesses start with the wrong question: “Which tool should we buy?” The better question comes first: which task repeats often enough, and clearly enough, for a machine to handle it without creating more work than it removes? This method gets you an answer in five working days, using a spreadsheet and your team. We will follow one fictional example from start to finish.

Days 1 to 3: keep a log

For three days, everyone who does repetitive work writes down what they do, when they do it. Don’t rely on memory: people forget the small five-minute tasks, and those are often the ones that pile up. Describe a specific action with a verb. “Copy a request into the tracking sheet” is usable; “handle admin” is not.

Involve the people who actually do the work. BDC recommends this for process mapping: they know what isn’t working, and taking part makes them more likely to get on board. For time, use a stopwatch on three to five real cases instead of guessing.

Task log (one entry per task)

Task (verb + object):
Who does it:
Trigger (what starts it):
Number of times this week:
Time per occurrence (timed on 3 to 5 cases):
Tools involved (email, form, spreadsheet, software):
Information needed:
Expected result (how you know it was done right):
Exceptions seen:
Impact of a mistake (low, annoying, serious):
Notes:

Fictional exampleA 12-person renovation company

A fictional renovation company in the Maritimes receives quote requests by email, by phone and through a form on its website. Julie, the office administrator (a fictional character), copies each request into a shared spreadsheet and then lets the estimator know. After three days, the team has logged 14 repetitive tasks. Four keep coming back: copying web form requests, sorting request emails, following up with clients who haven’t answered a quote, and pricing quotes.

Day 4: score each task

Give each task 0 to 2 points on six criteria. The grid isn’t looking for the task that would save the most time on paper. It is looking for the one most likely to work the first time. The thresholds are starting points, so adjust them to your business.

Scoring grid: 0, 1 or 2 points per criterion
Criterion0 points1 point2 points
FrequencyLess than weeklyEvery weekEvery day
VolumeUnder 1 hour a week1 to 3 hours a weekOver 3 hours a week
Stable rulesDifferent every timeA few known exceptionsAlways the same steps
Accessible dataPaper or memoryDigital but scatteredIn one tool, same format
Easy to checkNeeds an expertA few minutes to reviewA glance is enough
Reversible, low riskCostly or client-facing errorAnnoying but fixableNo real consequence

Add up the points. A score of 10 to 12 makes a good first candidate; 7 to 9 is possible once the process is clarified; 6 or less means not now. One rule overrides the total: a 0 on “stable rules” or “reversible” rules the task out as a first project.

Fictional example: the team’s four tasks
TaskScore /12Decision
Copy web form requests11First candidate
Sort request emails8Later
Follow up on unanswered quotes8Later
Price a quote3Stays human
Fictional exampleWhy the web form wins

Form requests arrive every day, always with the same fields, straight into a digital tool. Julie can tell at a glance whether a row was copied correctly, and a mistake takes seconds to fix. Emails are written freely, so they lose points on rules and data. Pricing a quote takes the estimator’s judgment, and a mistake is expensive, so it stays with a person.

Fix the process first

A task can score well and still be a poor candidate because the real problem sits earlier in the chain. Automating a messy process gives you a faster messy process that is harder to fix. If you see any of these signs, sort out the process before you look for a tool.

  • Two people describe the same task with different steps.
  • Exceptions happen more often than the normal case.
  • The information lives in notebooks, personal inboxes or one person’s head.
  • Nobody owns the result when something goes wrong.
  • The task mostly makes up for a mistake upstream, such as a form that doesn’t ask the right questions.
  • Nobody can say what a correct result looks like.
Fictional exampleThe real problem with emails

Julie’s log shows that one email request in two means calling the client back to get the address or the type of work. Automating how those emails are sorted wouldn’t fix that. The simplest fix needs no tool at all: reply with a link to the web form, which already asks the right questions.

Measure all of the work

Time saved on the task itself is only part of the picture. Automation adds work of its own: checking results, fixing errors, handling the cases it can’t deal with and making sure it still runs. If you don’t measure those, you are comparing a real process with a promise.

  1. Before: occurrences per week multiplied by the timed duration.
  2. After: review time, plus correction time, plus exceptions handled by hand, plus time spent monitoring the tool.
  3. Quality: errors that reached a client or a colleague, before and after.
Fictional exampleJulie’s math (illustrative numbers)

Before: 25 requests a week at 5 minutes each, or 125 minutes. During the trial: 1 minute of review per request (25 minutes), 3 requests to fix at 5 minutes each (15 minutes) and 10 minutes of monitoring, or 50 minutes. The real saving is about 75 minutes a week, not 125. That is modest but safe, and the team learns to work with automation on a low-risk case.

Day 5: decide

Take your highest-scoring task and run it through the list below. If any answer is “no”, the decision is “not yet”. That isn’t a failure: you now know exactly what to clarify.

Go or not yet?

  • The task scores at least 10, with no 0 on “stable rules” or “reversible”.
  • None of the “fix the process first” signs apply.
  • You can describe the trigger, the inputs and the expected result in three sentences.
  • One person owns the result and the review.
  • The first trial produces a draft or a row to review, and sends nothing to a client.
  • Current time has been measured on at least three real cases.
  • You know how to go back to doing it by hand if the trial fails.
  • The data involved can be used this way, and access is limited to the right people.
Fictional exampleWhat the team decides

The company runs a four-week trial: each web form request creates a row marked “to review” in the spreadsheet, and Julie approves it. Incomplete email requests get a reply with the form link. Phone calls and quote pricing stay with the team.

Notice that no AI is needed here: a simple rule between the form and the spreadsheet does the job. Anthropic, which builds AI models, gives technical teams the same advice: find the simplest solution possible and only add complexity when it is needed.

Try this week

Copy the task log today and hand it to the two or three people who do the most repetitive work. In three days, spend 30 minutes together scoring the tasks with the grid, then run the top one through the “go or not yet” list.

Limits and mistakes to avoid

  • One week of observation won’t reveal monthly or seasonal tasks, such as month-end or the busy season, so list those separately.
  • The grid helps you pick a safe first project, not the most profitable one over time.
  • The grid thresholds are starting points to adjust, not a standard.
  • If the task involves personal information, this method doesn’t replace checking your obligations.

Sources consulted

  1. BDC, “What is process mapping?” ↗Documenting who does what, when and how, and involving the people who do the work every day.checked on September 15, 2026
  2. Anthropic, “Building effective agents” ↗The advice to find the simplest solution possible and only increase complexity when needed.checked on September 15, 2026

Written with the help of AI tools, then checked and edited by Over U. Examples are fictional. This guide is not legal advice.