AI Readiness Assessment or Implementation Project: Which Do You Need?

Buy an AI readiness assessment when you need evidence to choose which work to pursue. Buy an implementation project when you already have a defined task, an accountable owner, and a credible way to accept the result. If a single technical uncertainty blocks that decision, commission a bounded feasibility test. The right starting point depends on what you still need to learn.

Identify the decision you can't make yet

Start with the sentence your leadership team can't finish: “We can approve the next step once we know…” The missing answer might concern business priority, access to records, or whether a proposed workflow can meet its quality bar. Those gaps require different work.

The National AI Centre's research covering December 2025 to February 2026 identifies trust, unclear relevance, and uncertainty about how to start as barriers for Australian SMEs. Those findings explain why guidance can help. They don't establish that every company needs a separate strategy engagement before improving a task.

Reader questions show the buying tension. In a small-business discussion about readiness assessments, participants question whether a score leads to practical next steps. Treat that discussion as a question to answer, rather than evidence about the whole market. Ask a prospective partner which decision their assessment will let you make.

This table is a buying framework, not a certification scheme. A company can be ready for an internal drafting task while lacking the controls for automated transactions. Define readiness against the proposed work and its consequences.

When an AI readiness assessment earns its place

An assessment earns its place when unresolved choices affect the investment. Several departments may want the same engineering capacity, an acquisition may have left system ownership unclear, or leaders may disagree about the problem to solve. An independent comparison can prevent a team from building the easiest demonstration while the costly bottleneck continues elsewhere.

Scope the assessment around actual decisions. Name the business units and candidate workflows, the evidence the assessor can inspect, and the people who can explain exceptions. A list of possible AI applications without access to operating evidence supports an initial conversation, but it doesn't support a confident delivery recommendation.

Ask for representative, permitted examples of completed work and difficult cases. Include the people who perform the task, the process owner, and the relevant system contacts. Finance can help distinguish effort released from a benefit the company can realise. The assessment needs to show where the work goes after a tool makes an initial output.

Broad frameworks can prompt questions you might otherwise miss. Microsoft's AI Readiness Assessment uses multiple-choice questions across areas including strategy, data, governance, organisation, and infrastructure. Use that kind of coverage to organise enquiries. For a purchase decision, ask for supporting workflow evidence behind the answers.

Require the assessor to consider process changes, existing software, and ordinary rules alongside AI. If staff copy the same structured fields between two systems, a supported integration may solve the problem. If nobody agrees who approves an exception, clarify that responsibility before automating the handoff.

Set a stopping condition for the assessment. Its conclusion can recommend a build, a prerequisite, a narrower test, or no further work. Agree who makes that decision and what evidence they need. The AI strategy and readiness service guide explains the scope and handover for this kind of engagement.

When you can go straight to implementation

You can skip a standalone assessment when your team already has current evidence for a bounded project. You know the task and its owner, can inspect the necessary records, and understand what a correct result means. You also have a credible reason to change the existing process and someone who can accept the delivered workflow.

A practical entry brief names the source system, the action boundary, the normal case, and the exceptions. It explains who reviews outputs and where they record the final decision. It also identifies the current baseline and the person responsible for support after release.

Existing evidence might come from an internal operations review, a previous assessment, or a working pilot. Check its age and scope. A system migration can invalidate an access finding; a new product line can change the cases a workflow must handle. Reuse what still holds and investigate the gaps that affect this project.

Implementation still includes discovery at task level. Engineers inspect interfaces, confirm permissions, and refine acceptance tests before connecting production systems. You can make those checks an explicit first stage of the build, with a decision point if they reveal a material obstacle. Ask the proposal to explain when further approval becomes necessary.

For an existing pilot, inspect the code and deployment evidence before commissioning a replacement. Identify its inputs, limitations, and maintenance owner. A pilot that drafts a plausible answer may still lack the permissions and failure handling needed for daily use. Keep the parts that meet the requirements and specify the work that closes the remaining gaps.

The AI implementation service guide describes delivery through evaluation, release, and support handover. Use it to check whether a proposal covers the full operating task. A demonstration alone doesn't establish that the business can rely on the workflow.

Ask for deliverables you can accept

Before commissioning an assessment, agree what you will receive and how you will judge it. A slide deck can communicate the findings, but the underlying records should let your team examine the recommendation and brief another delivery partner.

• A candidate register. Each workflow has a business owner, a problem statement, supporting evidence, and a reason for its priority. Record rejected options and the reason for rejecting them.
• A dependency and uncertainty record. Separate verified access and data findings from assumptions. Name who can resolve each material gap and the decision it blocks.
• A comparison of approaches. Explain why the recommendation fits better than the current process, configuration, or a simpler integration. State what evidence would change the choice.
• A first-project brief. Define the included task, exclusions, acceptance method, ownership, and prerequisites. Keep the recommendation portable so the assessment doesn't silently commit you to the assessor's build.

For implementation, acceptance moves to a working process. Request the code or configuration your agreement covers, integration documentation, evaluation cases and results, and the release and support instructions. Confirm access and ownership arrangements before work starts. A handover that depends on a departing contractor's personal account creates an avoidable operating problem.

