Say a financial advice firm asks whether it’s “AI-ready”. It has Office 365, a CRM and thirty staff who can all use a web browser. It also has no idea which process to automate first, and nobody has been asked to find out. Is it ready?
“AI-ready” gets used as if it’s a state you reach, like passing an inspection: get your data in order, train your people, write a policy, tick the boxes. But ready for what? A firm that’s ready to run a chatbot isn’t necessarily ready to automate compliance monitoring. A team that’s comfortable with ChatGPT might be nervous about an automated workflow touching live client data. It depends on the job.
Plenty of firms with no formal AI governance get a useful automation running quickly, and plenty with thorough data strategies and a board-level AI champion stall because nobody will own the project. So here’s a definition that predicts whether an AI or automation project will happen 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 some time on a regular basis to work on it.
That’s all. A concrete target, a reason, a person and some time.
Why the four parts matter
Each part of the definition catches a different way projects die, and most firms get stuck on the first: naming the process. “We need to be more efficient” isn’t a process. “Automating suitability reports” is closer, but still too broad. “Cutting the time it takes to format and proofread a suitability report after the paraplanner writes it” is specific enough to work with.
If you can’t name it, 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 (the levels are set out in what AI means for your advice firm). And without that, every vendor pitch sounds equally plausible, because you have nothing to measure it against.
The reason matters because automation projects die when they lose momentum. If the answer is “because everyone else is doing AI”, the project stalls the first time something else becomes urgent. If it’s “because Sarah spends nine hours a week on this and we need her doing something else”, the project has a concrete reason to exist.
Ownership sounds obvious, but most firms skip it. They say “operations will handle it” or “IT will look at it” and then wonder why nothing moves. Automation is a project, and a project needs one named person who owns it as a visible responsibility, not as a favour on top of their day job.
Regular time is the commitment test. If you can’t protect a few hours a week for the person leading it, you aren’t serious about it. It isn’t a full-time job: a typical Level 2 build needs ten to twenty hours of internal time spread over a few weeks. But if those hours get pushed to “whenever there’s time”, six weeks becomes six months and confidence goes halfway through.
What the definition leaves out
There’s no mention of data maturity, an AI policy, a training programme or a technology audit. They can all be useful. None of them is a blocker.
Messy data can be cleaned as part of the automation project. A pilot can be controlled and compliant without a policy if it’s scoped carefully and what you did is written down. Training helps, but a half-day workshop is usually enough when people know what they’re trying to achieve.
“Is our infrastructure good enough?” almost never matters as much as firms think. If you have internet access, a modern CRM and the ability to install browser extensions or sign up for SaaS tools, you have enough for most Level 1 and Level 2 automation. A Level 3 custom build might need more, but by then you’re working with someone who can tell you exactly what’s required.
The five-minute test
You can test your own firm on your own, with no one else in the room. Take a blank sheet of paper and 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 now know what’s missing.
Most firms can do the first two. The third and fourth are where it breaks down. If you can’t name an owner, the problem is organisational. If you can’t find three hours, it’s prioritisation. Neither is solved by buying better software or hiring a consultant.
What to do if you’re not ready
Fix the gap before starting the project. Most firms do the opposite: they commission an audit, attend a webinar or start a pilot, hoping the project will settle who owns it and where the time comes from. It won’t. Ownership and time get sorted by deciding, not by starting.
Fixing ownership is a fifteen-minute conversation: “you’re leading this, here’s why, here’s what it involves, do you have regular time each week to do it properly?” If the answer is no, find someone else or put the project off.
Fixing time means moving something else off their plate, or accepting the project will take longer than it should. If you can’t make the time at all, the project is less important than you thought, and that’s useful to know too.
The technical gaps (data quality, awkward integrations, policy questions) almost always get solved as part of the project. The organisational ones don’t, so fix them first.
Most definitions of “AI-ready” are written to sell you something: a consultancy engagement, a platform, a training course. This one is only meant to tell you whether a project will happen. If you pass the test, start. If you don’t, fix what’s missing first.