Skip to content

Buying AI is not the same as adopting it

A new tool can speed up a task while the rest of the business stays slow. The value depends on what you change around it.

Author: Matas BeniušisPublished updated 6 min read

In short

An AI subscription can make someone faster without making the whole business more effective. The next step is to examine the work around the tool: the searches, handovers, repeated entry and decisions. Start with one process, measure the complete result, and involve the people whose work will change.

An office worker moves paperwork between trays beside a new laptop.
A new tool can sit inside a process that still runs at the old speed.

Imagine a company buying AI subscriptions for forty people. Someone can now write a reply in thirty seconds. They still spend ten minutes finding the right record, copying details between systems and waiting for someone else to approve it.

The writing improved. The customer may still wait just as long.

When someone asks what the spending achieved, the answer is a list of tools people use. What is missing is a result: fewer errors, a shorter wait, more completed work or a service the company could not offer before.

That is the gap I would examine before buying another subscription.

Using AI and seeing a business result are different

McKinsey's 2026 survey captures the gap. Eighty percent of respondents said AI had improved their own productivity. But 37 percent reported a positive impact on their organisation's earnings before interest and taxes, a company-wide profit measure.

That does not mean the rest gained nothing. Some reported savings within particular departments or other benefits. It also does not prove that unchanged processes caused the gap. These are survey responses, not an experiment.

Still, the companies reporting the strongest results were much more likely to say they had redesigned workflows. My practical reading is to look beyond the individual task. If drafting gets faster, what still holds up the finished job?

The red flag is a useful warning

A conceptual historical scene of a steam road vehicle following a man carrying a red flag.
The red-flag rule made a person on foot part of the machine's operating limits.

Britain's Locomotives Act of 1865 required at least three people to operate a powered road vehicle. One had to walk at least sixty yards ahead, carrying a red flag. Speed was limited to four miles an hour on the open road and two in towns.

A new machine could be used, but only within rules that kept it moving slowly. In 1896, legislation exempted qualifying light vehicles from earlier restrictions and allowed a higher speed limit.

The analogy has limits. Those rules addressed dangers on shared roads; they were not simply pointless resistance. But the business question is useful: which steps still serve a purpose, and which remain because the old way of working needed them?

A better engine cannot remove a bottleneck somewhere else. Neither can a better model.

The Luddites had something real to lose

Calling someone a Luddite usually ends the discussion. The history deserves more care. These were textile workers whose livelihoods were threatened by changes in production, pay and working conditions. Their objections cannot be reduced to a fear of unfamiliar machines.

In Parliament in 1812, Lord Byron described machinery that let one worker do the work of many, leaving others without employment. He also criticised the quality of what it produced. The dispute included who benefited from the change and who paid for it.

That question belongs in an AI project too. Someone can understand the technology perfectly well and still have a good reason to worry about what it means for their work.

Automation has more than one outcome

Three examples from different periods show why the word automation cannot tell you what will happen to a job.

Different periods, different industries. The word automation does not tell you which of these your case is.
OccupationWhat changedWhat followed
Telephone operatorsMechanical switching replaced manual call connection.Operator jobs fell sharply. Later generations found other work, but existing operators faced lasting losses.
Factory weavingPower looms reduced the labour needed for each yard of cloth.Cheaper cloth increased demand enough for factory weaving employment to grow. That does not mean hand weavers kept their jobs.
Bank tellersATMs took over routine transactions.Branch expansion helped sustain employment for a time, while duties changed. That protection did not last indefinitely.

The teller example needs its later chapter. The US Bureau of Labor Statistics reports about 339,200 teller jobs in 2025 and projects a 13 percent decline by 2035. That is a projection, not an outcome already observed.

The telephone study makes another distinction. Automation did not reduce overall employment among later generations of young women. But women already working as operators were more likely, a decade later, to be in lower-paid work or no longer working.

A growing industry can still leave particular workers worse off. A plan for adoption needs to account for both.

