What an AI readiness assessment should check before you buy AI

An AI readiness assessment should check whether a specific workflow is worth changing, whether the data it needs is accessible and trustworthy, which systems the AI must read from and write to, what can go wrong, and who owns the result. Model and vendor choice come after those answers, not before them.

Most assessments fail in one of two directions. Some are generic maturity surveys that score a company on culture and strategy without naming a single workflow. Others are sales conversations for a specific tool. Neither tells you what to build, what to buy, or what to leave alone. This checklist is meant to sit between them.

Why readiness is hard to judge from the outside

AI projects rarely fail because the model is too weak. They fail because the surrounding system was not ready. The data lives in exports nobody refreshes. The process has undocumented exceptions that only one person handles. The output needs to land in a tool with no usable interface. Or nobody has agreed on what a correct answer looks like.

These problems are invisible in a demo. A demo uses clean sample inputs, skips permissions, and ends when the answer appears on screen. Production starts where the demo ends: the answer must be checked, stored, acted on, corrected, and audited. A readiness assessment exists to find the gaps between those two worlds while they are still cheap to close.

There is also a timing problem. Teams usually ask for an assessment after they have already chosen a tool or promised a feature. At that point the assessment becomes a justification exercise. The most useful time to run one is before budget is committed, when the answer is allowed to be no.

What teams often get wrong

The first mistake is assessing the company instead of the workflow. Readiness is not a single score. A business can be ready to automate inbound inquiry triage and nowhere near ready to automate refund decisions. Assess candidate workflows one at a time.

The second mistake is treating data availability as a yes-or-no question. Having the data somewhere is different from being able to read it programmatically, with the right permissions, at the moment the workflow runs. Stale spreadsheets and PDF archives count as data, but they come with extraction and freshness costs that belong in the estimate.

The third mistake is skipping the definition of good. If the team cannot describe what a correct output looks like for twenty real examples, nobody can tell whether an AI system is working. That is not a model problem; it is a missing specification.

The fourth mistake is ignoring the write path. Reading data and generating text is the easy half. Updating a CRM, sending a message, or changing a record is where errors become customer-facing, and where permissions, approvals and audit trails matter.

A practical assessment structure

A useful AI readiness assessment walks through six areas for each candidate workflow. Each area should end with a short written finding, not a score.

1. Workflow fit

• What is the workflow, step by step, including the exceptions people handle manually?
• How often does it run, and what happens today when it is slow or wrong?
• Which steps involve judgment, and which are repetitive transformation of information?
• Is the goal to save time, reduce errors, respond faster, or make something possible that is not done at all today?

2. Data and context

• Where does each input live, who can access it, and how is it accessed: an interface, a database, an export, or a person?
• How fresh does the data need to be, and how fresh is it actually?
• Is there sensitive, personal or regulated information in the inputs or outputs?
• Are there enough real, labeled examples to test against?

3. Systems and integration

• Which systems must the AI read from, and which must it write to?
• Do those systems have stable interfaces, rate limits, or webhook support?
• Where will outputs be stored so they can be reviewed later?

4. Risk and review

• What is the worst realistic outcome of a wrong answer, and who notices it?
• Which actions need a human approval step before they take effect?
• What must be logged to reconstruct why the system did something?

5. Ownership

• Who owns the workflow after launch, including prompt, data and integration changes?
• Who reviews failures, and how do they feed back into fixes?

6. Evaluation

• What does a correct output look like, written down for real examples?
• How will the team compare versions before shipping a change?
• What signal would tell you to stop, simplify, or roll back?

Implementation considerations

Run the assessment with the people who do the work, not only the people who approve the budget. The exceptions that break automation are usually known to one operator and absent from every process document.

Collect artifacts, not opinions. Ask for a sample export, a screenshot of the tool where outputs must land, the current response templates, and a handful of real cases including the awkward ones. An assessment that ends without real examples cannot produce a credible estimate.

Keep sensitive data handling explicit from the start. Decide which inputs may be sent to an external model provider, which must be redacted, and which should never leave your systems. If regulated data is involved, involve whoever handles legal and compliance review before a prototype touches it.

Finally, make the output decision-ready. A good assessment ends with a ranked list of workflows, the recommended approach for the top one, the main risks, what would need to be true to proceed, and a rough scope described as effort drivers rather than a quote.

Trade-offs

A short assessment is cheap and fast but can miss integration constraints that only appear when someone tries to call a real interface. A longer assessment that includes a small technical spike costs more but replaces assumptions with evidence. For workflows that write to customer-facing systems, the spike is usually worth it.

A broad assessment across many departments produces a useful map but rarely produces a build decision. A narrow assessment of two or three workflows produces a decision but may miss a better opportunity elsewhere. Many teams do a broad pass first and a narrow, deeper pass on the top candidate.

An internal assessment has more context; an external one has fewer blind spots about what is technically easy or hard. Mixing the two, with internal operators and an outside engineer in the same session, tends to surface the most useful disagreements.

Lessons from ImadDhin work

The portal's own intake for the complimentary AI Readiness Scan offers a small example of readiness thinking. The first point below is a code-level observation of that form; the other two describe patterns that reviews of intake flows like it commonly surface. None of them are claims about outcomes.

The form validates structure on the server before anything else: a valid email, a minimum-length description of the current tech stack, and a minimum-length description of the business model. That is a deliberate readiness gate. A scan cannot say anything useful about a workflow the requester has not described, so thin submissions are rejected with a clear validation error rather than processed into a vague report.

A common finding in reviews of intake forms is a usage rule, such as one complimentary request per email, that is enforced only in the browser or checked with a read followed by a separate write. The first can be bypassed by editing the request; the second can let two simultaneous submissions both pass. The sturdier pattern is to enforce the rule atomically where the record is created, return a specific, human-readable message when it applies, and let any browser-side pre-check fail open so a temporary lookup error never blocks a legitimate visitor.

Another frequent finding concerns work that runs after the record is saved, such as generating a report. Saving first keeps the submission fast and ensures the request exists even if downstream processing fails. The trade-off is the same one described in the content-to-CRM attribution guide: a fire-and-forget handoff is not a durable queue. If delivery must be guaranteed, the saved record needs a processing status, a retry path, and an alert that someone actually reads.

Common mistakes to test for

• Run the candidate workflow against real historical cases, including the ones operators remember as difficult, not only clean samples.
• Check whether the AI can reach the data with production permissions, not an administrator account used during the demo.
• Try inputs with missing fields, contradictory information, and a different language than expected.
• Confirm that a failed downstream write is visible to someone, rather than silently dropped.
• Verify that sensitive fields are redacted or excluded before they reach an external provider.
• Ask a second reviewer to judge outputs against the written definition of good, and compare their verdicts with the first reviewer's.

When a simpler solution is better

Sometimes the assessment's most valuable finding is that AI is not the first fix. If the workflow fails because the process is undocumented, write the process down. If it fails because data is scattered, consolidate it. If a fixed template answers most requests correctly, a rules-based form or a saved-reply library may be cheaper to build and easier to maintain than a model.

It is also reasonable to buy instead of build. If an existing tool already covers the workflow and your data can live in it, the assessment should say so. Custom engineering is worth it when the workflow is specific to your business, touches several systems, or needs controls an off-the-shelf tool cannot provide.

Start with one workflow, not a strategy deck

Pick the workflow that runs often, hurts when it is slow, and has real examples you can test against. Assess it across the six areas above, and let the findings decide whether you build, buy, simplify, or wait.

You can start with the complimentary AI Readiness Scan, explore AI automation consulting for a deeper assessment, or talk through a candidate workflow in a 30-minute call.