Say you've done the hard part. You listed the recurring work in your business, ranked it, and picked one job for AI to take on first. (If you haven't, start with where to put your first lever.)
The next mistake is the expensive one: building before you know whether the work underneath can carry it.
Automation copies what's already there. If the job runs on one person's memory, three spreadsheets, and a habit of calling the client when something's missing, a system will copy that too, only faster and with nobody noticing the gaps until a customer does. Most builds look fine in the demo. The trouble shows up a few weeks in, when real inputs arrive.
So before anyone builds anything, check three things: the people, the process, and the data. You need an afternoon, the person who actually does the work, and twenty recent real examples of the job.
People: who owns the result, and who catches the exceptions
Start here, because it's the check owners most often skip. It feels like a technology decision, so it gets treated like one.
Ask four questions about the job you picked.
Who does it today? A name, not a department. And were they part of choosing it? The person who does the work knows where it stalls. If they hear about the project after it's built, you've lost the cheapest source of information you have.
Who owns the output once a system produces it? Someone has to read the draft, approve the quote, or confirm the update went out. "The team" isn't an answer. If nobody owns the output, it piles up unreviewed, and within a few weeks people go back to doing it the old way.
Who handles the exceptions? Every job has cases that don't fit: the missing document, the unusual request, the client who replies to the wrong email. Decide now who those go to and how they'll know.
Does anything wait on you? If the job stalls on your approval, AI will speed the work right up to your desk and stop there. That's worth knowing before you spend money. We wrote more about this in owner dependency and AI implementation.
If you can't name the owner and the exception handler, don't build yet. Assign them first. It costs nothing and it's the most common reason good tools end up unused.
Process: watch the work, don't just describe it
Ask the person who does the job to show you the last three times they did it. Not how it's supposed to go. How it went.
Write down what you see: what starts the job, what information they need, where they get it, what decisions they make, who they hand it to, and how they know it's done. You'll usually find a few surprises. A step that exists only in someone's head. Two people doing it two different ways. A workaround everyone forgot was a workaround. A lot of "it depends."
Then run one test. Could a capable new hire do this job from your written steps alone? If not, a system can't either, because written steps are exactly what you'll be handing it.
This is where the order matters: cut, standardize, then automate. Cut the steps that exist for reasons nobody remembers. Standardize what's left so it happens the same way each time. Only then is it ready for automation. If the process is genuinely broken (work bouncing between people, unclear handoffs, rework on most jobs), fix the sequence first. Automating a broken process just makes it fail faster.
Data: pull twenty real examples
Descriptions of data are always cleaner than the data. So skip the description and pull the last twenty instances of the job.
For each one, note:
- Where the inputs lived: inbox, CRM, spreadsheet, shared drive, someone's notes
- Whether they were complete when the work started
- Whether they came in a consistent format
- Whether someone had to call, chase, or guess to finish
Then ask two practical questions. Can a system reach that information without a person copying it from one place to another? And is any of it sensitive (client financials, health information, employee records), so you need to be deliberate about who and what can see it?
Count honestly. Here's a hypothetical: say you picked proposal drafting, and six of your twenty examples needed someone to chase missing scope details before the proposal could start. That doesn't mean AI is a bad fit. It means the first fix might be intake, a required field or a short form, and the drafting gets easier once that's in place. The check just told you something a vendor demo never would.
Read the results: proceed, fix first, or pick another job
Each check lands in one of three places.
Proceed. Owners are named, the process is written and holds up to the new-hire test, and most of your twenty examples were clean. Write down your expected result before you build: today this job happens this often and takes this long; after the change we expect this metric to reach this level, and this person checks it.
Fix first. The gaps are real but small: an unnamed owner, a missing required field, steps that need writing down. These usually take days, not months. Do them, then build.
Pick another job. The process is broken in ways that need their own project, or the data is scattered across five places nobody owns. Make fixing that its own piece of work, and move to the next candidate on your list for the first build.
Two cautions. First, don't let the check turn into a six-month documentation project. The goal is enough clarity to build one thing well. Second, count the fix-first work in your costs. Time spent cleaning data or rewriting a process is part of what the project really costs, and leaving it out makes the return look better than it is. We walked through how to count that in AI ROI for small businesses.
Put it on one page
Before anything gets built, you should be able to fill this out:
Job: [the one job you picked]
People: Does it today: [name]. Owns the output: [name]. Handles exceptions: [name]. Waits on owner approval: [yes/no]
Process: Starts when: [trigger]. Steps written and tested by someone who doesn't do the job: [yes/no]. Known workarounds: [list]
Data: Inputs live in: [systems]. Of 20 recent examples: [#] clean, [#] incomplete, [#] inconsistent. System can reach it without copying: [yes/no]. Sensitive information: [yes/no, what]
Decision: Proceed / Fix first ([what, who, by when]) / Pick another job
That page is the difference between a build you can measure and one you end up arguing about. It also makes any vendor or partner conversation shorter, because you're handing them facts about your business instead of hopes.
When we work with an owner on this, it's the core of a Blueprint session: the opportunity sized in their numbers, the roadblocks named, and the build mapped in the right order. If you want to know which roadblocks tend to show up, our piece on why AI implementation fails in small businesses covers the usual ones.
If you'd like a starting picture of what AI could change in your industry, get the free AI Leverage Report. If you've already picked your first job and want a second set of eyes on these three checks, book a free 30-minute AI Leverage Call and bring your one-page note.
