Stop looking for AI use cases

“Where can we use AI?” sounds like a perfectly reasonable question. It is also one I hear increasingly often. A business gets access to ChatGPT or Microsoft Copilot, staff receive some training and people begin to experiment. Someone discovers that AI can write emails, summarise documents or analyse a spreadsheet, and it does not take long before attention turns from the tool itself to the organisation. Where else could we use this? What are our AI use cases? Which processes could we automate?

I have increasingly come to think that, for organisations trying to improve how their existing business works, this is the wrong place to start. Not because businesses should not use AI, but because an AI use case is already a proposed solution. By the time we describe something in those terms, we have introduced a particular class of technology into the problem. We are no longer simply asking what needs improving; we are looking for places where our preferred solution might fit.

For operational improvement, I think the thing being prioritised should initially be the organisational problem.

Start with the work

There are sophisticated approaches to AI adoption that consider business value, feasibility and organisational readiness, so I am not suggesting that every discussion of AI use cases is technologically led or poorly thought through. My concern is more fundamental. Once the thing being prioritised is an AI use case, AI has already entered the definition of the candidate intervention.

This is not a new concern in management or technology. Continuous improvement, Lean and systems approaches all place considerable emphasis on understanding current work before changing it. Goodhue and Thompson’s work on Task-Technology Fit made a related point in information systems: technology is more likely to improve performance when its capabilities fit the tasks it supports. Research into design fixation also gives us reason to take initial framing seriously. It does not show that asking “Where can we use AI?” necessarily causes fixation, but it does remind us that early commitment to a class of solution can constrain what we subsequently notice about the problem.

Generative AI makes this particularly easy because the technology arrives with such visible capabilities. We see what it can do and naturally begin looking around the organisation for somewhere to apply it. There is nothing necessarily wrong with that if the purpose is exploration. Asking what a new technology makes possible can reveal new products, services and business models. But that is a different question from asking how we improve the performance of the business we already have.

For that, I use a much less sophisticated-sounding starting point: come back with three business processes that give you grief.

“Grief” is deliberately ordinary language. I am looking for things that people already know are difficult: orders that go missing, reports that take days to assemble, information copied between spreadsheets, customers waiting while somebody finds an answer, recurring rework, queues, exceptions, awkward hand-offs and processes that depend upon one particular person knowing what to do. I use the word process because managers generally understand what I mean, although more precisely I am interested in problematic work. That includes decisions, information flows, coordination, judgement and informal activity that may never have been formally described as a process.

These problems are signals rather than priorities. A process can cause enormous irritation while being commercially insignificant, so finding the grief is only the beginning. The next question is whether improving it would actually matter: would it affect revenue, capacity, cost, quality, customer experience, lead time or risk? At this stage, value is a triage decision rather than a detailed business case. Grief gets the work onto the list; value determines whether it deserves investigation.

That apparently small change alters the object being prioritised. Instead of beginning with a portfolio of AI use cases, we begin with a portfolio of valuable organisational problems.

A CRM was not the problem

I saw this with a joinery manufacturer employing around 40 people. The initial ambition was to “vibe-code” a CRM application to improve sales-order processing. It was an understandable idea. AI-assisted software development was making something that would once have required specialist developers appear much more accessible, and a bespoke application seemed an attractive way of bringing the process under control.

When we started looking at how sales orders actually moved through the business, however, a different picture emerged. Information was being transferred through email, spreadsheets were being updated manually, customer and order information was not held centrally, and numerous spreadsheets lived on a shared network drive. The immediate problem was not the absence of an AI-built CRM. It was the way information moved through the business.

The company therefore tackled those problems one at a time. Information was centralised using SharePoint and Microsoft Lists, templates and forms improved information capture, workflows were revised, and Power Automate dealt with relatively predictable transfers and updates. These examples come from my practitioner work rather than controlled experiments, so I treat the figures as operational evidence rather than proof of causality. Less information was being lost in email, around 15 per cent more orders were processed without a corresponding increase in sales activity, suggesting that fewer existing opportunities were being lost within the process, and quotation turnaround reduced from around ten days to four. Over the following six months, revenue also increased by 27 per cent. Many factors affect revenue, so it would be wrong to attribute that increase solely to the process changes.

What happened next is important. The bottleneck moved. Once the earlier information and workflow problems had been reduced, producing bespoke quotations became the constraint, and this time AI really was part of the answer.

Producing a bespoke joinery quotation was not simply a matter of moving known information between systems. Architectural drawings had to be interpreted, each order could require materials the company did not routinely hold in stock, and that information had to be researched and brought together into a commercially useful proposal. An AI component was introduced into the Power Automate flow to produce an initial draft. An experienced estimator considered that draft before approving it, after which the approved version was processed again with AI and the final proposal approved by the commercial manager before being sent to the customer.

