Start with the work, not the tool.
Don’t start with the most futuristic idea. Start with the place where capable people are losing time to a process that should work better.
When I’m trying to understand how work actually happens, I pay attention to sentences that begin with:
- “Usually, I just…”
- “Then I copy it into…”
- “She knows where that lives.”
- “If he’s out, we wait.”
- “We have a spreadsheet for that somewhere.”
Those aren’t complaints about technology. They’re clues.
I’ve spent years taking projects from discovery and scoping through implementation and launch. The diagram of a process is almost always tidier than the process itself. On paper, an inquiry comes in, someone responds, and the work moves forward. In reality, the inquiry lands in a shared inbox, one person notices it, someone else has the client history, and the next step depends on a Slack message sent at exactly the right moment.
That gap between the official process and the lived one is where good automation opportunities tend to hide.
Ask five questions before choosing a solution.
This sounds obvious. It is also where many automation projects go wrong.
A team sees an impressive AI demonstration and starts hunting for somewhere to use it. Now the goal is “implement AI,” so every problem begins to look like an AI problem. It’s the business version of buying a beautiful sectional before measuring the room.
I would rather begin with one recurring frustration and ask:
- What sets this work in motion?
- What has to happen before it is finished?
- Where does it wait, repeat, or go wrong?
- Which steps require judgment?
- What would be noticeably better if we changed it?
The answer might involve AI or ordinary automation, a better form, a clearer rule, or a feature inside software the company already pays for. That is not a disappointing result. Avoiding an unnecessary tool is a win.
Choose work that happens often.
Saving 20 minutes sounds good, but frequency changes the value. Twenty minutes saved once a quarter is not a meaningful first project. Twenty minutes saved twelve times a week might be.
Frequency also creates enough examples to test. If a workflow happens regularly, you can compare how it works before and after the change without waiting six months for evidence.
Connect the frustration to a real cost.
“This task is annoying” is worth hearing, but it isn’t enough on its own. What does the annoyance cause?
Maybe a customer waits two days for an answer. Maybe a skilled employee spends Friday afternoon copying information into a report. Maybe the owner is still the only person who can approve a routine next step. Maybe missing one handoff means losing a lead.
The strongest first projects connect the frustration to time, delay, errors, capacity, or customer experience.
Give the workflow a clear beginning and end.
“Improve our operations” is not a workflow. Neither is “automate marketing.”
A usable scope sounds more like this:
When a qualified inquiry arrives through the website, assign it to the right person, prepare the relevant context, and create a follow-up task for review.
There is a starting event, an outcome, and a place for a person to check the work. You can draw a boundary around it.
Make sure the team understands the process.
You do not need pristine documentation. Honestly, most growing businesses don’t have it. But the team needs enough shared understanding to say what usually happens and identify the exceptions.
If five people describe five entirely different processes, the first job may be agreeing on the process. Automating confusion only makes it move faster.
Give someone ownership.
This is the least glamorous test and one of the most important.
Every working automation needs a person who notices when something changes, decides how exceptions should be handled, and confirms that the result is still useful. “The system will take care of it” is not ownership.
The owner does not need to be technical. They need to understand the job and have enough authority to keep the workflow current.
Compare your best opportunities.
If you have several candidates, score each from one to five on:
- Frequency
- Time or delay created
- Error or customer risk
- Ease of defining the workflow
- Availability of usable information
- Team willingness to adopt a change
- Effort and cost to implement
Want to do this without a spreadsheet? The free Workflow Finder walks you through scoring your tasks and ranks your top three.
I also add one question that does not fit neatly into a spreadsheet: If this works, will anyone care?
That question matters. A technically elegant automation that removes four minutes from a task nobody minds doing is not a strong first win. A modest change that stops good leads from sitting unanswered might be.
Know what not to automate first.
Some work can be automated and still be a poor place to begin.
I would be cautious with:
- Rare processes with little test data
- Work that changes every week
- High-stakes decisions about employment, credit, healthcare, legal rights, or safety
- Processes nobody can explain consistently
- Projects requiring major data cleanup before any useful result is possible
- Automations that remove the only meaningful human check
- Workflows spanning several systems with unclear access or ownership
That doesn’t mean “never.” It means the first project should help the company learn without creating an expensive new problem.
A practical starting exercise.
Ask three people this question separately:
What task do you do repeatedly that feels harder than it should?
For each answer, write down:
- How often it happens
- Who touches it
- Which tools are involved
- Where information is copied or re-entered
- What people have to remember
- What goes wrong
- What must remain a human decision
Do not debate solutions yet. Map the work first. The pattern usually becomes visible faster than people expect.
Before building, check whether your business is ready to test the workflow.
Make the first improvement repeatable.
Your first project does not need to prove that AI will transform the company. That is too much pressure for one workflow and, frankly, not a useful goal.
It should prove something smaller: that the business can identify a real operational problem, improve it responsibly, measure what changed, and hand the new process to someone who can own it.
Once you can do that once, you have a repeatable way to make the next decision.
Hazel & Helm’s AI Operations Sprint examines three recurring workflows, chooses one practical opportunity, and builds or tests a defined improvement. If you already know the task that keeps getting stuck, tell us what is happening.
Frequently asked questions.
What business process should a growing business automate first?
Choose a recurring, rules-based workflow with a clear beginning and end, a noticeable cost in time or delays, and a person willing to own it. Inquiry routing, recurring reporting, document intake, task creation, and routine follow-up are often stronger starting points than complex decision-making.
Should I automate the most time-consuming process first?
Not automatically. A time-consuming process may also be unstable, high-risk, or too broad for a first project. Balance potential value against implementation effort, data readiness, exceptions, risk, and whether the team will use the result.
Does my first automation need AI?
No. Some problems are better solved with a standard automation, a simpler process, or better use of existing software. Use AI when the work requires tasks such as interpreting, classifying, summarizing, or drafting—not merely because AI is available.
How many workflows should I compare before choosing one?
Three to five is usually enough to compare meaningful options without turning the assessment into a company-wide transformation project. Select one bounded workflow to build or test first.