AI Readiness Checklist: Find Your First High-Value Automation
Find where AI could save your team time. Use an eight-point checklist, a worked cost example, and a free personalized AI Readiness Report.
Your team has started using AI. Emails are faster to write. Meetings turn into summaries. Someone has built a promising agent.
But orders still need checking across three systems. Finance still cleans up the same spreadsheet. Customer service still asks the warehouse for updates. And the person who knows how everything connects is already overloaded.
The question is no longer just “Can we use AI?” It is “Where can we remove real work, without creating a new problem to supervise?”
This guide helps you answer that question with one process, actual numbers, and a practical decision. You do not need a company-wide transformation plan to get started.
Want to apply this to your own team? Our free assessment turns your answers into a personalized four-page report: annual effort, a readiness verdict for your primary task, and an action checklist. No app connections or sales meeting required.
What does AI readiness actually mean?
AI readiness is the ability to apply AI to a specific business task with reliable information, appropriate permissions, clear success criteria, and a measurable benefit. Owning AI software is not the same as being ready to let it act on your business.
Your company can be ready for AI-assisted drafting but not autonomous customer communications. It can be ready to automate order lookups while keeping refunds under human approval.
Readiness is specific to the task—and to how much authority you give the system.
The short answer
Before starting, you should be able to identify:
One recurring task worth improving.
The systems and information needed to complete it correctly.
Which steps need AI and which can follow fixed rules.
What requires a person's approval.
How you will measure time, quality, and total cost.
Who will notice and handle failures.
If a piece is missing, that is your next action—not a reason to abandon AI.
Why the pressure to adopt AI feels ahead of the results
The gap between trying AI and operating it at scale is real. In McKinsey's 2025 survey of 1,993 participants, 88% reported AI use in at least one business function, but only 7% reported it fully scaled across their organizations. These are survey respondents, not a census of all businesses. Source: McKinsey, December 2025.
For an operations leader, the pressure can show up as “Handle more orders without adding another person.” For IT, it becomes “Connect another tool without weakening access controls.” For finance, it is “Show me the return—not another subscription.”
All three can be right. The missing piece is often an end-to-end view of the work.
An AI tool that writes a reply in ten seconds has not solved a twelve-minute customer request if someone still spends eleven minutes finding and checking the facts.
The biggest opportunity may be the work around the AI—not the AI output itself.
Start with one expensive handoff, not “AI for the whole company”
Write down three recurring frustrations. Good candidates sound like real tasks:
“We look up order status in the store, warehouse, and shipping system before answering customers.”
“Someone copies approved deal information from the CRM into the finance system.”
“We read incoming documents, find the matching record, and correct missing fields.”
For each, record weekly volume, active staff time, systems involved, common exceptions, and the consequence of a mistake.
Then choose a task with meaningful effort, accessible information, a clear definition of correct, and a safe way to test. A smaller task with a trustworthy baseline can be a better first project than a large, vaguely defined opportunity.
Do not confuse system count with readiness. Two systems with conflicting customer IDs may be harder to automate safely than five systems with reliable identifiers and clear ownership.
This is a familiar integration problem before it is an AI problem. For example, Komar Distribution Services' integration work spans customers' different commerce, ERP, and warehouse environments. That case illustrates the work of connecting operational systems; it is not evidence of AI-generated savings.
The AI readiness checklist: eight checks before your first pilot
Copy these checks into your project brief. For each, write Ready, Needs work, or Unknown, followed by the evidence. Do not average the answers into a reassuring score: missing permission or an unsafe action cannot be offset by a large potential saving.
1. Can you describe the job in one sentence?
Evidence to collect: A clear start, finish, and person responsible for the result.
Example: “When a customer asks where an order is, prepare an accurate reply using verified order and shipment information, then send it to the support agent for approval.”
If not: Watch someone complete three real examples. Write down every handoff, not just the visible final step.
2. Do you know what the work costs today?
Evidence to collect: Weekly volume and active minutes per case, including checking, corrections, and follow-up. Track elapsed waiting time separately.
If not: Keep a short task log for a normal working week. Include everyone touching the same task, without counting their time twice. Flag seasonal peaks instead of treating one busy week as normal.
3. Can the system retrieve facts you would trust?
Evidence to collect: The authoritative source for each important fact, a reliable way to match records, and a rule for stale or conflicting information.
If not: Resolve one concrete gap first—for example, which system owns shipment status. An AI-generated explanation does not make an uncertain delivery date correct.
4. Are access and actions explicitly approved?
Evidence to collect: Which records the automation may read, what it may change, which AI services may receive the data, and who has approved that use. Check retention and access requirements with your security or data owner.
If not: Start with approved, minimized test data and read-only access. Do not treat access to a shared inbox as permission to send every attachment to an external model.
5. Have you separated fixed rules from AI judgment?
Evidence to collect: A step-by-step list marked “fixed rule,” “AI-assisted,” or “human decision.”
If not: Ask: “Would the correct result always follow the same known rule?” Calculating a total, copying a verified ID, and checking an approval threshold normally should not require a language model to improvise.
6. Can you recognize a wrong or unsafe result?
Evidence to collect: Examples of correct output and cases that must stop for help: missing IDs, duplicate requests, conflicting data, unavailable systems, and requests outside the agreed scope.
If not: Write the test cases before choosing a tool. For customer messages, check factual accuracy and unauthorized promises—not just tone. Treat instructions inside incoming emails or documents as untrusted content, not authority to change what the automation is allowed to do.
7. Is somebody responsible when it fails?
Evidence to collect: A named owner, a visible queue for unresolved cases, a pause mechanism, and a safe way to recover without sending duplicate messages or creating duplicate records.
If not: Keep the automation in draft or recommendation mode. “Someone will check the logs” is not an operating plan unless that person, timing, and escalation are clear.
8. Will the result still be worthwhile after review and running costs?
Evidence to collect: Total time saved after checking and rework; setup, platform, model, and support costs; and an agreed quality threshold.
If not: Run a limited comparison against today's process. A faster draft that takes longer to verify is not a productivity gain.
Turn the checklist into a decision
Ready for a controlled pilot: The task, data access, safety boundaries, owner, and success measures are clear. Test with human oversight.
Fix one dependency first: The opportunity is credible, but a specific source, permission, or process rule is missing. Name the fix and its owner.
Keep it human-led for now: You cannot reliably judge correctness or contain the consequences of a mistake. Consider assistance with research or drafting instead of autonomous action.
These are practical planning decisions, not a security certification or a guarantee of production readiness.
The $72,000 question: what could this process be costing you?
Here is an illustrative calculation—not a MindCloud customer result, industry benchmark, or savings promise.
Suppose a team handles 300 order-status requests per week. Each requires six minutes of combined staff work. Use 52 weeks and an assumed blended staff cost of $46.15 per hour, including wages and employment overhead. These are the same annualization assumptions used in the worked example for our assessment.
300 requests × 6 minutes ÷ 60 = 30 staff hours per week.
30 hours × 52 weeks × $46.15 = $71,994 in annual staff effort—approximately $72,000.
That is the cost of the current work, not the amount AI will save. The assessment annualizes a typical week over 52 weeks. If your process is seasonal or runs for fewer weeks, use your actual operating weeks in the worksheet below.
Now break the six minutes apart:
Four minutes finding and checking information.
One minute preparing the answer.
One minute updating the record and completing the request.
Even eliminating the entire one-minute writing step would address only one-sixth of the time. The larger opportunity is obtaining trustworthy information and completing the handoff.
Suppose a pilot tests whether the entire process can fall from six to three active minutes, including review, exceptions, and rework. If sustained, that would free 15 hours per week, equivalent to $35,997 in annual labor capacity at the same assumptions.
Whether that creates a financial saving depends on what happens next. Removing overtime or contractor spending is different from freeing salaried staff to handle more customers. Both can matter; report them separately.
Copy this automation value worksheet
Fill in these numbers with your own evidence:
Annual cases: weekly cases × operating weeks.
Current labor cost: annual cases × current active minutes ÷ 60 × loaded hourly cost.
Potential capacity released: annual cases × reduction in active minutes ÷ 60 × loaded hourly cost.
Recurring operating cost: platform, model usage, hosting, and ongoing support. Include checking and rework either in active minutes or separately—not both.
First-year project cost: setup plus recurring operating costs.
Realizable cash benefit: spending you can actually eliminate or avoid, with finance's agreement.
For a cash ROI calculation, use (realizable first-year cash benefit − first-year project cost) ÷ first-year project cost × 100. Report released capacity separately if it does not reduce spending. Avoid counting an avoided hire, freed staff hours, and increased revenue as three versions of the same benefit.
The useful “aha” is not “AI saves $72,000.” It is “We now know where $72,000 of effort goes, which portion is avoidable, and what we need to prove.”
Build with AI. Run with fixed rules where possible.
Using AI to design automation and using AI every time that automation runs are different decisions.
AI can help describe a process, map fields, propose logic, and draft tests. Once reviewed, some of that work can run as conventional code or fixed business rules. Other steps may still benefit from model inference each time.
In this article, deterministic automation means steps that follow explicit code or rules rather than asking a language model to decide the result. It does not mean the whole system is infallible: bad data, bugs, failed connections, and changing APIs still need controls.
For an order-status process, a sensible division could look like this:
Understand a free-form request: AI may help classify the request or extract a proposed order reference. Validate the result.
Match the customer and order: Use verified identifiers and fixed checks. Stop if the match is ambiguous.
Retrieve shipment facts: Use authorized system connections. Do not ask a model to invent missing facts.
Prepare the response: Use an approved template when sufficient; use AI drafting when variation adds value.
Approve, send, and update the record: Follow explicit permission and approval rules, with duplicate protection and an activity record.
That design reserves AI for ambiguity rather than paying it to rediscover a known rule on every transaction.
Anthropic's December 2024 engineering guide similarly recommends starting with the simplest solution and adding agentic complexity only when justified by performance. Its definition of a “workflow” can still include model calls; a workflow is not automatically token-free. Source: Building effective agents.
Worried about token costs? Measure cost per correct outcome.
A low-priced model call can become expensive when each request triggers long context, multiple steps, repeated attempts, and human cleanup. Conversely, a more expensive model call may be worthwhile if it reliably eliminates substantial work.
The business metric should be cost per correctly completed case, measured alongside completion rate, quality, and turnaround time. The FinOps Foundation explicitly encourages moving AI metrics beyond tokens toward business outcomes. Source: FinOps unit economics.
For your pilot, divide all in-scope operating costs—including failed attempts and human correction—by the number of cases completed to the agreed standard. Keep setup costs visible separately. Compare the same kind of cases before and after; do not hide difficult requests by excluding them from the results.
Ask whoever builds it to specify:
Which steps call a model and why.
Limits on retries, run duration, and spend.
What happens when information is missing or systems fail.
What humans must review and how much time that takes.
How quality and cost changes will be detected after launch.
Do not optimize for the lowest token bill at the expense of the outcome. Optimize for useful work completed reliably at an acceptable total cost.
A practical two-week starting plan
Two weeks can produce a useful decision—not necessarily a production-ready deployment. High-risk processes and complex integrations need more time.
Days 1–3: Observe and measure. Choose one task. Review recent examples with the people doing it. Record active time, volume, exceptions, and authoritative data sources.
Days 4–5: Draw the boundary. Agree on access, actions, approval rules, and the definition of success. Decide which steps need AI. Set quality and cost limits before seeing results.
Days 6–8: Test without uncontrolled actions. Use an approved test environment or draft-only process. Include normal cases and deliberate failures. Compare with examples that were not used to tune the solution. A small sample can expose problems; it cannot establish the safety of rare, high-consequence outcomes.
Days 9–10: Make the decision. Review end-to-end time, correctness, unresolved cases, review burden, and cost. Continue, narrow the scope, fix a dependency, or stop. Decide how the recovered time would actually be used.
For example, a draft-only order-status pilot might require verified customer/order matching, no unsupported delivery promises, visible escalation of missing records, and a reduction in average active time including review. Do not interpret “no errors in this sample” as a guarantee of no future errors.
A useful way to start with Cirra
MindCloud's approach is to build with AI and run deterministically where practical, keeping AI in the steps where interpretation or generation adds value.
Cirra provides a conversational starting point for planning and building connected workflows. Start with a bounded task, not a request to “automate the department.” Review the proposed connections, permissions, logic, and tests before running it. Availability depends on the systems and actions your process needs; AI assistance does not remove that implementation work. See how to create a workflow with Cirra.
Copy and adapt this brief. Leave unknowns as unknowns, and do not include secrets or personal customer data:
Help me plan an automation for [specific task]. It happens [volume] times per week and takes [active minutes] per case across [systems]. The correct outcome is [result]. Our source of truth is [system or unknown]. Separate fixed-rule steps from steps that genuinely need AI. List missing information, required permissions, human approvals, failure cases, and a test plan. Estimate value only from the numbers I provide, label assumptions, and include review time and ongoing costs. Do not enable external actions until we approve the plan.
A useful first result is a testable plan—not an agent with broad permissions.
If you want help choosing the first process, bring one example, the systems involved, and a rough weekly time estimate. We can discuss whether the next step is AI assistance, an integration, fixed-rule automation, or a combination.
You do not need AI everywhere. You need a clear answer to where it removes work, what must be trustworthy, and how you will know it helped.
Find your own starting point
You do not need to finish a pilot before taking the first step. Describe one repetitive task in the free AI Readiness Check, with room to add two other, non-overlapping processes. Hours and staff-cost estimates are optional; leave unknowns blank rather than guessing.
Your emailed four-page PDF includes:
Your annual effort estimate: see what your reported weekly work adds up to, with the assumptions visible. This is workload cost, not promised savings.
A readiness verdict for your primary task: what is in place and what to address before a trial. Additional processes expand the workload total; they are not separately assessed for readiness.
Where AI, fixed rules, and people fit: avoid using a model for every predictable step.
An action checklist and copyable Cirra starter: begin with made-up examples, then measure total time, correctness, and cost per completed case.
The assessment is based on your answers, not an audit of your systems or approval to deploy. You can use the checklist with your own team; Cirra is an optional next step.
