The short answer
Most businesses asking whether they are ready are ready for something smaller than they are imagining. The readiness question is really seven questions about process, ownership, data, and cost, and you can answer all of them yourself in an afternoon.
Readiness is not a technology question
The phrase makes it sound like a maturity level, as though a business needs to reach some threshold of sophistication before it qualifies. That is not how it works, and treating it that way mostly benefits people selling readiness assessments.
A two-person business with one well-defined bottleneck is more ready than a fifty-person business with four vague ambitions. Readiness is about the specificity of the problem, not the size of the company.
The seven questions
1. Can you name the specific problem in one sentence?
Not a goal like being more efficient or using AI better. A problem: calls go to voicemail between four and seven every day, and about a third of those callers never call back. Vagueness at this stage becomes budget overrun later, because the project spends its first phase discovering what it was for.
2. Does the process exist in a form two people would describe the same way?
Ask two employees to describe it separately. If the descriptions differ materially, the process is informal, which is fine but means the first work is writing it down. Automating an undefined process just picks one person's version and surprises everyone else.
3. What does the problem cost you?
A rough number is enough. If a third of after-hours callers never call back, and you get twenty after-hours calls a month, and a job is worth several hundred dollars, you can estimate the annual cost in about two minutes. That number sets your budget and tells you whether to bother.
4. Who will own it after launch?
Name a person, not a role or a committee. That person needs to see what the system is doing, have authority to switch it off, and actually look at it on a schedule. Projects without a named owner drift and then fail quietly.
5. What condition is your data in, really?
Open your customer records and read a hundred of them. Not the schema, the actual rows. Count duplicates, inconsistent formats, and blank required fields. Anything that reasons over those records inherits their condition, so it is better to know now.
6. What must it never be allowed to do?
Write this list before anyone builds anything. Never quote a price. Never promise emergency availability. Never give clinical or legal advice. Never contact someone who opted out. This list is more useful than the feature list, because it is what keeps a project from producing a story you have to apologize for.
7. How will you know in ninety days whether it worked?
Pick a business number you already track: booked jobs, response time, hours spent on a task, quotes that got a second contact. Activity numbers like messages sent are not evidence. Decide the measure before the build, because deciding afterward guarantees a flattering answer.
Reading your answers
| If this is true | What it means |
|---|---|
| You answered all seven concretely | Ready. Start with the single smallest version that addresses question one. |
| Clear on 1, 3, 4 and 6 but vague on 2 | Ready, but the first phase is documenting the process. Budget for it openly. |
| Vague on question 3 | Not ready to spend. You cannot size a solution to an unquantified problem. |
| Cannot name an owner | Not ready. Solve this before anything else, because it is the cheapest failure to prevent. |
| Data is a mess | Ready for a narrower project that avoids those records, or for a cleanup phase first. |
Notice that only two of these say not ready, and both are fixable in a week without hiring anyone. That is the usual outcome. Most businesses asking the question are closer than they think, and the correction needed is scope rather than sophistication.
Where to actually start
The highest-return first project in a small service business is almost always the same shape: something that protects the first response to a new customer. Not because it is exciting, but because the cost of a missed inquiry is easy to quantify, the process is usually simple, and the improvement shows up in a number the owner already watches.
Common versions of that first project:
- Making sure inquiries that arrive outside business hours get acknowledged and reach a person.
- Following up on quotes that went quiet, consistently, without anyone having to remember.
- Capturing and preserving where an inquiry came from, so marketing spend can be judged.
- Getting the details a dispatcher or scheduler needs captured on the first contact instead of the third.
Each of these is small, measurable in ninety days, and does not require the business to reorganize itself first. If they work, the next project is easier to justify. If they do not, you have lost a small amount of money and learned something specific.
Questions people ask about this
01Is my business ready for AI?+
Probably, for something smaller than you are imagining. Readiness depends on whether you can name one specific problem, describe the process consistently, estimate what the problem costs, name a person to own the result, know your data condition, list what the system must never do, and define how you will judge it in ninety days.
02Does my business need to be a certain size to use AI?+
No. A two-person business with one well-defined bottleneck is readier than a fifty-person business with four vague ambitions. Specificity of the problem matters much more than size or technical sophistication.
03What should a small business automate first?+
Usually something that protects the first response to a new inquiry, such as after-hours acknowledgment, quote follow-up, or capturing lead source. These are simple, cheap to test, and show up in a number the owner already watches within ninety days.
04How much should a small business budget for a first AI project?+
Size it against what the problem costs you rather than against a market rate. If missed after-hours calls cost several thousand dollars a year, that number sets the ceiling for solving it. If you cannot estimate the cost, that is a sign to define the problem further before spending.
05What is the most important thing to decide before starting?+
What the system must never be allowed to do, and who owns it after launch. Those two answers prevent more failures than any technical decision, and both are free to make.