Start with the problem, not the AI.
Every business is being offered AI. For writing, selling, hiring, replying and planning. The appeal is understandable: nobody wants to discover that a competitor finishes in a morning what takes their team a week. But buying something to avoid missing a trend is still buying without a diagnosis. You pick a tool and look for a job to give it. That order needs reversing.
A relevant AI integration rarely starts with choosing a model. It starts by observing an existing process.
Where are teams losing time? Which decisions require manually gathering information from several sources? Which tasks are repetitive, slow or difficult to scale?
Those frictions reveal the interesting opportunities. AI then becomes a way to improve a system rather than a feature added to follow a trend.
Consider an illustrative situation. A sales manager prepares each proposal by rereading conversations, finding the prospect's constraints and asking a colleague which version of the offer still applies. Writing the proposal is only the visible part. The real difficulty sits upstream. An assistant that writes faster may help one step while leaving the missing information untouched. Mapping the work first prevents a polished output being built on an unreliable input.
Observation means following a real case, including interruptions, exceptions and trips back to the beginning. How often is information entered twice? Who is waiting for whom? Which answer lives exclusively in one colleague's head? Listen to the people doing the work, as well as the person buying the software. An unglamorous friction repeated every day may deserve more attention than an impressive boardroom demonstration.
Value also needs a recipient. If one person saves time and another spends longer correcting the output, the system has moved the burden. If replies become faster but less reliable, speed is hiding a debt. A useful hypothesis names the work being improved, the person benefiting and the minimum quality that must survive. That is specific enough to debate and concrete enough to test.
The right question isn't “Where can we put AI?” but “Where are we unnecessarily losing time, information or capacity?”
Three areas where value often appears.
The first is access to information. An organisation accumulates documents, procedures, conversations, customer data and internal knowledge. Making that information queryable and usable can significantly reduce the time required to find an answer.
The second involves repetitive operations. Qualification, classification, extraction, summarisation or preparation can often be assisted without trying to automate an entire function.
The third concerns decision-making. AI can prepare context, identify signals or structure information so a human can decide faster with better visibility.
In customer support, an assistant might prepare a reply from the returns policy and the details of a case. It should not invent a commercial exception. The distinction looks small in a demo. It becomes rather larger when a customer receives a promise the business cannot honour. A useful response separates what is known, what is suggested and what requires approval from someone responsible.
For internal knowledge, access is only the beginning. Documents must be current, their status identifiable and their permissions respected. An old procedure retrieved instantly is still an old procedure. People need to inspect the source and recognise conflicting guidance. When two rules disagree, the system should lead them back to the information owner. A neglected library does not become trustworthy because it acquires a chat interface.
Qualification is another manageable starting point. An assistant can read an enquiry, identify useful details, suggest a category and prepare questions about missing information. A salesperson receives a structured request rather than a raw message, while retaining judgement about the opportunity. In administration, extracting details from a document can reduce typing; checks on amounts and references still matter. In content production, a preliminary summary may speed preparation, but experience, an editorial angle and responsibility do not emerge from a button.
Analysis can help bring together information a team otherwise lacks the time to assemble. The output should help someone ask a better question. A sales summary does not establish why sales changed. Grouping customer feedback might reveal a problem, but someone needs to examine the cases and decide what to change. These uses expand an existing capability without pretending to replace the whole job.
The model is only one part of the system.
An AI demonstration can be impressive while remaining unusable inside a real organisation. Value appears when the model is correctly connected to the data, tools, rules and people that make up the process.
Permissions, data quality, human validation, security, cost, observability and integration with existing software then become as important as the model itself.
That is why we consider an AI solution as a complete architecture rather than a simple API call.
Integration starts with details that rarely feature in launch videos. What triggers the work? Which information is passed in? Where does the output appear? Who takes over after a failure? An assistant that requires another application, manual copying and then another transfer may add handling. It needs to meet people where their work happens. Otherwise they adopt the demonstration for a week and then return to their previous routine.
Separate a suggestion from an action. Preparing a draft is different from sending it. Extracting an address is different from changing a customer record. The harder an action is to reverse, the more explicit its controls need to be. An initial deployment can remain read-only, show its sources and require approval before writing anything. That boundary lets the organisation learn without making an entire operation depend on a poorly understood output.
Reliability needs testing against awkward cases as well as ordinary ones. Incomplete documents, ambiguous requests, missing sources, malformed files and expired information are part of actual work. Decide what happens when the system lacks an adequate basis for a response. Asking a question, handing over a case or declining to answer can be the correct behaviour. Confidently filling the gaps is not a fallback plan.
Human review must be practical. If an operator receives a long answer with no references and has to reconstruct everything to check it, the assistant has created a second job. Showing extracted facts, sources and uncertainties makes review more useful. The process owner must be able to inspect errors, change rules and retire outdated sources. That is the architectural work behind our AI systems, beyond selecting a model.
Sometimes the best solution isn't intelligent.
A receipt needs sending when an order reaches a defined state. A reminder needs triggering after a specified interval. A form needs routing to a team based on an explicit answer. Ordinary rules may solve these problems. Adding a language model where a condition would suffice makes the outcome harder to predict and the system more expensive to maintain. Sensible automation does not need to hold a conversation.
AI becomes interesting when the input is less structured: free-form messages, varied documents, information to reconcile or text to summarise. Even then, it need not handle everything. A model can propose a category while deterministic rules calculate a price or verify a condition. The system combines flexibility with control. The same tool does not have to interpret a situation and guarantee every consequence of that interpretation.
Some problems simply need better organisation. If nobody knows which procedure is authoritative, clarify that responsibility first. If a form collects too little information, improve it. If commercial decisions change every week without documentation, no technical layer will permanently repair the ambiguity. Automating disorder can produce disorder faster. The bottleneck may be management rather than computation.
Deciding against AI for one step is not a lack of ambition. It keeps the means proportionate to the problem. A system with one carefully bounded AI use, surrounded by conventional checks, may be more dependable than a collection of agents expected to run everything. Technical sophistication is not a unit of value for the business owner. Work completed, quality preserved and cost understood are.
When waiting is the better decision.
A rare process that is poorly documented and hard to verify is a weak first candidate. It offers few opportunities to learn and plenty of room for exceptions. A process whose data cannot be used under the proposed conditions also calls for a pause. Examine what information is sent, how it is retained, who can access it and the organisation's constraints. A convenient copy into an external tool is not automatically an acceptable integration.
Responsibility needs a clear answer. Who approves the output? Who can disable the system? Who handles rejected cases? Without answers, the organisation has purchased a capability without arranging its use. This matters particularly when an output influences a commitment, a person or an operation that is difficult to correct. Human judgement should be part of the workflow, not a sentence added at the bottom of a screen.
A subscription can help someone learn or assist an individual task. Five scattered subscriptions, however, do not constitute a strategy. Without objectives, usage rules and feedback on errors, the business cannot describe what it gains. It may not even know which documents are circulating. Strategy begins when experiments generate shared knowledge and support decisions about which uses to continue, restrict or abandon.
Allow for maintenance too. Offers change, procedures evolve and employees leave. A system without an owner can remain technically available while becoming operationally wrong. Name someone responsible for source quality and, where needed, someone responsible for operation. Delivery does not end the subject. It begins a service that needs looking after.
Measure before scaling.
Not every AI opportunity deserves to be industrialised. A first system should test an assumption within a sufficiently limited scope.
Time saved, volume processed, response time, quality, cost per operation or resolution rate can then provide a concrete basis for deciding what comes next.
This approach turns AI into a measurable investment rather than a permanent experiment.
Before testing, observe the unassisted work. Record active time, waiting, rework and errors across a varied sample of cases. The aim is to understand the process, not to monitor employees. Then test the same categories with assistance. Compare like with like: a simple case completed with AI tells you little about a complex case completed without it. A baseline gives an attractive demonstration something serious to answer to.
Include correction in the apparent saving. In a purely illustrative example, a draft produced in seconds may still require several minutes of checking. It can remain worthwhile; the checking simply needs counting. Add integration, source maintenance, training, subscriptions and operation. The price of a request does not describe the cost of a system any more than the price of a screw describes the cost of a machine.
Released time does not automatically become a cash saving. It might let the team handle more requests, improve responses or clear a backlog. Those benefits are legitimate, but name them accurately. If nobody can reuse the capacity, the commercial effect will be limited. The next question is what the team will do with the time. The investment becomes clearer when that answer exists.
Agree stopping criteria as well. Poor quality, expensive review or weak adoption may justify changing the scope. Continuing because a project has already consumed time adds a bad reason to a bad hypothesis. A successful pilot is not necessarily one that gets expanded. It is one that enables a better-informed decision.
Choose a first use that earns its place.
Start with a frequent, observable process. Describe its input, expected result, people and the exact point at which work slows down. Choose a limited step whose output can be checked without repeating the entire task. Preparing a sourced reply is a more manageable boundary than delegating customer service. The limit need not be permanent; it reveals the conditions under which expansion would make sense.
Write the hypothesis before building: reduce this delay or workload, for this team, while preserving this quality standard. Identify the sources and confirm they can be used. Decide what stays human, what follows rules and what actually requires interpretation. You now have a short decision brief. It lets you compare an AI solution with a simpler alternative rather than treating the model as a foregone conclusion.
Test ordinary, difficult and incomplete cases. Involve the person who will use the result every day. Their experience of checking, interruptions and usefulness matters as much as the demo's output. Measure the net outcome, then decide whether to continue, change or stop. If you continue, assign an owner and arrange a review when sources or processes change.
The best first use may not be the one you are most eager to show on stage. It will be the one the team misses when you switch it off. That is a useful test. AI creates value when important work becomes easier to complete, with clear responsibility and an output worth trusting. Start where the work is struggling. The tool can come later.
End of article / 3W Insights