When people talk about starting with AI, the conversation usually jumps to the exciting part.
An agent. A company-wide copilot. A new customer experience. A system that connects everything to everything else.
Maybe some of those things will be useful one day. I’m not against them. But they are usually a strange place to begin.
I would start somewhere much less exciting: with the work people quietly hate doing.
The weekly report that is assembled by hand. The same customer question answered from memory. The email that has to be forwarded because one system does not talk to another. The document that exists somewhere, but nobody can find when they need it.
This is where the opportunity is often easier to see. People are already paying for the problem through wasted time, delays, mistakes, frustration, or constant interruptions. You do not have to invent a benefit. You have to understand the cost that is already there.
There is an important qualification, though.
Not every task people dislike should be automated.
Some tasks involve sensitive information. Some look repetitive but actually depend on judgment. Some are symptoms of a badly designed process, and automation would only make the mess harder to see. Some are human interactions that should become easier, not disappear.
The aim is not to automate every complaint. It is to find one real piece of work where a sensible, bounded improvement might be possible.
Start by looking at the work
Before choosing a tool, I would ask three fairly ordinary questions.
What actually happens today?
This does not need to become a large process-mapping exercise. Start by asking someone to talk you through the work from beginning to end.
What starts it? What information is needed? Where does it go next? Where does somebody have to copy and paste something? What happens when the normal case is not the actual case? Who makes the final decision?
Even a rough description can expose things that are easy to miss when the conversation stays at the level of “we need to do something with AI”.
The problem may not be a lack of AI at all. It may be unclear ownership, missing information, duplicate approval, or a document nobody trusts. A tool can make a clear process faster. It can also make an unclear process even harder to understand.
What would better actually mean?
“Save time” is a useful starting point, but it is not enough on its own.
Maybe better means fewer errors. Maybe it means faster responses, more consistent service, easier access to information, or better visibility for the person making a decision.
If a process saves twenty minutes but creates more checking and rework, the work has not really disappeared. It has just moved somewhere else.
Before testing anything, write down what happens today and what you would like to improve. The measure does not need to be perfect. It does need to be meaningful enough to stop you confusing activity with progress.
What still needs a person?
This is the question that often gets added too late.
Some parts of a workflow should not be delegated completely. That might include sensitive information, unusual circumstances, customer empathy, professional judgment, or accountability for an important outcome.
“Human in the loop” is not a magic phrase that makes a system responsible. The person reviewing the result needs enough context to judge it, enough authority to change or reject it, and enough time to do the job properly.
If someone is expected to approve a stream of AI-generated outputs in a few seconds, without the information needed to assess them, the human review is probably theatre.
Try one small part first
Once you understand the workflow, the temptation is to rebuild everything. Try not to.
Choose one bounded slice: one type of document, one internal request, one recurring report, or one category of customer question.
Use representative examples, not only the clean cases that make a demo look good. Give one person responsibility for the outcome. Keep a simple baseline. Decide what better means and what would make you stop.
The purpose of the first experiment is not to prove that AI is transformative.
It is to learn whether this workflow, with this information, for these people, can be improved without creating a bigger problem.
That is useful learning even when the answer is no.
Maybe the data is not ready. Maybe the exceptions are too important. Maybe the process is too ambiguous. Maybe reviewing the output costs more than doing the original work. Or maybe the task was never a good candidate in the first place.
Those are all useful findings. They are also much cheaper to discover with a small experiment than after a large implementation programme.
A demo is not the same as a result
A demo asks, “Can the system produce an impressive output?”
A useful experiment asks different questions:
- Did the workflow improve?
- Did the people doing the work benefit?
- Did quality stay the same or improve?
- Did new risks or failure modes appear?
- Is the result worth the cost of operating and reviewing the system?
The second set of questions is less exciting. It is also much closer to the truth.
AI is not valuable simply because it is available. It is valuable when it helps people do meaningful work better, while the risks are understood and accountability is still visible.
So, if your team is discussing a large AI initiative, look for the smaller task underneath it.
What work do people quietly hate?
What would better mean?
What is the smallest safe experiment that could teach you something?
That is probably where the useful work begins.
If you already have a workflow in mind, reply and tell me about the process, not the tool you think you need. I’m more interested in where the friction actually lives.