Buying an AI tool is not evidence of readiness. Neither is discovering that half the team already has a ChatGPT account.
Readiness belongs to the use case.
“Are we ready for AI?” sounds like a yes-or-no question. It rarely is.
A company may be ready to test AI-assisted meeting summaries and nowhere near ready to let a system make pricing recommendations. It may have excellent product information and a chaotic customer database. One department may have a stable workflow while another is still changing roles every month.
Readiness belongs to the specific use case.
That is good news. You do not have to clean every record, document every process, and settle a five-year technology plan before trying anything useful. You need to choose a reasonable first job and understand what that job requires.
Start with a specific workflow.
“Use AI to become more efficient” gives a team nowhere to begin.
“Reduce the time an account manager spends turning discovery notes into a first project brief” is work you can examine.
A ready use case has:
- A recognizable starting point
- A defined outcome
- People who can describe what happens now
- Enough repetition to test the change
- A reason the improvement matters
If the idea is still “we should have a chatbot,” keep asking what job the chatbot is supposed to perform and for whom.
Involve the people doing the work.
This is where good ideas become usable—or don’t.
Leaders often know where the business feels slow. The employee doing the task knows why. There may be a strange exception, a client preference, a compliance step, or an unofficial workaround keeping the whole thing from breaking.
I learned this repeatedly in digital projects: requirements passed down from a distance sound clean. Once you speak with the person completing the task on an ordinary Tuesday, the edge cases appear.
AI implementation cannot be something done to the team. The people using the workflow need to help map it, test representative examples, identify bad outputs, and say whether the new version genuinely helps.
If nobody has time to participate, the company may have enthusiasm—but it does not yet have implementation capacity.
Know where the information comes from.
AI cannot reliably answer from information your business does not have, cannot access, or no longer trusts.
That does not mean every database must be spotless. The standard is more practical:
- Can we identify the source material this workflow needs?
- Is it current enough for the job?
- Do we have permission to use it?
- Is the information in a format the chosen tools can access?
- Can someone recognize when the source is wrong or incomplete?
For a drafting workflow, the source might be an approved service guide and a set of good examples. For document intake, it may be a consistent group of PDFs. For internal answers, it could be current process documentation.
If the only source of truth is “ask Maria,” your first project may be capturing what Maria knows.
Define what stays human.
“Human in the loop” sounds reassuring and often means almost nothing.
Name the person and the action.
For example:
The system prepares a response using approved service information. The account manager verifies the recommendation, edits the language, and sends it.
That is a control. “A person can review it if needed” is a hope.
Before implementation, decide:
- Which outputs require review?
- Who performs it?
- What are they checking?
- Can they override the result?
- What happens when the system is uncertain?
- Which decisions will the AI never make?
The higher the consequence of an error, the more explicit these answers need to be.
Set boundaries for your data.
Teams often start experimenting before anyone discusses what they are allowed to enter into an AI tool.
At minimum, identify whether the workflow touches:
- Customer or employee personal information
- Financial or health information
- Confidential contracts or business plans
- Login credentials
- Regulated records
- Copyrighted or licensed material
Then review the proposed tool’s access, retention, training, and administrative controls. Requirements vary by industry and use case. When legal, security, or compliance obligations apply, involve the appropriate specialist.
The practical rule is simple: do not upload sensitive records merely to see what happens.
Check your software and access.
A promising idea can become expensive when the systems involved do not connect cleanly.
Check:
- Whether your existing software already has the needed feature
- What integrations or APIs are available
- Whether your plan level includes them
- Who controls administrative access
- Whether data can move without manual exporting
- What a third-party tool would cost after a trial
- Whether the workflow depends on one employee’s personal account
This is not glamorous discovery work. It is, however, where realistic scope comes from.
I would rather discover early that an integration needs a more expensive subscription than unveil it after the team has fallen in love with the prototype.
Measure the starting point.
You do not need a complex ROI model for a first test. You need a starting measure connected to the problem.
Useful measures include:
- Minutes spent per item
- Time to first response
- Number of manual handoffs
- Items returned because information was missing
- Follow-ups missed
- Percentage requiring substantial correction
- Employee confidence using the new workflow
Record the baseline before the build. Memory becomes generous after a new system launches. Suddenly the old process was impossibly slow and the new one is obviously better. Numbers keep everyone honest.
Assign an owner after launch.
Implementation is not finished when the automation runs successfully in a demonstration.
Someone needs to:
- Monitor early use
- Collect problems and exceptions
- Update instructions or source material
- Manage access
- Decide whether to expand, revise, or stop
- Train new team members
If the workflow has no owner, it will eventually become digital attic furniture: technically still there, vaguely familiar, and avoided by everyone.
Your practical AI readiness checklist.
You are probably ready for a bounded AI project if you can answer yes to most of these:
- We can name one recurring workflow we want to improve.
- The people who perform it can help map and test it.
- We know where the necessary information comes from.
- We understand what data should and should not be used.
- We can name the decisions that remain human.
- We have access to the relevant software and accounts.
- We can measure the current process in a simple way.
- Someone can own the workflow after launch.
- The first project is small enough to test without betting the business on it.
If you checked four boxes, do not panic and commission an “AI transformation roadmap.” Pick the missing pieces connected to one workflow. Readiness can be built.
Build readiness one step at a time.
Map one process. Improve the intake form. Gather ten representative examples. Write down the approval rule. Confirm who owns follow-up. Review the software you already have.
None of that looks like a dramatic AI initiative. All of it makes a future implementation more likely to work.
Hazel & Helm’s AI Operations Sprint is designed for businesses that are ready to examine real work but do not yet know which improvement makes sense. We review three workflows, select one bounded opportunity, and build or test it with the people involved.
To start, choose a recurring workflow, connect your AI policy to a shared AI strategy, and agree on a starting measure.
Frequently asked questions.
Does our data need to be perfect before we use AI?
No. It needs to be appropriate and reliable enough for the specific task. A narrow workflow may require only a controlled set of current documents or representative examples. Poor, outdated, or inaccessible source information should be addressed before it is used.
Do we need an AI policy?
A short, practical policy is useful once employees are using public AI tools. It should explain approved tools, prohibited information, required review, ownership, and where employees should ask questions. A policy should reflect actual use rather than sit unread in a folder.
Do we need an internal technical team to implement AI?
Not necessarily. A bounded workflow can often be implemented using existing business software and mainstream tools. You still need an internal decision-maker, access to the relevant systems, and someone who will own the finished process.
What if our employees are already using AI?
Find out what they are using it for, what information they enter, and which shortcuts are genuinely helpful. Then choose one recurring workflow to standardize, establish boundaries, and measure. Individual experimentation can provide useful clues, but it is not a shared operating process.