This sequence illustrates why I am wary of treating “AI” as the organising principle for improvement. Power Automate was not an inferior solution used until the company became sufficiently sophisticated to adopt AI. It was the appropriate intervention for one kind of work, while generative AI was appropriate for another. Even where AI was appropriate, human expertise and commercial authority remained important.

Once we stop assuming that the answer must belong to a particular technology category, the intervention space becomes much wider. We might stop, simplify, redesign, automate, assist or delegate. These are not stages in a digital maturity model. A Power Automate flow is not a failed attempt at an AI agent, and removing an unnecessary activity can be better than automating it. Redesigning how information is captured may remove the need for either. A single organisational problem may also require several different interventions.

The useful question is not how much AI we can put into a process. It is what does this work need?

What if the organisation does not know how to investigate the work?

There is an obvious difficulty with this argument. Telling an organisation to stop looking for AI use cases and instead understand and improve its work is not especially helpful if it does not possess the capability to do that. Many smaller organisations do not have process-improvement teams, Lean specialists or business analysts, and their important processes may never have been examined systematically. People know that something causes grief, but they do not necessarily know how to establish why.

This is where I think AI becomes much more interesting. Its most valuable first use may not be doing the work at all. It may be helping the organisation understand how the work is being done.

I saw this while working with a specialist textile manufacturer producing short runs of cloth for commercial customers. Textile production and finishing involved an intricate supply chain with a heavy dependence upon accurate and timely exchange of information, but the organisation did not have an established internal process-improvement capability that could readily expose what was happening across this system.

We therefore did not begin by looking for somewhere to deploy AI. We began by trying to understand the work. Many processes were identified and five were selected because they were both prone to problems and potentially valuable to improve. Together, they represented approximately 40 per cent of the business. As we started examining them, numerous information hand-offs became visible that had not previously been apparent.

ChatGPT became part of that investigation. It helped us examine existing process documentation and structure interviews with production staff about what they actually did. We used it to compare the specified process with actual practice, identify differences and highlight steps that deserved closer scrutiny. In several places, however, the organisation simply did not have enough data to support a sound judgement. Rather than treating that as an invitation for the model to produce a plausible answer, we made the absence of evidence part of the investigation. We used AI to ask what evidence would be required to make the judgement properly and how that evidence might be obtained. Small studies were devised to gather sample data, and the results were then fed back into the analysis.

AI was not the source of truth. It helped scaffold an improvement investigation in an organisation that did not already have that capability readily available internally. It helped interrogate what was documented, elicit what actually happened, expose discrepancies, identify what was not known and suggest how the organisation might find out.

One of the processes investigated was order preparation, where materials had to be located and production scheduled. Initially, the process contained around four hours of actual processing time, but those four hours were spread across approximately eight days of elapsed lead time. For most of those eight days, the order was not being worked on at all. Individual activities were passing through queues in different departments, and the waiting and information hand-offs were not sufficiently visible to the organisation beforehand.

The investigation helped make them visible. The eventual intervention was not an “AI solution”: the process was simplified, a small amount of conventional process automation was introduced, and generative AI was used where qualitative instructions needed to be interpreted. The resulting process required around 20 minutes of actual processing within approximately four hours of elapsed lead time.

Those numbers are striking, but I think the more important point is how the opportunity became visible. Asking “Where can we use AI in order preparation?” would not necessarily have revealed that four hours of work was taking eight days to move through the organisation. The opportunity appeared because the organisation developed a better understanding of how the work actually flowed. Nor did the eventual intervention fit neatly into a single technology category. Simplification addressed part of the problem, automation another, and AI-assisted interpretation another. The organisational problem determined the combination.

AI can scaffold improvement capability

This experience raises a possibility that I think deserves more attention. Organisations are investing heavily in AI capability, but much of that investment concentrates on teaching people to operate AI tools: how to prompt, generate, summarise and automate. What if AI can also help organisations acquire some of the improvement capability they currently lack?

I do not mean that ChatGPT can replace an experienced process-improvement professional, nor should an organisation upload a process map and accept whatever changes a language model proposes. The textile example suggests something more useful and, I think, more realistic. AI can help interrogate existing information, structure questions, compare different accounts of how work happens, expose inconsistencies and generate hypotheses. When the evidence is inadequate, it can also help identify what needs to be measured and how a small experiment might provide that evidence.

People still provide the domain knowledge. They make observations, gather evidence, exercise judgement and decide what to change. AI provides scaffolding around that activity. This suggests a principle that I think is particularly important: when the evidence runs out, do not ask AI to guess. Ask what evidence you need next.

