Where AI pays back first

Why the first choice matters

Almost every large company now uses AI somewhere. In McKinsey’s 2026 survey of 1,719 leaders, nearly nine in ten report regular use in at least one business function. Only 37% attribute any EBIT impact to it, and that share has barely moved in a year. About 6% of respondents qualify as high performers, with at least 5% of EBIT coming from AI.

BCG’s numbers tell the same story from a different angle. In its 2025 study of 1,250 executives, 60% of companies reported minimal revenue and cost gains from AI. Only 5% were generating substantial value. A year later the picture has improved: in BCG’s 2026 index, nearly half of companies now report meaningful value, and the leaders show 2.4 times the revenue growth of laggards. The gap between the two groups is widening.

MIT’s 2025 research on generative AI is the bluntest. Across more than 300 public initiatives and 52 interviews, about 5% of custom enterprise pilots reached daily use with measurable returns. Mid-market firms moved from pilot to full roll-out in about 90 days. Large enterprises took nine months or more, ran the most pilots and converted the fewest.

These studies use different methods and should be read with care. They agree on one point: the companies that get value from AI made a different first decision. They picked work that matters to the P&L, redesigned it, and measured the result in money. The rest picked work that was easy to demonstrate.

Most stalled programmes did not fail at the build. They failed at the choice of what to build.

Where the money sits

BCG estimates that about 70% of AI’s potential value sits in core business functions: sales and marketing, operations and manufacturing, supply chain, pricing. IT accounts for about 13%. Support functions such as finance and HR hold real savings too, especially where the work is high-volume and document-heavy.

What the high-value use cases have in common is the shape of the work. Across Twistag client work, the first use cases that paid back fit at least three of these five patterns:

1. High volume. The same decision or document comes up hundreds or thousands of times a month.
2. Rules plus judgement. Most cases follow clear rules. A minority need a person to look, and the system can tell which is which.
3. Data spread across silos. The right answer depends on information that sits in separate sites, teams or systems, so nobody sees the whole picture.
4. A visible cost line. The work maps to a number the finance team already tracks: agency spend, overtime, write-offs, days sales outstanding, cost per claim.
5. A cheap way to catch errors. A person can check the output quickly before it takes effect, so a mistake costs minutes and never reaches a customer.

General chat assistants rarely fit this shape. They help individuals write and search faster, and that is worth having. MIT’s research found that these tools mostly raise personal productivity without changing P&L results. They are a sensible baseline for every team. They are a poor candidate for the first funded use case.

Two patterns from client work

Two Twistag engagements show what a strong first use case looks like.

A European hospitality group with more than 2,000 employees across several properties spent over €1 million a year on agency staff. Each property scheduled its own people from its own bookings and forecast. A property at 45% occupancy could have idle housekeeping shifts while another across the city, at 95%, filled the same shifts through an agency at last-minute rates. Twistag built a data layer that brings bookings, occupancy and staffing from every property into one view, and an optimisation engine that proposes cross-property rotations with a projected saving attached. General managers accept or reject each proposal. Agency spend fell by 70%, four months from kickoff to live.

This use case scored high on value because the money was already on a ledger line. It scored medium on effort because the data existed in each property’s systems and needed joining. It scored low on risk because every recommendation passed through a manager. It also shows that the best first use case does not always need a language model. The engine at its core is a mathematical optimiser.

Aralab, a manufacturer, receives more than 2,000 supplier invoices a month, each in the supplier’s own layout. Three people in finance read and keyed them by hand. Twistag built an accounts-payable agent: a language model reads each PDF, deterministic code re-checks every price, tax line and total against the purchase order, and staff review only the invoices the system is unsure of. Around 80% of invoices follow patterns that need no review. The agent went live in six weeks, built by one engineer, and the three finance staff moved to forecasting and supplier work.

Here the value sat in hours and in the team’s capacity. The effort was low because the invoices, the ERP and the purchase orders were all reachable. The risk was contained by the second check in code and by the review screen.

Scoring value

A value score is only useful when it is tied to money and to a person. For each candidate, write down three things:

