Most businesses have more manual work than they realise.
Some of it is visible. People talk about it in meetings. Someone complains that they are still copying information from one system into another. A manager knows that reporting takes too long. The team has a shared joke about the spreadsheet nobody wants to own.
Some of it is less visible. It sits inside judgement calls, status checks, inbox monitoring, exception handling, reconciliation, and small acts of coordination that happen so often they stop being questioned.
This is where automation conversations often start badly.
The business asks, "What can we automate?"
That sounds sensible, but it is too broad. It encourages a hunt for tasks instead of a diagnosis of drag.
The better question is:
Which manual work is repeated often enough, structured enough, and costly enough that a targeted fix would actually improve how the business runs?
That might involve AI. It might involve a standard integration, a small internal tool, better configuration, cleaner data, or a process change. The point is not to automate for the sake of it. The point is to remove avoidable friction without making the system more fragile.
Start With Drag, Not Tasks
Manual work is not automatically bad.
Some manual work is useful. It adds judgement, care, commercial context, customer sensitivity, or operational control. Removing it too quickly can make the business worse.
The work worth investigating usually has a different pattern. It slows people down without adding much value. It creates errors. It delays handoffs. It makes reporting unreliable. It forces experienced people to spend time on basic checking, copying, chasing, or formatting.
Look for drag rather than just effort.
A task that takes ten minutes once a month may be annoying, but it is probably not a priority. A task that takes five minutes thirty times a day, blocks downstream work, and creates mistakes when someone is busy is a different matter.
The cost is not only the time spent doing the task. It is also the waiting, rework, confusion, duplicated effort, missed follow-up, and management attention it consumes.
Repetition Matters, But So Does Stability
Good automation needs a stable enough pattern.
If the task is repeated, has clear inputs, follows known rules, and produces a predictable output, it is usually a strong candidate. Examples include:
- copying approved data from one system into another
- checking whether required fields are complete before a handoff
- preparing a standard report from known sources
- classifying inbound enquiries by type
- extracting information from structured documents
- routing work based on agreed rules
- flagging records that do not match across systems
- generating a draft response from known context
The important phrase is "agreed rules".
If the business cannot explain how the task should be done, automation will expose that confusion. It may still be useful to improve the process, but the first step is not building an automation. The first step is agreeing the rule, owner, exception path, and source of truth.
Automating uncertainty does not create control.
Follow The Handoffs
The best automation opportunities often sit between systems, teams, or stages of work.
That is where friction hides.
Sales hands something to operations. Operations waits for finance. Finance needs a detail from the CRM. Customer support needs to know what has been promised. A report needs numbers from several places, but nobody trusts the definitions.
These handoffs are easy to underestimate because no single task looks dramatic. One person exports a file. Another checks a column. Someone sends a message. Someone else updates a status. Then a manager asks whether the thing has happened yet.
Individually, these steps are small. Together, they create drag.
When reviewing a workflow, ask where work changes hands. Then ask what information is missing, duplicated, mistrusted, or rekeyed at that point.
If a handoff depends on memory, private notes, Slack nudges, naming conventions, or someone checking three systems before they can act, there is probably an operational design problem. Automation may be part of the fix, but the first useful move is to make the handoff explicit.
Separate AI Work From Workflow Work
AI is useful for some types of manual toil.
It can help when the work involves messy information, repeated judgement, summaries, classification, extraction, drafting, comparison, or pattern spotting.
But AI should not be used to cover up a workflow that has no owner.
If nobody knows what should happen after the AI has classified something, the classification is not the bottleneck. If the source data is inconsistent, an AI summary may simply make weak information look more polished. If there is no review point for a judgement-heavy step, the business may lose control while thinking it has gained efficiency.
The practical version is more contained.
Use AI for the messy part. Wrap it in a workflow with clear inputs, review points, audit trails, and useful outputs. Make sure someone owns exceptions. Keep the source of truth clear.
Check The Failure Mode
Before automating a task, ask what happens when it goes wrong.
Some failures are harmless. A draft needs editing. A tag is wrong and someone corrects it.
Other failures matter. A customer receives the wrong message. A finance record is updated incorrectly. A compliance step is skipped. A team acts on a false status. A manager makes a decision from numbers nobody has checked.
The higher the consequence, the more control the system needs.
That does not mean avoiding automation. It means designing the right level of review, logging, rollback, and human approval.
Low-risk, high-volume toil is often a good place to start. High-risk workflows can still be improved, but the fix may be a controlled internal tool or process redesign rather than a quick automation script.
Choose The Smallest Robust Fix
Once the toil is understood, the answer is often smaller than expected.
Sometimes the fix is a field being made mandatory. Sometimes it is a cleaner handoff checklist. Sometimes it is an integration, scheduled reconciliation, small admin screen, or AI step inside a tightly defined workflow.
The right fix should reduce drag without creating a new maintenance burden that outweighs the benefit.
That is why diagnosis matters.
If the issue is unclear ownership, do not build automation first. If the issue is bad data, fix the data path. If the issue is an exception-heavy process, define the exception handling before writing code. If the issue is repeated judgement over messy information, AI may be worth testing.
A useful operational review does not produce a long wish list of automations.
It produces a ranked view of where the business is losing time, where the root cause sits, and which fixes are worth making.
The best automation opportunities are rarely the flashiest.
They are the repeated pieces of manual toil that quietly slow the business down every day, have stable enough rules to support, and can be improved without adding unnecessary complexity.
Find those, fix them properly, and automation starts to look less like a technology project and more like operational housekeeping with a measurable return.