The question we hear most isn't "can you build this?" — it's "should we be doing something with AI?" It usually arrives with a note of anxiety, as if the business is falling behind by not having a chatbot yet.
Here's the honest answer: AI is a power tool, not a strategy. Used on the right problem, it wins back hundreds of hours a year. Used on the wrong one, it's an expensive demo that quietly gets turned off. The difference is almost never the technology — it's the problem selection.
Where AI genuinely pays off
Modern language models are remarkably good at a specific category of work: tasks that involve reading, writing, or classifying language, where each individual decision is low-stakes, and where the volume is high enough that humans doing it get bored. In practice, that looks like:
- Reading at volume. Summarizing intake forms, triaging support tickets, extracting fields from invoices and contracts.
- Finding answers in your own documents. Policies, past proposals, SOPs — knowledge your team re-derives weekly because search can't reach it.
- First drafts. Responses, reports, and descriptions where a human edits the last 20% instead of writing from a blank page.
- Turning mess into structure. Free-text notes, emails, and voicemails converted into fields a database can actually use.
Notice what these share: the work already exists, someone is already doing it manually, and the cost of an occasional imperfect output is low because a human is still in the loop.
Where it doesn't
AI is usually the wrong tool when the problem is deterministic. If the rule can be written down — "if the invoice is over $5,000, route it to Sam" — you want a plain script, and it will be cheaper, faster, and correct every single time. AI is also the wrong first move when:
- The volume is low. Automating a task someone does for an hour a month is a hobby, not an investment.
- Mistakes are expensive and unreviewable. If an error costs real money or trust and no human checks the output, don't put a probabilistic system there.
- The data doesn't exist. An assistant grounded in your documents needs the documents to exist, be findable, and be roughly current.
- The real problem is process. AI layered over a broken workflow automates the brokenness.
The checklist
Answer honestly for the task you have in mind:
- Does this task involve reading, writing, or categorizing language or documents?
- Does someone spend two or more hours a week on it today?
- Could a competent new hire do it after reading your existing documentation?
- Can a human review the output where it matters, at least at first?
- Would you still get value if the system were right 90% of the time, not 100%?
- Can you point to the documents or examples the system would learn the job from?
Five or six yeses: you have a genuinely good AI candidate — scope a small pilot. Three or four: there's probably something here, but the shape needs work; the missing yeses tell you what to fix first. Two or fewer: skip AI for now. That's not a failure — you just saved yourself a budget.
Start smaller than you think
The failure mode we see most isn't choosing the wrong problem — it's choosing too many at once. "AI transformation" projects fail; "answer questions about our install manuals" projects ship. Pick the single workflow with the most yeses, pilot it against your real data — including the ugly edge cases — and measure hours saved, not demos delivered.
If the pilot works, you'll know exactly what to expand next. If it doesn't, you've spent a fraction of the budget learning that — and the discipline of the pilot usually reveals the process fix that was the real answer all along.