How to integrate AI into business processes: the operating guide (in 4 phases)

In brief. Integrating AI does not mean picking the right tool: it means finding the process that is actually losing value, often a problem that looks technological and is not. The sequence that works has four phases: diagnosis (map the process and quantify the loss in euros), system (build and ship to production on a bounded scope), value (measure every month what changed) and autonomy (train somebody inside the company so the system holds on its own). Skipping the diagnosis to rush to the tool is why most AI projects leave no trace.

The problem that looked like a tool and was not

An accounting firm, ten professionals, called us with a precise request: they needed AI to speed up electronic invoicing. The owner was convinced the bottleneck was technological, old software, slow procedures. We spent the first day looking at their management system with him instead of talking about tools.

The system showed invoiced revenue. Not collected revenue. The owner knew how much he had invoiced in the quarter, but he did not really know how much cash he had at that moment, nor which clients were months overdue. Every month end somebody reconstructed the picture by hand, cross-checking bank statements and invoices, half a day of work to answer a question that should have had an instant answer: how much do we actually have available.

It was not an invoicing speed problem. It was a hole in cash visibility, disguised as a technology request. If we had granted the initial request, we would have delivered a faster tool for continuing not to see the real problem.

Why starting from the tool is almost always the mistake

The number one mistake in AI adoption is asking "which tool do we adopt" before understanding which problem it has to solve. It leads to picking a solution and only then, once the project is done, wondering whether it was any use. In the accounting firm's case, the right question was not "how do we automate invoicing", but "where are we losing visibility and what does not having it cost us". That is where the sequence we use with every client comes from, regardless of sector: four phases, in this order.

Phase 1: diagnosis. Find where you lose value and put it in euros

With the accounting firm we mapped the real cash management process, not the one described on paper. Where the data stopped (in the management system, not in the bank statements). Who did the reconciliation by hand and how long it took. What stayed invisible until month end: client overdues, which in practice were the company's own money sitting somewhere with nobody seeing it.

This mapping work exists to find the Value Leaks, the losses of value nobody notices because they have become operational normality. The goal of the phase is one number: what it costs today, every month, not to have that visibility. At the firm it was roughly half a day of one person's time wasted on manual reconciliation, plus the overdue that stayed out of control for weeks. That is exactly the work we do with the ROIometer: before talking technology, a starting number.

A note on method. The diagnosis only closes when the loss is a number, not a feeling. Illustrative example from the accounting firm case.

Phase 2: system. Build something that reaches production, not a demo

With the number in hand, you build. In the firm's case they did not need a faster invoicing tool: they needed a system that recognised what had actually been collected, not just what had been invoiced, and showed it without having to reconstruct it by hand every time.

Two technical things matter here that often get underestimated: the data has to be clean and accessible, and the system has to talk to the tools the company already uses rather than replacing them all. That is why an infrastructure like MARF, which collects and orders the data before automating anything, makes the difference between a system that holds and one that breaks on the first exception. And on a bounded scope: not "let's redo the firm's whole financial management", but "let's fix the visibility on collections". A small project that genuinely reaches production beats an enormous project that stays at pilot stage for months.

Phase 3: value. Measure the result every month, not vaguely

An integration that is not measured cannot be defended, in front of anyone. At the accounting firm the criterion was clear from the start: how long reconciliation takes, and how much overdue stays visible instead of getting lost. The format we use to report it is the Value Report: what changed, in euros or in hours, over the period. Not "we automated a process", but "reconciliation went from half a day to a few minutes, and overdue is now visible the same day".

This is the point where many AI adoptions get lost: once the project is done, nobody goes back to check whether it actually changed anything. Without that monthly number, an owner has no way of deciding whether to extend the investment or stop it.

Phase 4: autonomy. Make somebody inside the company able to run it

The last phase is what separates a real integration from a dependency. At the firm, the end goal was not for Morfeus to keep stepping in every time something changed: it was for the accountant to be able to read his own cash position without needing an external supplier to make it work. That is why you train an AI Champion, an internal person who understands the system well enough to maintain it and evolve it as needs change.

If, when the supplier leaves, nobody is left who can read what the system produces, the integration is not complete. It is just a project on pause.

The sequence generalises, the problem does not

The four phases (diagnosis, system, value, autonomy) are the same sequence in every project we run, regardless of sector. But what changes every time, and what no framework can tell you in advance, is where the problem is actually hiding. At the accounting firm it looked like an invoicing tool, it was a hole in cash visibility. At an agency it can look like a content volume problem and turn out to be a problem of briefs never collected in one place. The method tells you how to look. It does not tell you what you will find, and that part always has to be verified in the field, not assumed at a desk.

"Start from the number, not the tool. If you do not know what you are losing, any tool will look like the right answer."

How big to start: small, but real

The temptation, faced with a problem like invisible cash, is to open an enormous project: redo the whole management system, digitise every process in the firm in one go. That is almost always a mistake. Better a small scope that genuinely reaches production and produces a verifiable number than a vast programme that never gets past the presentation stage. The Pilot → Retainer model comes from this observation: you prove the value on a real, circumscribed front, then extend where it has already worked.

Common mistakes to avoid

• Starting from the tool instead of the process, as in the firm's initial request.
• Stopping at the demo, without ever taking anything to production.
• Leaving the project to the technology people alone, without the people who live the process every day.
• Automating on dirty data: it amplifies the chaos instead of reducing it.
• No monthly measurement: impossible to defend the project or decide whether to extend it.

In short

Integrating AI is process work, not technology work, even when the initial request seems to say otherwise. Find where you are losing value before looking at tools, build a system that genuinely reaches production on a small scope, measure it every month in euros or hours, and leave somebody in the company who knows how to run it. In that order, not another one.