Someone has asked what the company is doing with AI, and now there’s a number attached. A subscription to approve. A vendor quote. A line in next quarter’s budget.
You don’t have a data team to ask. You have a few people who’ve tried ChatGPT or Copilot, a demo that made the current process look painfully manual, and a suspicion that the money could land somewhere that changes nothing.
The expensive failure happens before anyone compares tools. Something gets bought before the company has decided what work should change, what information the system can use, who’s accountable for the result, and how anyone will know the work got better.
Six things have to be true before AI spending has a fair chance of improving the work: usable data and context, a clear workflow, a way to measure the change, a named owner, a review step with real authority, and a plan for adoption. Each has a test you can run this week without technical help, and each failure points to a fix that’s usually less technical than the tool on the table.
Start With One Workflow, Not the Company
“Are we ready for AI?” has no useful answer at company level. Readiness is a property of one workflow. A team may be ready to summarize approved internal material or search a well-maintained knowledge base while being nowhere near ready for a workflow that handles sensitive customer information or writes to operational systems.
So pick one. Choose a recurring piece of work that’s slow, inconsistent, or repetitive today: the weekly report someone assembles from several exports, say, or the inbound inquiries someone sorts by hand. Every test below is asked about that one workflow.
The six answers will come out uneven. They have different owners and different fixes, so keep them separate long enough to see which one needs attention first.
Know What Goes In and Where It Came From
An AI tool works from the information it’s given: records, documents, exports, and the definitions behind them. The data and context constraint asks whether that information is current, permitted for this use, and understood by someone responsible for it. It doesn’t ask for perfectly clean data.
The problem nobody notices is usually a definition. “Customer” may mean a closed-won deal in the CRM, an active subscriber in billing, or anyone who ever submitted a form. An AI assistant won’t resolve that disagreement. It’ll reproduce whichever definition was easiest to connect.
The test. If you had to hand someone the data this workflow depends on, could you? Find the source of the last input the work used. Ask who owns that source, when it was last checked for duplicates or gaps, and whether the information was collected under terms that permit this use.
If it fails. Repair before you buy. Resolve one definition dispute. Trace one important field to its source. Name the person who can approve or halt its use. If the information would go to a vendor, find out what leaves your systems and where it goes next.
Go deeper. The Browser Didn’t Force Your Hand. Your AI Roadmap Will. puts the data work in order.
Draw the Work Before You Change It
The workflow constraint is whether anyone can see the work as it happens today: the inputs, the handoffs, the exceptions, what happens downstream, and which steps a person owns. When exceptions are handled from memory and the answer depends on who’s working that day, automation adds a disconnected process rather than improving the existing one.
The test. Sit down with the person who runs the workflow every week. They know where it breaks. Map what happens now, who does it, what information it depends on, and where the exceptions go. Then ask the team to describe what a bad answer would look like. If nobody can, the tool’s output has nothing to be checked against.
If it fails. The next move is the process, and it may involve no AI at all. Sometimes the answer is a better intake form, a documented procedure, or cleaner reporting definitions. Once the map exists, each step gets its own decision: automate, assist, simplify first, or keep human.
Go deeper. You’re Not AI-Ready. One Workflow Might Be. sets out the possible moves.
Decide How You’ll Know It Got Better
Measurement means the team can name what should improve and how it’ll be observed. Without that, the pilot becomes a demo with no viable success condition.
A draft can arrive faster while the workflow gets harder to manage once review, exceptions, and rework are counted. “We saved time” is the beginning of the analysis.
The test. Ask three people close to the workflow to write down, separately, the problem the tool is meant to solve. Compare the three answers. Then try to finish two sentences: “This will have worked when…” and “The failure we couldn’t accept is…” Note how the work goes today (how long it takes, how often it comes back for rework) so there’s something to compare against later.
If it fails. Write the decision statement before anything else: the problem, the intended users, the desired outcome, the constraints, and how success gets measured. If three people named three different problems, settle that first. Every later decision about the tool gets checked against it.
Go deeper. AI Makes the First Draft Cheaper. Trust Still Costs Money. separates task, workflow, and outcome evidence.
Put a Name on It
Ownership means a named person owns the decision, the maintenance, the monitoring, and the escalation. A mailing list doesn’t count. Without a name, the workflow becomes an orphaned pilot, and every question about it routes to whoever’s available rather than whoever’s accountable.
The test. Write one name beside each of these: who decides whether the output is good enough, who maintains it when a system or a definition changes, who pays for it, and who can pause it when the output is unreliable. Then check that person has the time. An owner with forty other things to do is a name in a document.
If it fails. Assign the owner, the support path, and a review cadence before launch. License cost is the visible part, so count the hours before declaring a tool cheap. You don’t need a large data team for this. You do need someone responsible.
Go deeper. The Integration Tax Just Got Cheaper counts what a tool costs after the subscription.
Give the Reviewer the Power to Say No
Governance, in its useful form, is the visible ownership, definitions, permissions, quality checks, and escalation paths that let a team use information in ways it can explain and defend. A small company doesn’t need an enterprise program. It needs controls in proportion to the risk, and more of them when the data is sensitive, the decision carries consequence for a person, or an error would be hard to catch.
The control most plans lean on is human review, and it works only under five conditions. The reviewer needs expertise and context, time, authority, an escalation path, and incentives that permit refusal.
A review step missing any of the five can still produce a signature. It can’t be counted on to produce oversight.
The test. Ask the person you’d name as reviewer three questions. What are you looking for? What evidence do you need to decide? What can you do when you find a problem? Then ask the plan one more: what happens if the reviewer does nothing? If the output proceeds anyway, you have a timeout with a human decoration on it.
If it fails. Choose a review model on purpose: every output, a sample, exceptions only, or no routine review with logging and fast rollback. Write down who can pause the workflow and who gets told. And keep AI out of the final decision where the result materially affects someone’s livelihood, safety, rights, health, or access to essential services.
Go deeper. You Put a Human in the Loop. Can They Say No? has both lists in full.
Count Adoption as Evidence
A system people route around hasn’t created much value. A system people use enthusiastically but can’t challenge or safely correct isn’t a success either. Adoption has to be planned: who needs to learn what, where people request a change, and whether the team can run the thing without calling whoever built it.
The test. For a tool already in use, check the last two weeks of usage against the list of people who were expected to use it. Then ask one regular user what they did with the time it saved last week. If the answer is “checked its output,” write that down. For a tool you haven’t bought, read the plan to its last page. If it ends at the demo, adoption hasn’t been planned.
If it fails. Find out whether the cause is the tool, the data, or the habit before spending more. And bring the person who does the work into the decision, alongside the person who owns the budget.
Go deeper. A Great Solution Design Makes the Next One Easier covers writing for the people who have to use it.
Six Tests on One Page
Run these against one workflow. Each line is a test, then what to do first if it fails.
- Data and context. Could you hand someone the data today, and say who owns the source? If not: settle one definition, trace one field, and name who can approve its use.
- Workflow. Can the person who runs it map the steps and exceptions, and can the team describe a bad answer? If not: fix or document the process before adding technology.
- Measurement. Do three people name the same problem, and can you finish “this will have worked when…”? If not: write the decision statement, with a success measure.
- Ownership. Is there one name, with time, for deciding, maintaining, paying, and pausing? If not: assign the owner and count the hours before launch.
- Governance and review. Can the reviewer say what they’re looking for and what they can do about it? If not: pick a review model and name who can stop it.
- Adoption. Does usage match the list of expected users, and does the plan go past the demo? If not: find out whether it’s the tool, the data, or the habit.
Fix the First Thing That Failed
A workflow can fail more than one test. Resist the long roadmap. Name the one failure the others depend on and start there. A review step can’t be designed for a workflow nobody has drawn.
If you’d like a quick reflection first, the free Snapshot asks five questions about one tool or workflow your team already uses. It takes about five minutes, needs no email, and names one thing to check first, based on your answers rather than an evidence review.
If one workflow and one decision are in front of you, a Working Session works through it in ninety minutes with the person who runs the work. If several efforts are competing for the same budget, or people disagree about what’s blocking progress, that’s what the AI Foundation Diagnostic is for. It ends with a named primary blocker and a sequenced 90-day plan.
A new model, platform, or subscription can’t decide what the workflow is for, settle competing definitions, assign ownership, or create the evidence that the work improved.
None of the six comes with the tool. All six can be started this week.