• The figure at stake each year. Hours times loaded cost, spend on a supplier line, revenue lost to slow response, write-offs, penalties. Use the finance team’s numbers, even rough ones.
• The share AI can realistically move. Rarely 100%. In the invoice example it was about 80% of volume. In the staffing example it was the agency share of shifts.
• The owner. The executive whose budget or target moves. If nobody owns the figure, the score is zero until someone does.

Then score from 1 to 5. A simple scale works for most mid-market and enterprise companies:

Adjust the bands to the size of the company. What matters is that every score can be traced back to a number.

Revenue use cases, such as faster quotes, better pricing or proposals that win more often, are harder to size than cost use cases. Score them with a conservative assumption, and note the assumption next to the score so it can be tested later.

Scoring effort

Effort is where most teams are optimistic. In practice, the model is the smallest part of the work. Most of the effort sits in four places:

1. Data access. Can the system read the documents, records and history it needs, today, without a new data project? This one factor decides more timelines than any other. Chapter 4 covers it in depth.
2. Systems to connect. Each system the use case must read from or write to adds integration, testing and an owner to agree with.
3. Share of exceptions. A process where 80% of cases are routine is far easier than one where every case is different.
4. Change for the team. New screens, new approval steps and new targets all take time to land, and the people affected need to be part of the design.

Score each from 1 (easy) to 5 (hard) and take the average, or simply judge the whole on the same scale. A use case that scores 1 or 2 on effort can usually reach a working version within six to twelve weeks.

Marking risk

Risk is marked, and it does not cancel a use case on its own. A high-risk use case can still be the right first choice. Its risk class decides how it must be built.

Ask three questions:

• Who is affected by an error? An internal team, a customer, a patient, an applicant.
• How reversible is it? A draft that a person reviews is fully reversible. An automatic payment or a credit decision is far less so.
• Which rules apply? Data protection always applies. Some uses, such as credit scoring, insurance pricing, recruitment or access to essential services, fall under the high-risk class of the EU AI Act, with specific duties on documentation, oversight and logging. Similar rules are emerging in other markets.

Mark each use case low, medium or high. Low means a person checks every output, or errors are cheap and internal. High means decisions about people, money or regulated activity, with limited ability to reverse them. Chapter 8 sets out the controls for each class.

Building the map

Plot every candidate on a simple grid: value on the vertical axis, effort on the horizontal. The four quarters each lead to a different decision.

• Fund first (high value, low effort). The short list comes from here. Pick three to five.
• Plan (high value, high effort). Worth doing, after the data or systems work that lowers the effort. Put that groundwork on the roadmap now.
• Use standard tools (low value, low effort). Often covered by off-the-shelf software or the general AI assistant the company already pays for. No custom build.
• Park (low value, high effort). Write down why, and revisit in a year.

Colour each point by risk. A high-value, low-effort, high-risk use case belongs on the short list, with the stronger controls planned from the start.

From the short list, pick one to prove first. The best first proof has a clear owner, data that is already reachable, and a result that can be measured within a quarter. Chapter 3 shows how to take it from use case to a working agent in six to twelve weeks.

Common mistakes

Five patterns explain most of the stalled programmes Twistag has seen:

• Choosing for the demo. A use case that looks impressive in a board meeting and touches no cost or revenue line. It gets applause and no second budget.
• One use case per department. Spreading money evenly so every function has a pilot. The result is many small proofs and no single result big enough to fund the next stage.
• Starting with the platform. Buying or building a platform before any use case has proven value. The platform matters later, once several agents run every day. Chapter 11 covers that stage.
• No baseline. Without the number before the change, nobody can prove the number after. Record the baseline before the first line of code.
• No owner. A use case owned by the innovation team and nobody in the business. When the pilot ends, nobody adopts it.

What to do this month

1. Ask each executive for the three processes that cost their area the most time or money.
2. Run the value–effort map in a two-hour leadership session, with finance in the room.
3. Agree the short list of three to five, each with an owner and a baseline figure.
4. Pick one to prove first, and set the date for its first result.

Questions for the leadership team

1. Which three processes cost the company the most hours or the most money each month, and who owns each one?
2. For each AI initiative under way today, what P&L line is it meant to move, and by how much?
3. Where do decisions depend on data that sits in separate teams, sites or systems?
4. Which candidate use cases could start on data the company already holds, in its current form?
5. Who in the leadership team owns the short list, and when does it get reviewed?