AI Adoption: Audit Your Processes Before You Buy a Tool
Published 2026-09-26 · Updated 2026-10-13 · 7 min read · ShooWork (FREECO CO., LTD.)
The first step in AI adoption isn't buying software — it's a one-hour process audit. Here's the three-filter method we use, and the traps to skip.
If you are trying to work out where to start with AI in your company, here is the whole answer in one line: open a spreadsheet, not a vendor's pricing page. The first step is a process audit — a plain list of what your team actually does every week, how often each thing happens, how many hours it eats, and whether the rules can be written down. Choosing a model, a platform or a subscription comes fourth or fifth. It is not first.
We hear the same opening line from most of the people who come to us: "We want to adopt AI — what can you build for us?" It sounds proactive, and it is the most reliable predictor of failure we know. The question assumes AI is something you buy and bolt on, like a printer. It isn't. AI replaces a slice of a process, so until you know which processes you have and which ones are quietly burning payroll, there is nowhere to put it.
We say this from the inside. We run ShooWork, our own AI tool platform — including ShooWork Clip (our video-editing engine), ShooWork Write (SEO articles) and ShooWork Ads (Google Ads tooling). Every one of those features went through the same sequence: audit the process, prove the value on something small, then build. The times we skipped the audit, we built things nobody opened. Here is the method, including the parts where it bites.
Buying first is the most expensive way to start
The script is always the same. Someone attends a conference, or a friend raves about a tool, and an enterprise subscription appears on the company card. An email goes out telling the team to "start using AI." Three months later the card is still being charged and the login count is close to zero.
The tool is usually fine. The problem is that nobody could name the specific job it was hired to do. The tool went looking for a problem instead of a problem looking for a tool, and when the order is that way round, no amount of model quality rescues it. A frontier model pointed at nothing produces nothing.
The number one cause of failed AI adoption isn't weak technology. It's picking the answer before you have a question.
The real damage is what the team concludes afterwards: "AI doesn't work for a business like ours." That conclusion is wrong, and it is sticky. It was never a fit problem, it was an aim problem — but the next person who proposes anything AI-shaped now has to argue against a failed project everyone remembers.
Three filters that decide whether a process is worth handing over
When we look at a step in a workflow and ask whether AI should touch it, we check three things. All three have to be true.
- Frequency. Something you do three times a month has almost no automation upside — you will spend more time building than you ever save. Something you do thirty times a day has real compression room. Frequency is the denominator in every ROI calculation you are about to run.
- Clear rules. Simple test: could you teach a new hire to do this with a one-page SOP? If yes, a model can probably learn it too. If the honest answer is "you just get a feel for it after a year," today's models will struggle in exactly the places a new hire would — except they will struggle confidently, which is worse.
- Human hours. Whose time does this eat right now, and how many hours a week? If you can't produce a number, go ask the person doing it. The answer is routinely two to three times higher than management assumes, because the invisible part — the chasing, the reformatting, the double-checking — never made it into anyone's job description.
From our own operations: support ticket triage, first-draft product copy, social asset generation and transcript cleanup all hit three out of three. Meanwhile, "decide what to stock next quarter" mixes market intuition with incomplete data, and we still do that with humans. Not because it's sacred — because it fails the second filter and we know it.
The audit itself: one spreadsheet, four columns, one hour
You do not need a consulting deck for this. Open a spreadsheet with four columns:
- Process step — one line, concrete. "Reply to shipping-status emails," not "customer service."
- Hours per week — a real estimate from the person who does it.
- Can the rules be written as an SOP? — yes / partly / no.
- Cost of getting it wrong — what actually happens if an output is wrong and nobody catches it.
Then the part most companies get wrong: have the people who perform the work fill it in, not their managers. Managers describe the process as designed. Operators describe the process as run, workarounds included — and the workarounds are usually where the hours are hiding. Give each team an hour. That's enough.
Sort by hours per week multiplied by rule clarity. The top three rows are your candidate list. That's the entire audit. If it takes more than a week of calendar time, you're overthinking it. And if you want those saved hours converted into a number your finance lead will accept, we wrote that up separately in how to calculate AI ROI.
Your first project should be cheap to get wrong
Here's the counterintuitive part. The process at the top of your sorted list is often not the one to start with. Do not make your first AI project one where a mistake is expensive.
Invoice amounts, medical or dosage information, regulatory filings, anything with a legal consequence — those are real opportunities, and they are terrible first projects. Your team has no calibration yet for where models fail, what a confident-but-wrong output looks like, or how much review a given output needs. You want to learn that on something where the worst case is "we redo it."
Good first projects: internal document summaries, drafting (not sending) support replies, meeting notes, transcript cleanup, first-pass ad copy that a human approves before it goes live. The goal of project one is not maximum savings. It's trust and calibration. Once your team can predict where the model breaks, you can move up the risk curve deliberately — and you'll be right about how much human review the risky process needs, instead of guessing.
Only now does the technology choice matter
At this point you're holding something useful: a specific step, a specific frequency, specific rules and a specific failure cost. Now questions like "Claude or GPT," "do we need an API integration," "do we need retrieval over our own documents" have real decision criteria behind them, instead of being settled by whoever pitched you most recently. We laid out that comparison in how to choose an LLM model.
Very often the audit also reveals that step one needs no engineering at all. Take an off-the-shelf tool, write a genuinely good prompt, run the process manually for two weeks, and measure. If the output isn't good enough at that scale, a custom build won't save it — you'll just spend a lot more money discovering the same thing. If it is good enough, you now have two weeks of evidence to justify the build. That habit has saved us real money; the mechanics are in why your AI project needs a PoC first.
A first-90-days shape that actually works
Weeks 1–2: run the audit. Spreadsheet, operators filling it in, sorted list, top three candidates, and one low-risk candidate chosen as project one.
Weeks 3–6: manual pilot. Off-the-shelf tools, real inputs, one named owner. Log every output and whether a human had to fix it. Your success metric is the correction rate, not enthusiasm. Under roughly 20% correction on real work, you have something worth keeping.
Weeks 7–12: build the thin integration that removes the copy-paste, or kill it and move to candidate two. Both are wins. Killing a project at week seven with a documented reason is a functioning process, not a failure. The actual failure mode is the subscription nobody cancels because nobody wants to admit it isn't being used.
One more thing worth saying out loud: some processes should not be handed to AI at all, and a good audit tells you that in week one instead of month nine. If you want a low-commitment way to get calibrated on what current tools can and can't do before you commit budget, our free tools are a reasonable place to build that instinct.
The whole takeaway fits on a sticky note: AI adoption starts with a spreadsheet, not a purchase order.
FAQ
Q: How long should a process audit actually take?
About a week of calendar time, and roughly one hour per team of actual work. If it stretches into a multi-month discovery exercise, someone has turned it into a project of its own. The output is a sorted spreadsheet with three candidate processes on top — not a report.
Q: What if our processes aren't documented at all?
That's the normal case, and it's not a blocker — the audit is the documentation. Ask each operator to describe what they did yesterday, step by step, and write it down. If a step can't be described clearly enough to write down, that's your answer: it fails the clear-rules filter and it isn't a first project.
Q: Do we need to hire a consultant to run the audit?
Not for the audit. Nobody understands where your hours go better than the people spending them, and an outsider's first month is mostly spent learning what your team already knows. Bring in outside help after the audit, when the question has narrowed to "how do we build this specific thing well" — which is a much cheaper question to buy an answer to.
Q: How do we tell if a process is too risky to be our first AI project?
One question: if a wrong output slipped through unnoticed, what would it cost to undo? If the answer involves money leaving the company, a regulator, a safety issue or a customer you'd lose, put it on the list for later and pick something where the worst case is redoing the work.
Q: What if the audit shows nothing is worth automating right now?
That's a legitimate and genuinely valuable result — you just avoided a year of subscriptions and a build. It usually means your volumes are too low for the frequency filter, which changes as you grow. Re-run the same spreadsheet in six months; it takes an hour the second time.