AI Readiness Assessment: What to Test First
Invoice approvals take four days because staff search through email threads, compare purchase orders, and re-enter fields into an accounting system. That is a credible starting point for AI, but only if the process has enough reliable data, clear decision rules, and an owner who can change how work gets done.
An AI readiness assessment helps you determine whether a proposed AI initiative can improve a real business process before your team commits engineering effort and changes core workflows. It is not a test of whether your company has adopted the latest tools. It is a structured way to assess business value, data quality, technical fit, operational ownership, and risk.
The goal is simple: identify the few AI use cases worth building, define what must change first, and rule out projects that would add cost without improving a decision or process.
Start with a business constraint, not an AI feature
Many AI projects begin with a broad request such as “build a chatbot” or “use AI for reporting.” Those requests describe technology, not a business outcome. A useful assessment starts with a constraint that someone can observe, measure, and own.
Consider an operations manager who spends each Monday combining sales, inventory, and shipment data from three systems. The issue might not require a generative AI assistant. A consolidated data pipeline and a scheduled dashboard could solve most of the problem faster and with less ongoing maintenance. AI becomes a better fit if the manager also needs to interpret unstructured supplier messages, flag unusual changes, or recommend actions from patterns across the data.
Ask three questions for each candidate process: What decision or task takes too long? What does that delay cost in time, missed revenue, rework, or customer experience? What would a better outcome look like in concrete terms?
Avoid vague targets such as “improve productivity.” A stronger target is: reduce the time required to classify incoming support requests from ten minutes per ticket to two minutes, while keeping human review for uncertain cases. That statement gives your team a workflow, a baseline, and a boundary for success.
What an AI readiness assessment should examine
A practical assessment looks across five connected areas. Weakness in one area does not automatically stop a project, but it changes the sequence of work. Sometimes the correct decision is to fix the underlying process first.
Business value and workflow design
AI works best when it supports a repeated decision, a high-volume task, or a bottleneck with meaningful consequences. The workflow must also have a clear handoff: who receives the output, what do they do next, and when should they override it?
Map the current process on one page. For example, document how a customer request enters your business, which team reviews it, which systems they consult, where they make a judgment, and how they record the result. Include exceptions. If staff handle one-third of requests outside the stated process, an AI tool will inherit that ambiguity.
Then decide whether the AI should assist, automate, or analyze. Assistance might draft a response for an agent to approve. Automation might route a standard request to the right queue. Analysis might identify the request types driving repeat contacts. These options carry different risk and implementation requirements. Start with assistance when the consequence of a wrong answer is high or the process changes frequently.
Data availability and data quality
A model cannot compensate for incomplete records, inconsistent labels, or information trapped in personal spreadsheets. For generative AI use cases, the relevant question is often whether the source documents are current, well organized, and accessible through defined permissions. For predictive or classification use cases, you also need historical examples that connect inputs to real outcomes.
Run a small data audit before you discuss model selection. Choose a representative sample, such as 100 support tickets, 100 invoices, or six months of order records. Check whether key fields are present, whether teams use the same names for the same concepts, and whether the final outcome appears in the record.
For instance, if you want to predict late payments, confirm that invoice dates, due dates, payment dates, account details, and payment status use consistent formats. If a large share of records lacks payment dates, the project may need data cleanup and process changes before prediction can provide useful guidance.
Quality matters more than volume in many early projects. A smaller, well-defined set of approved product documents can support an internal knowledge assistant more effectively than thousands of outdated files from shared drives.
Systems and integration paths
Your assessment should identify where data lives and how an AI capability would fit into daily work. A useful prototype that requires staff to copy and paste information between five systems often creates a new bottleneck.
Document the systems involved, their available interfaces, the data each system owns, and the person responsible for access. An interface, often called an API, is a controlled way for software systems to exchange data. If a critical system has no practical integration path, you may still run a limited pilot, but you should account for manual steps and their effect on speed.
Architecture choices should match the use case. A simple document search tool may need document ingestion, access controls, and a review screen. A forecasting tool may require scheduled data updates, monitoring for changes in demand patterns, and a way to send results into planning software. Building a large shared AI platform before proving one workflow can extend delivery time without improving the initial decision.
People, ownership, and operating rules
An AI system needs a business owner after launch. That owner does not need to write code, but they do need authority to define the workflow, review output quality, resolve exceptions, and decide when the team should change course.
Name that person during the assessment. Also identify the users who will test the tool and the team responsible for the data source. Without those roles, a pilot can produce encouraging demonstrations but fail when it reaches routine operations.
Create simple operating rules before implementation. Specify which outputs require human approval, what staff should do when an answer is uncertain, where they report errors, and how frequently the team reviews results. A customer support assistant, for example, might draft replies only from approved help content, show its source material to agents, and send unanswered questions to a queue for review.
Evaluation and ongoing measurement
A working demo is not proof that an AI solution improves the business. You need an evaluation method that reflects the task.
For a document classification workflow, compare the tool’s suggested category with a reviewer’s final category across a defined test set. For a response-drafting tool, measure edit time, approval rate, and the types of changes agents make. For demand forecasting, compare forecasts with actual demand over successive periods and track whether planners use the result.
Define a baseline before the pilot starts. Record current handling time, rework volume, error types, and escalation rates where relevant. Do not rely on a single accuracy score if the workflow has uneven consequences. Misclassifying a routine internal request may cause little harm; misclassifying a cancellation request may create a customer problem. Your evaluation should weight those cases accordingly.
How to run the assessment in two focused workshops
You do not need months of meetings to establish readiness. A focused assessment can begin with two workshops and a short evidence-gathering period.
In the first workshop, bring together the process owner, the people who perform the work, a technical representative, and a decision-maker. Select one workflow, map its steps, identify its exceptions, and state the target outcome. Leave with a short list of required data sources and a named owner for each one.
Over the following week, collect a representative sample and inspect it. Count missing fields, duplicate records, outdated documents, and steps that happen outside the main systems. This work often reveals that the immediate opportunity lies in standardizing intake forms or consolidating records, not in deploying AI.
Use the second workshop to review findings and choose one of three paths: proceed with a bounded pilot, complete preparation work first, or stop the idea. A bounded pilot has a narrow user group, a defined input set, a review process, and success measures. Preparation work should have an equally clear scope, such as standardizing customer categories, centralizing approved product content, or connecting two systems through an API.
At HINTY, we use this kind of assessment to connect AI choices to the data, software architecture, and workflows that make them commercially useful. The output should not be a generic maturity score. It should be a prioritized plan that explains what to build, what to fix first, and why.
When AI is the wrong next step
An AI readiness assessment should give you permission to say no. If a process has low volume, unclear ownership, constantly changing rules, or no dependable source data, automation may create more review work than it removes.
Likewise, do not use AI to hide a broken workflow. If sales and operations disagree on product identifiers, resolve the shared data definition before asking a model to generate inventory recommendations. If employees lack a consistent approval process, clarify authority before automating decisions.
Choose one workflow where delayed decisions or repetitive manual work create a visible business consequence. Map it with the people who do the work, inspect a real sample of its data, and decide whether a small pilot, data preparation effort, or process redesign earns the next investment.