AI Readiness Assessment: A Practical Guide for Mid-Market Teams

An AI readiness assessment is a structured review of whether a team can run a specific AI use case reliably, with appropriate ownership, trustworthy inputs, controlled actions, and measurable business value. Its useful output is a decision to proceed, defer, or reject the use case, plus a prioritized gap list, named owners, and next steps, not just a maturity score.

For example, a mid-market operations team could assess whether new billing enquiries are ready for AI-assisted classification. The question is not whether the whole company is “AI-ready.” It is whether this process has a clear owner, usable intake data, a permitted classification task, a safe route for uncertain results, and a way to measure whether handling improves.

This guide treats readiness as a use-case decision. It provides a five-area rubric, minimum pilot gates, a proposed AI-assisted intake design, and measures that distinguish usage from operational value.

What an AI readiness assessment should tell you

Readiness is specific to a use case. A team may be ready to test AI on a bounded task while remaining unready to let AI make decisions or update records across the business. The assessment should answer one operational question: Can this team run this use case with trustworthy inputs, bounded AI responsibility, a controlled action, and an owned exception path?

Make’s editorial guide describes five assessment areas: strategy, data, infrastructure, people, and governance. That is a useful starting structure, not an independently validated standard. This guide adapts those areas into a practical, use-case-level review. Read Make’s AI readiness assessment guide.

The assessment should produce four tangible outputs:

• A decision to proceed to a bounded pilot, resolve named gaps first, or reject or defer the use case.
• An evidence-backed scorecard showing what is known and what remains uncertain.
• A prioritized gap list with accountable owners and dependencies.
• A pilot plan with acceptance criteria, baseline measures, and reassessment triggers.

Scope the assessment around one business process

Start with a repeated operational task and an outcome that matters. Examples include reducing the time to triage incoming requests, improving the completeness of case records, or reducing avoidable handoffs. Avoid a broad goal such as “use more AI,” which does not establish what should change or how success will be judged.

Map the current process before choosing an AI model or automation platform. Record the trigger, source data, decisions, system updates, and exceptions. Name the system of record and the person accountable for the process outcome. Then identify which steps are deterministic, which may benefit from AI, and which require human judgment.

A short use-case charter makes the boundary explicit:

• Process owner: the person accountable for the operational result.
• Current problem and target outcome: what is difficult now and what should improve.
• Systems and data: the source, destination, relevant fields, and access path to verify.
• Prohibited actions: decisions or fields the AI-enabled workflow must not change.

Write the charter as one sentence: the process owner will use a defined source and destination to improve a named outcome, while the AI may perform only a specified task and may not perform specified actions.

Score five readiness areas for the selected use case

Score each area separately and attach evidence, an accountable owner, a gap, and a next action. The following scale is an editorial scoring aid for prioritization, not an industry benchmark:

• 0: Unknown or absent. The team cannot show that the requirement is met.
• 1: Identified but informal. Someone has considered it, but the approach is not documented or tested.
• 2: Documented and tested. A defined approach has been checked for this use case.
• 3: Operating with an owner and evidence. The control or process is in use and someone can show how it is monitored.

• Business ownership and strategy: Is there a named process owner, a specific outcome, and an agreed decision about what the pilot may change?
• Data: Are the required inputs identifiable, accessible, sufficiently current, and trustworthy for this task? Is a person accountable for their quality?
• Workflow and technical fit: Can the existing systems exchange the needed data through a verified access path? Is there a defined destination and a way to handle failures?
• People and process adoption: Who will use or review the result? Is the revised process clear, and does the team have time to handle exceptions?
• Governance and control: Are permitted and prohibited actions, access permissions, review requirements, and recordkeeping defined for this use case?

Apply minimum readiness gates before approving a pilot

A bounded pilot does not require perfect enterprise-wide data governance. It does require enough evidence to operate this specific workflow safely. The process owner should be able to answer these five questions:

1. What business outcome should change, and how will it be measured?
2. What exact fields or documents enter the workflow, and where do they come from?
3. Who owns the source data, and what confirms that it is suitable for this task?
4. What may the AI interpret or suggest, and what must it never decide or change?
5. Who handles a missing, uncertain, invalid, or incorrect result?

Use deterministic rules for required fields, permissions, allowed values, duplicate controls, numeric thresholds, and protected fields. Reserve AI for tasks such as interpreting unstructured text, extracting candidate information, or drafting a summary. A filter can enforce defined conditions, but it does not establish that AI-generated content is factually or semantically correct. Make documents filters for deterministic scenario conditions.

Do not approve a pilot if there is no accountable process owner, no traceable source for the data, or no safe route for exceptions. Document the required inputs, AI boundary, validation rules, destination, and manual fallback before the first live test.

Design one controlled AI-assisted workflow

Consider this hypothetical implementation design for classifying new billing enquiries. The intake application is the source, the CRM case is the system of record, and the intake process owner is accountable for classification quality. A systems owner handles integration failures. Confirm that the required source and destination access methods, permissions, and connector or webhook options are available in the actual environment before building.