There is a wider research question here. To what extent might AI make systematic organisational improvement methods more accessible to organisations that have never possessed specialist Lean, process-improvement or business-analysis capability? I do not think we yet know the answer, but I think it is a more interesting question than simply asking how many processes we can automate with AI.

Tool literacy is not improvement capability

I have seen the other side of this when organisations begin with AI training. A building contractor asked for prompt-engineering training for its back-office team, and staff got started quickly using Copilot for marketing copy, emails and general office administration. Then the limitations appeared. Marketing material looked similar to that of competitors, emails could be unfocused and impersonal, and, more seriously, documents were sent externally containing commitments that the business could not actually service.

The point is not that Copilot should not be used to draft an email or document. It is that knowing how to obtain an output from an AI system is not the same thing as knowing how that output should participate in organisational work. Tool literacy enables experimentation; it does not provide an improvement method.

This makes me wonder whether some of what we currently describe as an AI skills gap may also be an improvement-capability gap. That is a hypothesis rather than a conclusion, although there is an interesting signal in UK evidence. Office for National Statistics research found that firms with stronger management-practice scores were more likely to adopt advanced technologies and more likely to follow through on plans to adopt AI. In the same research, the most commonly reported barrier to AI adoption was difficulty identifying activities or business use cases, reported by 39 per cent of firms.

The obvious response is to help businesses become better at finding AI use cases. There is another possibility: perhaps we should help them become better at finding and improving valuable problems, and perhaps AI itself can help them do it.

A different starting point

The approach that has emerged from this is straightforward. First, find the work that persistently causes grief and then consider its value: which of those problems matter enough to investigate? Value at this stage is simply a triage decision, not a detailed business case.

Next, understand what actually happens. Follow the information, waiting, hand-offs, workarounds, exceptions and decisions, and look for the difference between actual practice and what the organisation thinks happens. AI can help interrogate the evidence, but the next step is still to establish what we actually know. What are we assuming? What evidence would allow us to distinguish between competing explanations? If the evidence is not there, a small study or experiment may be needed to obtain it.

Only then should we intervene, choosing whether the work should be stopped, simplified, redesigned, automated, assisted or delegated. Often the right answer will be a combination. Finally, we need to learn from what happens. Did lead time, throughput, rework, capacity, quality, customer outcomes or risk actually improve? And, once they did, what became the problem next?

The joinery manufacturer demonstrated this particularly clearly. Improving information movement and sales-order processing exposed quotation generation as the next constraint. Investigating that work subsequently led to an appropriate application of generative AI. Improvement was not a one-off search for technological opportunities; it became a continuing management discipline.

For Cernwell, I describe the higher-level logic as Discover, Design, Deliver. Discover the valuable problem and understand the work. Design an intervention appropriate to what the evidence tells you. Deliver enough change to establish whether it worked and inform the next decision. AI can participate throughout that process: it can help investigate the work, support the design and, where appropriate, become part of the intervention itself.

What to do on Monday morning

If your organisation is wondering where to begin with AI, I would not start by assembling the management team and asking everyone to identify three AI use cases. I would ask them to come back with three business processes that give them grief.

For each one, I would want to know what repeatedly goes wrong, why it matters, what actually happens, what evidence we have and what we do not know. From that list, choose one problem that combines persistent friction with meaningful organisational value, but resist the temptation to propose a technology immediately.

Follow the work instead. Talk to the people doing it, examine how information moves and look for waiting, rework, workarounds, dependencies and exceptions. Compare what is supposed to happen with what actually happens. If the organisation does not have specialist improvement capability, use AI to help structure the investigation. Give it the evidence you possess, ask it to challenge assumptions and identify inconsistencies, and ask what further evidence would be required before reaching a conclusion. Then go and obtain that evidence.

Only after that should the organisation decide what intervention the work needs. Make the change small enough to learn from, but important enough that improvement matters. Measure what happens and then repeat.

There will still be plenty of AI use cases. The difference is that you will arrive at them for a reason.

More importantly, you may discover that AI does not only give an organisation another way to perform work. It can help the organisation become better at understanding and improving the work it already does.

AI should be a possible conclusion of the diagnosis, not the premise of the investigation.

References

Crilly, N. (2019). Methodological diversity and theoretical integration: Research in design fixation as an example of fixation in research design? Design Studies, 65, 78–106. https://doi.org/10.1016/j.destud.2019.10.006

Goodhue, D. L. and Thompson, R. L. (1995). Task-Technology Fit and Individual Performance. MIS Quarterly, 19(2), 213–236. https://doi.org/10.2307/249689

Office for National Statistics (2025). Management practices and the adoption of technology and artificial intelligence in UK firms: 2023. Released 24 March 2025.