Which parts of a process actually need AI?
Insights

Which parts of a process actually need AI?

The right design might combine models, conventional software and human judgment. It might also be simpler than the original proposal.

Amigdala Team4 min read

Complexity has to earn its place.

Before expanding an AI pilot, establish where the technology improves the outcome and where it adds unnecessary work. The right design might combine models, conventional software and human judgment. It might also be simpler than the original proposal.

An application reads a document, extracts data and prepares a response. The demonstration works. But what happens between that response and an outcome the business can actually use?

Someone may still need to check the data, resolve an exception, correct the output or transfer it to another system. These steps belong in the design and the business case, even when they are absent from the demo.

Our starting point is the outcome the business needs. Model costs matter, alongside the work required to make the output useful.

Randstad’s CFO describes matching different models and technologies to different tasks in this IMD interview.

Break down the work before choosing the tools

Consider a hypothetical business receiving requests for quotations with free-text descriptions and attachments. It wants to prepare accurate proposals faster.

One possible design uses AI to interpret requests and identify missing information. The business management system supplies prices and availability. Explicit rules check commercial constraints. A person clarifies ambiguous requirements and approves commitments outside standard terms.

Hypothetical quotation workflow: AI interprets requests and identifies missing information; the business management system supplies prices and availability; explicit rules check commercial constraints; people clarify ambiguity and approve non-standard commitments. The outcome is a usable proposal with consistent terms.

The outcome to assess is a usable proposal with consistent terms and sufficient information. A quickly generated draft that needs an almost complete rewrite is a different result.

This design is a hypothesis to test. It assumes accessible data, clear enough commercial rules and defined responsibilities. If an existing feature meets the need, use that as the baseline. If requests are infrequent and highly variable, assisted manual work may remain the better option.

Breaking down the work helps compare alternatives. It should not become an excuse to build more components.

Measure the accepted outcome

Business and IT need a shared definition of a usable result before the pilot starts.

In our hypothetical example, the comparison would track time until a proposal is ready, substantial corrections and the work required from people. It would also include configuration, integration and maintenance over realistic volumes and a realistic period of use.

Cost per accepted outcome is a useful measure alongside quality, turnaround time and service value. It is not the only criterion: a more expensive solution might enable a better response or a service that was previously impractical.

Evaluation framework beyond generation cost: include review and substantial corrections, configuration and integration, and ongoing maintenance. Assess quality, turnaround time, human effort, service value and cost per accepted outcome together, using the same criteria for alternatives.

Bain distinguishes expected AI value from value actually delivered through its “realization rate” concept.

Make responsibility part of the design

In the quotation example, the commercial lead and the people preparing proposals would define what makes a draft usable. Developers could then compare solutions against a shared standard, rather than judging how convincing the text appears.

The same design must specify which terms can be applied automatically and which require a commercial decision. An approval button is only useful if the reviewer has the information, authority and time to make that decision.

IMD’s guide for CFOs connects performance measurement, autonomy and accountability for exceptions.

Make complexity earn its place

Every additional connection can bring maintenance work and another point of failure. Compare the integrated design with a simpler alternative using the same acceptance criteria. If its advantage disappears once ongoing management and review are included, simplify it. If the benefit appears only in certain activities, concentrate AI there.

For Amigdala, this is where strategy, design, technology and adoption come together: defining the intended outcome, designing the handoffs between people and systems, and testing the value in the actual working environment.

A pilot should end with a specific decision: which part of the process to expand, with which tools, under whose responsibility and based on which observed results.

That gives the business something more useful than a general answer to “Does AI work?”

Want to learn more?

Get in touch to discuss how these insights can apply to your business.