1. Receive and identify: A supported application trigger or configured webhook receives a new intake event. Capture the source system, source record ID, source event ID, timestamp, text, and confirmed destination case ID.
2. Ask a bounded question: Pass selected text to an AI agent or other chosen AI module to suggest one category from an approved list and a short rationale. Do not delegate permissions, destination selection, or a high-impact update to the AI.
3. Validate deterministically: Check that source and destination IDs exist, the category is on the allowlist, required fields are present, policy checks pass, and the proposed field is permitted to change. If a confidence or review field is available from the chosen AI provider, use it as a routing signal, not as proof of correctness.
4. Route and record: Update only the approved classification field on the confirmed CRM case if every check passes. Otherwise create a review task or exception record for the process owner. Preserve the source reference and previous and proposed values.

An illustrative output contract might look like this. These fields are a proposed design, not a universal Make output format:

{
  "source_system": "intake_form",
  "source_record_id": "REQ-4821",
  "source_event_id": "evt-7f31",
  "category": "billing_discrepancy",
  "rationale": "The invoice total differs from the approved quote.",
  "needs_human_review": false,
  "policy_flags": [],
  "instruction_version": "intake-classifier-v1",
  "processing_run_id": "run-2026-10-16-001"
}

For example, an unknown category, missing case ID, or flagged result should not update the CRM. The workflow creates a review item containing the source reference and proposed classification; the intake process owner decides whether to correct, approve, or reject it. A timeout or temporary destination error follows a separate technical exception path.

Make’s documentation describes planning and configuring an AI agent, adding tools and context, and testing it. It also documents filters, routers, and retry and incomplete-execution handling. Those documented features do not constitute the complete governed workflow above: the output contract, human review, provenance, field protections, and duplicate safeguards are proposed implementation controls. See Make’s introductory agent setup and testing guide, its guidance on defining tools and their inputs and outputs, and its documentation for scenario routes and fallback routing.

For repeatable writes, use a stable event identity such as source_system + source_event_id + workflow_version. Protect that key with destination-side uniqueness or a transactional upsert where available. A read-then-create sequence can still create duplicates if concurrent runs both check before either writes. Retries also need duplicate-safety controls. Make documents retry handlers and incomplete executions, but those features alone do not make a destination write idempotent. Review Make’s retry error handler documentation and verify the behavior of the actual destination.

For teams that have defined a bounded use case and need implementation support, see AI agent implementation support. If the assessment identifies CRM ownership, data quality, or process integration gaps, CRM systems consulting may be relevant.

Turn assessment findings into a pilot plan and measures

Rank gaps by business impact, effort, dependency, accountable owner, and the next decision. Capture a baseline before the pilot and name the system of record for each measure. Separate activity from quality and business outcomes:

• Activity: scenario runs, AI calls, tool invocations, or active users. These show usage, not value.
• Quality: valid-output rate, human-review rate, override rate, duplicate writes, and error or retry rate.
• Business outcomes: processing time, rework, escalation rate, or cost avoided. Define the measurement period and compare against the baseline.

Keep data grain clear. An event record represents one incoming source event and uses a key such as source_system + source_event_id. A run record represents one workflow execution and uses a processing run ID, with an attempt number if retries create separate attempt records. A citation record, if used, needs a key such as processing_run_id + citation_id. A period-level metric represents a defined entity and reporting period, such as entity_id + aggregation_date + aggregation_version. Do not combine multiple events or runs into one event record, or treat aggregate results as individual events.

Agree acceptance criteria with the process owner before the pilot. For example, the owner might require that all automated writes pass the defined validation checks, that exceptions reach the review queue, and that the measured business outcome improves against baseline. Scale only when the agreed quality and business measures meet those criteria and exception handling is working, not because usage has increased. For teams implementing a validated workflow in Make, see Make automation services.

Run the assessment as a repeatable operating process

Use a cross-functional group shaped by the process. Depending on the use case, include operations, finance, customer-facing teams, IT, and compliance. Record the assessment date, process boundary, systems reviewed, assumptions, decision, and owner so a later review compares like with like.

Reassess when the model or provider, source data, permissions, destination workflow, or applicable controls change. The scope depends on the systems, teams, data, and control requirements involved, so there is no reliable universal assessment duration.

Common questions about AI readiness assessments

How long does an AI readiness assessment take?

It depends on the process boundary, number of teams and systems, data access, interviews, and control requirements. A focused internal review of one process differs from a broad review across an organization. Set the scope first rather than treating a published timeline as a benchmark.

How much does an AI readiness assessment cost?

Cost depends on the same scope factors, including whether the work is completed internally or involves external support. Define the process, evidence needed, and decision the assessment must enable before requesting a quote. Avoid using unverified market ranges as a budget standard.

What is the difference between readiness and maturity?

An assessment evaluates a current use case or organizational state and identifies what to do next. A maturity model describes stages of capability over time. A company can be ready for one narrow pilot without being ready for broad AI deployment. Make describes its AI Playbook as a four-question assessment that assigns a maturity stage and roadmap; that is Make’s own tool, not validation of this guide’s five-area rubric. See Make’s description of its AI Playbook.

Can a small company conduct an assessment without a consultant?

Yes, if the team can map the process, gather evidence from the relevant owners, identify control gaps, and agree measurable pilot criteria. Bring in specialist support when the review exposes complex integration, data ownership, permission, or compliance questions that the team cannot resolve.

Make the decision at the use-case level

A useful AI readiness assessment ends with a practical status: proceed to a bounded pilot, resolve named gaps first, or reject or defer the use case. Keep the evidence, owner, decision, and measures together. That gives the team a defensible next step without pretending that one score can certify the whole organization as ready for AI.