Readiness for AI has nothing to do with how many tools you have tried. It is a short list of conditions that either hold in your business or do not, and you can check them in an afternoon without buying anything. Below is the list we work through before recommending a first implementation. Pick one specific task you would like to automate and answer these about that task, not about your business in general. A business can be ready for one workflow and nowhere near ready for the one next to it.

1. The workflow itself

Can you write the whole task on one page? Trigger, input, current steps, who does it, what the output looks like, what the exceptions are, and who makes the final call. If you cannot write it, nobody can build it. This is the single most common blocker and it is not a technical one.

Do two people on your team do it the same way? Ask them separately. If the answers differ and nobody can say which is correct, you have a management decision to make first. Automating an unresolved process makes the inconsistency faster and harder to see.

Does it happen often enough to matter? Count how many times it ran last month. A task that occurs twice a month rarely repays the setup, the testing, and the maintenance, however annoying it is. Frequency, not irritation, is the qualifier.

Would something simpler fix it? Before anything else, check whether a form field, a saved reply, a CRM setting, a routing rule, a template, or a checklist solves the problem. Cheaper to build, cheaper to run, and your staff can fix it themselves at four o'clock on a Friday.

2. The information behind it

Is there one current source of truth? Whatever the system needs to know, your services, prices, coverage area, policies, warranty terms, hours, has to live somewhere current and owned. Not in three documents that disagree.

Do you know which of your documents are out of date? Open the three files your team quotes from most and check the last edit. If the assistant reads stale information, it will state it with more confidence than any of your staff would.

Who maintains it after launch? Name the person. Knowledge decays every time you change a price, add a service, or hire someone. An assistant nobody updates becomes wrong slowly, which is worse than being wrong immediately, because nobody notices.

3. Access, data, and risk

Can you say exactly what the system may read, draft, send, and change? Those are four different permissions and they carry very different consequences. Most first implementations should read and draft, and stop there.

Have you marked what must never be sent to a model? Customer payment details, identity documents, health information, anything under a confidentiality agreement, staff records. Decide this before the build, in writing, not after someone pastes a contract into a chat window.

Does the value justify the access it needs? If the workflow only pays off when the system has broad permissions across your business, that is a poor first implementation regardless of how good the idea is. Start where the blast radius is small.

Is there a stop rule? Something specific that makes the system hand the task to a person: an unfamiliar request, a complaint, a price outside the published range, a customer asking for a person. Write the rule down before launch.

4. Ownership and review

Is there one owner? One named person who checks the output, catches the failures, and has the authority to switch it off. Shared ownership means nobody watches the exception queue, and the exception queue is where the damage accumulates.

Is the output reviewable in seconds, not minutes? If checking the machine's work takes nearly as long as doing the work, the implementation saves nothing. Good candidates produce output a person can approve at a glance.

Does the reviewer have somewhere to put corrections? A correction that lives only in one person's memory does not improve the system. There has to be a place where fixes go back into the instructions or the knowledge.

5. Measurement

Do you have a before number? Response time, handling time, missing-field rate, appointment conversion, or staff hours on the task. Take the measurement this week, before anything is built. Nearly every disappointing AI project is one where nobody recorded the baseline and so nobody can tell whether it helped.

Do you know what result would justify the running cost? Name it in advance. Twenty minutes a day, or a first response inside five minutes, or half as many quotes going out with a field missing. A target set after the fact is not a target.

Do you know what would make you turn it off? The failure condition matters as much as the success one, and agreeing on it while everyone is still optimistic is far easier than agreeing on it later.

How to read your answers

The five sections are not equal. A no in section one means the answer is not AI yet, and no amount of good tooling changes that: an undefined process cannot be automated, only accelerated. A no in section three means stop and resolve it, because permissions and data exposure are the failures that cost more than the project. A no in section two or five is fixable in a week or two of unglamorous work, and it is work worth doing whether or not you ever build anything, because clean service information and a known baseline make everything else in the business easier to run.

If most answers are yes for one specific task, you have found your first implementation. Narrow it further than feels necessary. One workflow, one owner, one source of truth, one review point, operating next week.

What comes after the checklist

If you would rather have someone else run this against your business, that is what an AI readiness audit is. It reviews the workflow, the knowledge, the systems, and the risk behind one problem, and the recommendation may well be to use existing software, build a basic automation, write a checklist, or clean up the process first. If the workflow is a fit, it can lead to a first focused AI implementation priced at $1,500 flat.

Either way, the work in the list above stays yours, and none of it is wasted if the answer turns out to be no. Two pieces go deeper on the parts people get wrong most often: how to set read, draft, and execute permissions, and what a complete AI system looks like from source to review.

When you have one task that passes most of this list, that task is the conversation worth having. Bring it to us with the trigger, the owner, and the before number, and we will tell you whether it is a build or a checklist.