Three months ago, a financial advice firm asked me if they were “AI-ready.” I said I didn’t know what the question meant. They had Office 365, a CRM, and thirty staff who could all use a web browser. They also had no idea which process to automate first, and no one assigned to figure it out. Were they ready?
The term “AI-ready” gets used as if it describes a state you can reach, like passing an inspection. Get your data in order, train your people, write a policy, tick the boxes. But readiness for what? A firm that’s ready to run a chatbot is not necessarily ready to automate compliance monitoring. A team comfortable with ChatGPT might panic at the idea of an automated workflow touching live client data. Readiness is contextual, not binary.
I’ve worked with firms that had no formal AI governance and still successfully automated half their onboarding process in a month. I’ve also worked with firms that had comprehensive data strategies, board-level AI champions, and immaculate documentation, and couldn’t agree on what to automate because no one wanted to own the project.
So here’s a working definition that actually predicts whether an AI or automation project will succeed in a small business:
You’re AI-ready when you can name a specific process, explain why it matters, assign someone to own the change, and give them three hours a week to work on it.
That’s it. Not perfect data hygiene. Not a Chief AI Officer. Not a transformation roadmap. Just a concrete target, a reason, a person, and some time.
Why this definition works
Most firms get stuck at the first part: naming the specific process. “We need to be more efficient” isn’t a process. “Automating suitability reports” is closer, but still too broad. “Reducing the time it takes to format and proof a suitability report after the paraplanner writes it” is specific enough to work with.
If you can’t name the thing, you can’t scope it. If you can’t scope it, you don’t know whether it’s a Level 1, Level 2, or Level 3 problem. And if you don’t know that, every vendor pitch sounds equally plausible, because you have no frame of reference for what good looks like.
The “why it matters” part matters because automation projects die when they lose momentum. If the answer is “because everyone else is doing AI”, the project will stall the first time something else becomes urgent. If the answer is “because Sarah spends nine hours a week on this and we need her doing something else”, the project has a concrete reason to exist.
Assigning ownership sounds obvious, but most firms skip it. They’ll say “the operations team will handle it” or “IT will look at it” and then wonder why nothing moves forward. Automation isn’t a department’s job, it’s a project. Someone needs to own it by name. Not as an add-on to their existing role, but as a named, visible responsibility.
The three hours a week is the commitment test. If you can’t free up three hours for the person leading the project, you’re not serious about it. This isn’t a full-time job. Most Level 2 automation builds take ten to twenty hours of internal time spread over a few weeks. But if those hours get pushed to “whenever there’s time”, the project will take six months instead of six weeks, and you’ll lose confidence halfway through.
What this definition excludes
Notice what’s missing from the definition: no mention of data maturity, no AI policy, no training programme, no technology stack audit. Those things can all be useful. But they’re not blockers.
I’ve seen firms with terrible data successfully automate their client onboarding by cleaning the data as part of the automation project. I’ve seen firms without AI policies run controlled, compliant automation pilots by scoping them carefully and documenting what they did. Training helps, but a half-day workshop is usually enough if people know what they’re trying to achieve.
The technical readiness question “is our infrastructure good enough?” almost never matters as much as firms think it does. If you have internet access, a modern CRM, and the ability to install browser extensions or sign up for SaaS tools, you have enough infrastructure for most Level 1 and Level 2 automation. Level 3 projects might need more, but by the time you’re scoping a custom build, you’re working with someone who can tell you exactly what’s required.
How to know if you’re actually ready
If you want to test this definition against your own firm, try this exercise. No one else needs to be in the room.
Take a blank piece of paper. Write down:
The name of one process you want to automate. Why it matters in one sentence. Who would own the project by name. Where in their week the three hours would come from.
If you can fill in all four in five minutes, you’re ready. If you can’t, you’re not — and now you know exactly what’s missing.
Most firms can do the first two. The third and fourth are where it breaks down. If you can’t name the owner, the issue is organisational, not technical. If you can’t find three hours, the issue is prioritisation. Neither of those problems is solved by buying better software or hiring a consultant.
What to do if you’re not ready
If the four-question test reveals a gap, fix the gap before starting the project. That sounds obvious, but most firms do the opposite: they commission an audit, attend a webinar, or start a pilot, hoping the project will clarify who should own it or where the time will come from. It doesn’t work that way. Unclear ownership and no time don’t get solved by starting. They get solved by deciding.
Fixing unclear ownership means having a fifteen-minute conversation with the relevant person and saying “you’re leading this, here’s why, here’s what it involves, do you have three hours a week to do it properly?” If the answer is no, find someone else or defer the project.
Fixing the time problem means moving something else off their plate, or accepting that the project will take longer than it should. If the project is genuinely important, you’ll make the time. If you can’t make the time, it’s not as important as you thought, and that’s useful information too.
The technical gaps (data quality, integration complexity, policy uncertainty) almost always get solved as part of the project. The organisational ones don’t. You have to fix them first.
Most definitions of “AI-ready” are designed to sell you something: a consultancy engagement, a software platform, a training programme. This one is designed to tell you whether a project will actually happen. If it passes the test, start. If it doesn’t, fix what’s missing. Don’t confuse preparation with progress.