AI Readiness Assessment: Can You Score Your Own Firm?

Most AI readiness assessments are a lead-capture form with a scorecard attached, and the result is always that you are somewhere in the middle and should book a call. Here is the actual assessment instead, with the scoring, so you can run it yourself in about twenty minutes and know your own answer before you talk to anybody.

It measures four things, and only one of them is technical. In our experience the firms that struggle are almost never held back by technology. They are held back because nobody can describe the process, or because the data is in a shape nothing can read.

Here is what matters most:

• Readiness is mostly about process clarity and data condition, not about technology or tooling.
• The single best predictor of success: can three people who do the work describe it the same way?
• Score below 12 and buying software will not help. Fix the process first and spend nothing.
• Digital does not mean machine-readable. A scanned photograph of a form is a picture, not data.
• Run this per process, not per firm. Most firms are ready for one thing and not ready for another.

How to score it

Twenty questions, four sections. Score each one 0, 1 or 2. Zero means no, one means partly, two means clearly yes. Maximum is 40. Pick one specific process before you start, because a firm is never uniformly ready, and scoring the whole organisation produces a meaningless average.

Section one: the process itself, out of 10

1. Can you draw this process end to end on one whiteboard?

2. If you asked three people who do this work to describe it, would they agree?

3. Do you know how many times it runs per month, roughly?

4. Do you know how long each step takes, roughly?

5. Do you know what proportion of cases are unusual in some way?

Question two is the one that matters most. Ask three people and you will usually get three different processes, with steps one person treats as mandatory that another has never done. That is entirely normal for a process that grew over ten years inside people's heads, and it is also the single most common reason automation projects fail: the build gets designed from how the work is supposed to happen rather than how it actually happens.

Question five catches the other big one. In most back-office processes, between a fifth and half of cases are unusual. The document arrived as a photograph. The statement covers the wrong period. The name on the form does not match the account. If you think your exception rate is under five percent, you have probably not counted.

Section two: the data, out of 10

6. Does the information arrive in a consistent format?

7. If it arrives as documents, are they machine-readable files rather than photographs or scans?

8. Is there a single place that holds the authoritative version of this data?

9. Can the systems involved be reached programmatically, or is somebody logging in and clicking?

10. Is there a reliable way to tell whether a given record is complete?

Question seven catches the most expensive misunderstanding in this whole field. Firms tell us their records are digital, meaning they are on a computer. A scanned photograph of a signed form is on a computer and contains no data at all until something reads it. That reading step is doable and it is what we do, but it is a real cost and a real source of error, and it changes the shape of the project entirely.

Question eight matters more than it looks. If the authoritative version of a client's address lives in three systems and they disagree, no automation can resolve that, and you will spend the project arguing about which one wins.

Section three: the people, out of 10

11. Is there one named person who owns this process and can decide how it changes?

12. Do the people who do the work today know this is being considered?

13. Is there somebody who will own the system after it is built?

14. Is the goal to absorb more volume rather than to reduce headcount?

15. Can you get the people who do the work into a room for an afternoon?

Question fourteen is not a values question, it is a delivery-risk question. Projects sold internally as headcount reduction need active cooperation from exactly the people being displaced, and they tend to stall in ways nobody documents. The version that works is that the mechanical work goes away, the team absorbs more volume without overtime, and the cases needing judgement reach a person faster.

Question thirteen is the one most firms score zero on and do not realise matters. Software that nobody owns degrades. Something changes upstream, a step starts failing, and if no named person is watching, it fails quietly for weeks.

Section four: risk and constraints, out of 10

16. Do you know whether this data can leave your own infrastructure?

17. Has anybody checked what your client agreements say about processing by a third party?

18. Do you know which regulations touch this specific process?

19. Would you be able to show an auditor how a given output was produced?

20. Is there an agreed answer for what happens when the system is wrong?

For firms handling client-confidential material, question sixteen usually decides the architecture before anything else does. If the answer is that data must stay in your own environment, that rules out most hosted tools and points at a self-hosted build, which is more control and also a real ongoing maintenance responsibility somebody has to own.

Question nineteen catches a subtle one. If a regulator or a client can ask how a particular answer was arrived at, then the reasoning has to be inspectable, and that pushes you towards fixed rules for the decision itself rather than letting a flexible system decide.

What your score means

Below 12. Not ready, and software will make it worse. Automating a process nobody agrees on encodes the disagreement into code, where it becomes expensive to change. Spend the afternoon on questions one and two instead. That costs nothing and sometimes removes the need entirely, because the real problem turns out to be two people doing the same step twice.

12 to 22. Ready for a narrow first project, not a platform. Pick the single most mechanical part of the process, put it into production with real data, and measure your actual exception rate for a month. That number is what tells you whether anything bigger is worth funding. Resist anyone selling you a firm-wide programme at this score.

23 to 32. Ready for a real end-to-end build on this process. You know the shape, the volume and the exceptions, and you have an owner. This is where the arithmetic starts working properly.

Above 32. You are readier than most firms that have already bought something. The risk at this score is over-scoping: doing four processes at once because it all looks tractable. Do them in sequence.

Then run the arithmetic

Whatever you scored, work out the number before anyone quotes you. Count how often the process runs per month, the mechanical minutes per run (the retyping, chasing, filing, checking, not the thinking), and a fully loaded hourly cost for whoever does it.

Sixty runs a month at forty-five mechanical minutes is forty-five hours. At forty dollars an hour fully loaded, that is about eighteen hundred dollars a month going into handoffs. Apply a realistic exception rate: if a quarter still needs a person, you are recovering roughly three-quarters of it. Now any quote is assessable by division instead of by faith.

And add the number that never appears in a proposal. If your turnaround is eleven days and a competitor's is two, that gap does not show up on an invoice. It shows up in who wins the client.

FAQ

Should we do a readiness assessment before talking to vendors?

Yes, and do it yourself rather than letting a vendor run it. A vendor's assessment is a qualification tool for their pipeline and will tend to conclude that you are ready for what they sell. Scoring it internally costs you an afternoon, and walking into the first conversation with your own volume, exception rate and constraints changes the quality of the proposals you get.

What if we score badly on data but well everywhere else?

That is the most common pattern and it is workable, because reading messy input is a solved problem now in a way it was not five years ago. It changes the project shape rather than blocking it: you are buying a reading and validation layer with a human review queue, not a simple connector between two systems. Expect it to cost more than a straight integration and to need a real exception-handling design.

How often should we redo this?

Per process rather than on a calendar. Score it once before a project, and re-score the same process after the first build has run for a month, because the real exception rate you measure will usually differ from your estimate. There is little value in reassessing the whole firm annually.

Does a low score mean we should wait for better technology?

No, and waiting is rarely the right read. A low score almost always reflects process ambiguity or data condition, and neither of those improves on its own while you wait. Both are fixable with internal effort that costs nothing but attention, and doing that work makes any later project cheaper and more likely to survive.

Key takeaways

• AI readiness is mostly process clarity and data condition, not technology maturity.
• If three people describe the process differently, fix that before buying anything.
• Digital is not the same as machine-readable. A scan of a form contains no data until something reads it.
• Score below 12 out of 40 and software will encode your process problems rather than solve them.
• Assess one process at a time, because a firm is rarely uniformly ready across its work.

If you have scored a process and want a second opinion on what it implies, that is a short conversation. Sometimes the honest answer is to fix the process and spend nothing.

Book a free strategy call

Related reading: what is workflow automation · do you need an AI automation consultant · AI agents for business

Services: AI readiness assessment · business process automation consulting