Is Your Business Ready for AI? A Practical Readiness Assessment.

AI readiness is not a measure of how many tools a business has purchased. It is the ability to choose a useful problem, provide the information needed to solve it, evaluate the result, and assign responsibility when the system needs attention. A company can be technically enthusiastic and operationally unprepared. It may have modern software but unclear ownership, inconsistent records, or a process that changes depending on who is working that day. This guide offers a practical readiness assessment for business owners considering their first serious AI initiative. It is a decision aid, not a certification or a prediction of financial returns.

Start with a business outcome

Describe what should improve in terms people can observe. Examples include fewer unassigned enquiries, faster preparation of an internal report, or less repeated copying between systems. Avoid starting with a tool category. Buying an AI agent does not explain which task it should perform or how the business will know whether it helped. Ask the process owner to describe the current problem using recent examples. A specific account of what happened is more useful than a general statement that the team is inefficient. Record the frequency, the people involved, and the consequence of leaving the problem unresolved.

Check whether the process is understood

A workflow does not need to be perfect before improvement begins, but its main steps and exceptions should be visible. If nobody can explain how work reaches completion, automation may simply move confusion faster. Follow one ordinary case from start to finish. Then follow an exception. Identify who makes decisions, where information is stored, and which handoffs depend on memory or informal messages. If the team disagrees about the process, resolve the important differences before selecting technology. Some disagreement may reveal legitimate variants, such as different treatment for existing customers and new enquiries. Those variants need explicit rules rather than an assumption that everyone works the same way.

Assess the information available

List the information needed for the proposed task and its source. Is it complete enough? Can the business access it through an appropriate account? Is there a reliable way to identify the relevant customer, request, or document? Data quality problems should be described specifically. "Our data is messy" is difficult to act on. "A third of these sample requests have no assigned owner" or "the same customer appears under several identifiers" points toward a repair task. Use actual measured figures if you publish such findings; do not estimate them casually. Also check whether the source is authoritative. A shared folder containing several policy drafts is not the same as an approved knowledge base.

Identify the decisions that need human judgement

List what the system may suggest, what it may do automatically, and what requires approval. These boundaries should reflect the consequences of an error. Drafting a response for review may be a reasonable starting point. Making a binding commitment to a customer is a different responsibility. Treating both as ordinary text generation hides an important business decision. Ask who will review the outputs and whether that person has time to do so. Human review is not a meaningful control if it is assigned to an already overloaded queue with no agreed response expectation.

Check ownership and recovery

Name the person accountable for the business outcome and the person who can investigate technical problems. Define what happens if the workflow stops or produces an unacceptable result. The team should know how to pause the system, continue manually, and preserve unfinished work. A pilot is easier to trust when people understand that they can stop it without losing control of the process. The NIST AI Risk Management Framework organizes risk work around governance, context, measurement, and management. For a small business, the practical implication is to connect responsibilities and evaluation to the actual use case rather than treating risk as a generic checklist.

Evaluate the team's ability to adopt the change

Ask the people doing the work what would make the proposed system useful or frustrating. They may identify hidden effort that a management-level process map misses. Consider training, access, working hours, and the devices people use. A workflow designed around a desktop dashboard may fail if the responsible staff spend most of the day away from a desk. Be clear about what changes in the role. If the system drafts records, employees may need to become better reviewers. If it routes requests, managers may need to maintain routing rules. Adoption requires these responsibilities to be recognized, not assumed.

Use a simple readiness worksheet

For each area below, record evidence and an unresolved question:

• Outcome: the problem, its frequency, and the desired improvement.
• Process: main steps, exceptions, and current owner.
• Information: sources, quality issues, and access.
• Decisions: permitted actions and required approvals.
• Operation: monitoring, recovery, and support ownership.
• Adoption: affected roles, training, and feedback.

Mark an area ready only when the supporting evidence exists. A named owner is stronger evidence than "operations will handle it." A tested export is stronger than an assumption that data can be retrieved later. Avoid adding the marks into a universal maturity score. A single serious gap, such as no permission to use the required data, can block a project even if the other areas look strong.

Decide whether to pilot, prepare, or stop

A business with a clear problem, accessible information, and an accountable owner may be ready for a limited pilot. Keep the scope narrow enough to evaluate and reverse. If the opportunity is promising but the source information is unreliable, begin with preparation. That could mean clarifying statuses, cleaning a reference list, or documenting the approval process. Some ideas should be stopped or deferred. If the outcome is low-value, the process is rare, or the consequences are difficult to control, a simpler improvement may be more appropriate. Readiness assessment is useful partly because it gives permission to make that decision before significant spending.

What to bring to a consultation

Prepare a recent example of the problem, a rough process map, the applications involved, and the people who own the work. Include the awkward cases rather than showing only the cleanest example. A useful consultation should help narrow the opportunity and identify the next piece of evidence needed. It should not require you to pretend that the business already has a complete AI strategy. Does a small business need a formal AI department? Not necessarily. It does need clear responsibility for each deployed use case and access to appropriate implementation and review skills. Should we wait until our data is perfect? No, but the required information must be good enough for the specific task and its consequences. A bounded pilot can reveal the most important gaps.

Book a conversation with AI with Akshay to examine one operational problem and decide whether the next step should be preparation, a pilot, or a simpler process change.