Redesign one piece of work with the people doing it

Two colleagues rearrange blank task cards and green blocks while discussing a workflow.
The people who do the work should help decide how it changes.

Take the customer reply from the opening example. Writing may be the easiest part. The delay might come from finding an order, checking its status and deciding who is allowed to answer.

An improved process could bring the relevant record and policy into one place, prepare a draft and show the supporting information to the person approving it. Unusual cases could still go to someone with the right experience.

Start by walking through a real case with the people who handle it. Ask where they wait, where they copy information and what they check twice. A step that looks wasteful from outside may prevent an expensive mistake.

Decide what should happen to the time saved

If the process takes less work, what becomes possible? You might answer customers sooner, take on more orders or spend more time on difficult cases. Lower costs can also make a new service worth offering. None of those outcomes happens automatically.

Be equally clear about the effect on staff. If their role will change, include training, time to learn and an honest discussion of the new responsibilities. If fewer people will be needed, do not present the project as a harmless convenience.

The people carrying the change need a place in the plan from the beginning.

Measure the whole job before expanding

Choose one repeated process and record how it works today. Measure the staff time per case, the customer's total wait, the error rate and the work needed to correct mistakes. Then test the proposed change on real cases, including awkward ones.

Suppose a team handles 100 requests a week. Each takes twelve minutes of staff time. If a tested new process reduces that to eight minutes, including review and correction, it releases 400 minutes: six hours and forty minutes a week.

That is an illustration, not a promised saving. It gives you a useful comparison: is the capacity gained worth the subscriptions, setup, training and maintenance? Can the team actually use that time? Saved minutes do not automatically become lower payroll costs.

Also measure the customer's experience. A request can require less staff effort and still sit in a queue for two days. If the queue is the problem, faster drafting has not solved it.

Make the next purchase answer a specific question

Before adding another tool, I would want four answers:

  • Which step is limiting the result today?
  • What will change in the process, and which checks must remain?
  • How will we know the complete job is better?
  • What happens to the people and the time this change affects?

Sometimes the answer will be a better model. Sometimes it will be connecting information that is already there, removing duplicate entry or changing who can approve a routine case.

Buying the tool is a decision about equipment. Adopting it means deciding how the work will change. That is where I would start an AI project. The method page sets out the stages I use to take a process from that first question to a working system.

A note on the history: the examples describe particular places, industries and periods. They help frame a decision; they do not forecast the outcome of an AI project.

Sources

  1. McKinsey, The state of AI in 2026, 25 August 2026. Self-reported individual productivity, enterprise EBIT impact and workflow redesign; associations do not establish causation.
  2. Locomotives Act 1865, original statute, sections 3 and 4: staffing, advance warning and speed requirements.
  3. Locomotives on Highways Act 1896, original statute, sections 1 and 4: exemptions for qualifying light locomotives and a revised speed limit.
  4. The National Archives, the proclamation of Ned Ludd. Archival context for protests over skilled work, new machinery and falling wages.
  5. Hansard, Frame Work Bill, House of Lords, 27 February 1812. Byron's speech is a contemporary argument, not a neutral statistical assessment.
  6. Feigenbaum and Gross, Answering the Call of Automation, NBER Working Paper 28061, published in the Quarterly Journal of Economics in 2024. Distinguishes existing operators from later entrants to the labour market.
  7. James Bessen, Toil and Technology, Finance & Development, March 2015. Factory weaving, and the historical response of bank branches and teller duties to ATMs.
  8. US Bureau of Labor Statistics, Tellers, Occupational Outlook Handbook, updated 27 August 2026. Employment in 2025 and projections for 2025 to 2035.

Ready to spend less time on the work that slows you down?

Let's start with a free 15–20 minute call. Tell me what you're looking to achieve, and I'll help you see where AI could make a real difference, what it would take and whether it's worth pursuing. If AI isn't the right solution, I'll tell you.

Not more AI. More value from AI. Solutions built around you, your team and your goals.