Using AI /
Your company does not need an AI strategy. It needs a problem worth solving
Companies keep being told they need an AI strategy.
The instruction sounds sensible because the technology matters. It also starts one level too high. A company writes a strategy, buys a few tools and asks each department to find somewhere to put them. Six months later it has a collection of pilots and no clear answer to what improved.
AI is a capability. The strategy should still belong to the business.
Start with a problem.
Technology looking for work
An AI strategy usually produces a list of technologies.
A chatbot for the website. A copilot for the office suite. A model for each team. A workshop where everyone writes down possible use cases.
This is backwards. It asks where AI could fit before asking which work deserves to change.
The result is often a convincing demonstration attached to a weak problem. The assistant can answer questions, but nobody trusts the knowledge underneath it. The report can be generated, but nobody needed another report. The pilot works, but the process around it still depends on three spreadsheets and one person who knows what every column means.
The model becomes the most visible part of the system and the least important part of the outcome.
The useful systems started somewhere less glamorous
The systems I run inside Evolve did not begin with a plan to ‘adopt AI’.
High-value carts were being abandoned without a reliable way to find and work them. So we built a system that detects them, checks for later orders and gives the sales team the context for a follow-up.
Regional content required repeated research, formatting and handovers. So we built a queue that prepares each version, makes an approval pack and waits for a person before publishing.
Routine support questions consumed attention that was better spent on difficult customers. So we wrote down the company knowledge, gave agents access to it and kept people at the gate for anything risky.
Each project began with an awkward workflow. AI entered only where language, judgement or messy information made fixed software insufficient.
That order matters.
Some good automation does not need AI
Once a company decides every project must be an AI project, simple problems become unnecessarily complicated.
If a rule can determine the answer, use the rule. If an API can provide the current number, call the API. If a scheduled job can move the file, schedule the job. A language model belongs where the input is ambiguous, the information is unstructured or the system needs to prepare a judgement for somebody to review.
In the cart-recovery system, a model is not asked whether a checkout became an order. Shopify already knows. The system checks Shopify.
Using AI for a deterministic question adds cost and uncertainty without adding capability.
The point is not to use the least AI possible. The point is to give each part of the problem to the mechanism best suited to it.
What makes a problem worth solving
Before building anything, I would look for five things.
It happens often enough to matter
A frustrating task that occurs twice a year is rarely the first place to build. Look for repeated work, repeated delay or the same decision being reconstructed every week.
The current cost is visible
You should be able to describe the baseline. Hours spent, customers waiting, errors made, revenue missed or work left undone. If the existing problem cannot be observed, the improvement will be difficult to prove.
The inputs exist
The system needs somewhere reliable to read from. That might be an API, a folder of documents, a database or a person whose knowledge first needs to be written down. No model can recover facts the company has never captured.
Failure can be contained
The first version should operate where a mistake is cheap and reversible. Draft the message rather than send it. Prepare the change rather than write to production. Let a person approve the step where money, safety or trust enters the workflow.
Someone owns the result
Pilots decay when nobody is responsible for the workflow after the demonstration. The owner does not need to be technical. They need to know what good looks like and care when the system drifts.
You still need rules
Rejecting an AI strategy does not mean ignoring governance.
A company needs clear rules for customer data, approved tools, access permissions, human review, logging and what must never be delegated. It needs somebody accountable for security and a way to disable a workflow without shutting down everything around it.
Those are operating standards. They apply across projects while each project remains accountable to a specific business outcome.
That is more useful than a document predicting how AI will transform the whole company.
Begin with the slow Tuesday afternoon
The best opportunities are usually already irritating somebody.
Watch the handovers. Find the spreadsheet copied into another spreadsheet. Read the support queue. Ask which report takes half a day and is outdated by the time it arrives. Look for the decision that waits because the only person who knows the answer is busy.
Write down the workflow before redesigning it. Measure the current result. Build the smallest safe loop that removes one constraint, then see whether the people doing the work want to keep it.
If they do, expand it.
If they do not, you have learned something more valuable than another AI pilot can show you.
The rule
Do not begin by asking where your company can use AI.
Ask which problem is expensive enough to deserve a system. Then decide whether AI belongs inside it.