An AI readiness assessment for a real business workflow.

An AI readiness assessment becomes useful when it describes a particular job: preparing an internal answer, classifying an incoming request, extracting fields from a document, or drafting work for review. “Our team wants AI” does not identify the inputs, decision or finish that a system needs.

Write the trigger, the current operator, the information involved and the useful output. Identify where work stalls today. A first automation decision compares potential jobs; this assessment examines whether one selected job has enough clarity to pilot.

For each row, record the evidence you have, the question you cannot yet answer and who will resolve it. A missing answer should become a next action rather than a guessed score. This is a planning worksheet, not a certification or an audit finding.

A workflow may look ready while its source documents are outdated, its records disagree, or its intended users cannot access the information they need. Inspect the real source boundary before testing an assistant over it. Decide who can read each source and who can change it.

A private knowledge system needs permission-aware retrieval. A document processing workflow needs supported file types and checkable fields. A CRM integration needs record matching and source ownership. These are different readiness questions even when all three projects use AI.

List the actions that would affect another person, a customer record, a schedule or a public channel. Decide what needs review and how the operator will see confirmation or failure. An assistant producing a plausible draft is different from a destination system accepting a change.

Test a missing input, an unsupported request, an unavailable tool and an interrupted action. The pilot should stop or expose uncertainty where it cannot prove the outcome. A successful normal case does not settle those operating questions.

Consider a fictional service business that wants an assistant to summarize incoming requests and assign follow-up. The request source is known, but the team has no consistent assignment rule and does not know whether the CRM supports the required write. The assessment has exposed two implementation questions, not produced a verdict about the whole company.

A useful first test could prepare a summary and proposed owner for staff review using representative requests. Meanwhile the business defines the assignment rule and verifies CRM access. The pilot measures corrections, review time and unresolved requests. This example illustrates a possible assessment; it is not a delivered client result.

The assessment may point to an existing product setting, an ordinary integration, an AI-assisted draft, or custom software. Keep the useful finish constant while comparing the options. Include setup, review effort, usage, maintenance and recovery in the operating cost.

Use custom software versus SaaS when the choice is build or buy. Use the AI Build Session to discuss a first-system direction with Bud. The goal is a scope the business can evaluate rather than a long roadmap whose assumptions nobody has tested.

A useful assessment record contains the chosen workflow, the six evidence checks, unresolved questions, the proposed first test and the people responsible for the next step. Keep private records and credentials out of an initial public inquiry. Explain the operating pattern in general terms.

ShepBuild is based in Jackson, serving Central Mississippi including Madison. The guided brief helps describe one problem for Bud to review. Workflow training can help the team practice the agreed job once a suitable process is ready.