AI Readiness Assessment: What to Examine Before Implementation

Readiness needs a defined task and an acceptable result. “Use AI in customer service” leaves the team without a clear boundary. “Prepare a draft answer using current product information for a service adviser to check” identifies an output, a source and a human decision before the answer reaches a customer. This is an illustrative task, not a claim about an included Adaca workflow.

The current process provides the baseline for judging that result. Representative completed cases show what people read, decide, enter and check today. Difficult cases matter too: a missing document or an ambiguous request may reveal work that a successful demonstration leaves out.

The proposed change should identify which steps AI would perform and which remain with people or conventional software. That distinction helps the team assign responsibility and choose tests. It also leaves room to conclude that clearer information, a simpler process or an existing software feature would address the problem.

A readiness review needs evidence that connects the proposed workflow to its operating conditions. The following areas provide a practical review structure, rather than a standardised scoring model or certification. Each finding should name its source, the uncertainty that remains and the person able to resolve it.

An unresolved dependency should remain visible in the assessment. A statement such as “the documents are available” is incomplete if nobody has confirmed which users may retrieve them. Recording that gap is more useful than giving the information category a high score based on a small sample.

Information readiness includes relevance, currency and permission to use the material. A document collection may contain superseded instructions alongside current ones, or records intended for different teams. The assessment should establish how the proposed workflow distinguishes those cases and who maintains the source material.

Access rules need to be tested against the people and tasks in scope. A technical account being able to read a file does not establish that every user should receive its contents. The design should specify which identity and permissions govern retrieval, and the tests should include information a user is not allowed to see.

Missing information requires a defined response. If the source does not support an answer, the workflow may need to ask for clarification or pass the case to a person. The assessment should identify that path before a team treats a fluent response as evidence that the task is complete.

A process owner needs authority to decide whether the result is usable. That person may need input from the people doing the work, the technical team and those responsible for the information. Naming an owner without giving them time to review cases leaves an approval dependency unresolved.

Human review must be described as actual work. The scope should say what the reviewer checks, what information they can inspect and how they correct or reject an output. A proposed time saving needs to include that effort; the automation selection guide explains how remaining work affects the comparison.

Training should cover the workflow's limits and escalation process. People need to know when an output can be used, when further checks are required and whom to contact when something goes wrong. Familiarity with an AI tool alone does not establish those responsibilities.

Acceptance criteria turn a promising trial into a testable proposal. For a document assistant, criteria could cover finding a supported answer, identifying the source, respecting access rules and handling a question that the available material cannot answer. The business and delivery team need to agree which failures would prevent launch.

Representative cases reveal different weaknesses from repeated demonstrations of the same successful example. Include routine tasks, incomplete inputs, conflicting documents and restricted information where those conditions occur in the proposed scope. Record the expected outcome before comparing it with the system's response.

Release decisions also need an operating plan. Someone must be able to investigate a reported error, update the source information and decide whether the workflow should be paused. The assessment should identify these responsibilities and any remaining support or access dependency without implying that a readiness review has already tested the finished system.

Our published document-assistant account describes an Australian manufacturing company using Copilot with SharePoint. The proposed next step required decisions about relevant material, permissions, document versions and citations, alongside human review and customer acceptance testing.

That engagement reached an approved plan and authorisation to build. The account does not establish a completed deployment or measured return. For a readiness review, its contribution is the set of dependencies the plan had to address before implementation, rather than evidence that a tool choice made the business ready.

The same published account appears in our custom software costs guide to explain scope and operating costs. Here it illustrates the information and acceptance decisions behind that scope. It is one engagement viewed through two questions, not a second customer result.

A self-assessment gives an initial view based on the answers supplied. It can help a team identify topics for discussion, but it does not inspect internal systems or demonstrate that an implementation is ready. Adaca's assessment hub distinguishes these indicative resources from scoped engagements.

The AI Diagnostic provides a separate readiness analysis and costed roadmap. Its published scope includes a workshop, departmental placement on Crawl, Walk or Run, and a presentation with the supporting document. The roadmap can be used with Adaca, another provider or the business's own team.

Discovery remains the starting point for an Adaca engagement. The AI Diagnostic is optional where further readiness analysis is needed; the Business Efficiency Assessment separately examines work, systems and administrative effort. Neither assessment is a compulsory purchase before implementation.

A useful readiness report separates evidence from assumptions and assigns the remaining work. It should describe the proposed scope, what was examined, what could not be checked and the decisions still required. Each unresolved item needs an owner and a condition for resolution, such as confirmed access or an agreed test result.

The next step may be a bounded trial, further investigation or a change to the underlying process. A trial should have a defined user group, information boundary and acceptance decision. Broader implementation can then be considered against what that work establishes, rather than being assumed at the outset.

Adaca's AI Diagnostic page describes the scoped assessment and its outputs. Where the requirements are sufficiently understood, discovery can instead establish the implementation work and whether it fits pre-developed workflows, custom technology or a combination.