Write acceptance cases in business terms. For an order-preparation workflow, the result includes the correct customer and product records, the right review route, and confirmation of the accepted state in the order system. Test missing data, conflicting records, and a repeated request after a timeout. A correct paragraph doesn't compensate for a duplicate order.

Include a route for unresolved cases and a way to pause the assisted path. Define who responds when the system or a source document changes. Use the existing guide to ownership after launch to assign those responsibilities before the implementation team leaves.

Use a bounded test for a material unknown

Sometimes you know the business priority but can't yet choose the implementation approach. An old system may lack a documented interface, or the records may contain conflicting identifiers. A focused feasibility test can answer that specific question without reopening the company's entire AI strategy.

Write the question so the test can fail. For example: “Can we retrieve the permitted customer and product records, match the incoming request, and identify ambiguous lines for review?” Specify representative samples and the failure cases that matter. Agree the acceptance conditions before reviewing the result.

Keep the access and action boundary explicit. A read-only test can establish whether the team can assemble the necessary context. It won't prove that production writes handle concurrency, retries, or recovery. List the untested requirements in the result so a successful experiment doesn't become an unsupported release decision.

A test report should preserve the inputs it can lawfully retain, the method, observed results, and the limits. Include the current process or simpler approach as a comparator when it answers the same question. If the test only examines clean examples, explain why those examples represent the proposed scope or extend the test.

Agree the next decision in advance. A positive result may support a scoped build. A negative result may narrow the task or send the team back to a source-system change. If the test finds a new uncertainty, explain its consequence before extending the work. Avoid rolling experiments forward indefinitely without an owner deciding whether the evidence justifies continuation.

A worked example: preparing distributor orders

Consider an illustrative distributor that receives customer orders by email. Staff interpret product descriptions, find account details, and prepare order records for approval. This example demonstrates a buying decision; it isn't a claim about a Waypoint client or a measured result.

In the first starting position, leaders only know that administrative work feels slow. Sales wants quote drafting, operations wants order entry, and finance wants help with disputes. The company hasn't measured where queues form or checked which systems hold the required information. A scoped assessment should compare those workflows before anyone commits to an order-entry build.

In the second starting position, the order team has already mapped its work. It has current examples, an authorised process owner, and an agreed scope: prepare draft order lines for human approval. The system owner has confirmed supported access, and reviewers can describe correct matches and unacceptable substitutions. The company can commission implementation with a targeted check of those assumptions.

In a third position, the task is equally clear but staff can't establish whether old customer product codes map reliably to current stock codes. Commission a bounded matching test using permitted historical orders, including ambiguous and obsolete codes. Ask it to measure correct matches and appropriate referrals. A model's willingness to suggest a product doesn't establish that the suggestion is acceptable.

Suppose the evidence shows that an existing maintained lookup table resolves the exact codes and that only free-text descriptions require interpretation. The delivery brief can then combine deterministic lookup with a narrower AI task. If records lack a dependable customer reference, repair that prerequisite before connecting the assisted output to an account.

The engagement changes because the evidence changes. The same company can need an assessment for its cross-department priorities and a direct implementation for a well-defined local task. Keep those scopes separate enough that each sponsor can accept the result.

Compare proposals around the same evidence

Give shortlisted partners the same sanitised workflow example and decision brief. Ask each to explain the work they propose, the evidence they need from you, and what they will deliver. Control access to sensitive records through your approved process rather than distributing production access during a sales discussion.

Ask why the proposed starting point fits. A recommendation for assessment should identify an unresolved choice that affects the build. A recommendation for immediate implementation should identify the evidence that supports its scope and the checks that still need to happen.

Compare exclusions and customer responsibilities. Your team may need to arrange system access, approve process changes, prepare evaluation examples, and provide reviewers. Name those people and confirm they have capacity. A proposal that assumes unavailable internal work can stall even when the supplier's technical plan is sound.

Check commercial independence and incentives. Ask about product affiliations, subcontractors, and dependencies that affect the recommendation. Agree ownership and access to the assessment outputs, and make the follow-on build a separate explicit decision. The same firm can assess and implement if the evidence and decision rights stay clear.

Request an acceptance review at the end of the first commitment. The sponsor should be able to continue, narrow the scope, or stop using the delivered evidence. Avoid accepting an unspecified “AI roadmap” or “production-ready agent” without agreed criteria that define those terms.

Write the brief for the next commitment

Prepare a short brief before discussing the engagement. State the decision you need to make, the workflow or business units in scope, and the evidence you already have. Identify the sponsor and the people who can grant access or approve a change.

Then write the deliverable and acceptance condition. For an assessment: “We need an evidence-backed choice between these candidate workflows and a first-project brief.” For a feasibility test: “We need to resolve this named constraint before approving the approach.” For implementation: “We need this defined workflow to pass these cases and enter supported use.”

Attach the known gaps and say which findings require a new decision. A request to expand into another department, introduce production writes, or replace a source system changes the commitment. Make that change visible before the work proceeds.

If the priority and operating evidence are unclear, use a readiness assessment to reach a defensible first-project decision. If your team already has that evidence, move into implementation with proportionate checks. If a single unknown blocks the route, define the test that will settle it and the person who will act on the result.