What decides the cost of an AI project?

You've asked two or three firms what it would cost to automate a process, and the answers are so far apart that you can't tell whether one of them is wrong. Most likely they're pricing different things. Each firm guessed at your systems and your exceptions, and each guessed differently.

Nobody can give an honest figure before they've seen your process, so this guide doesn't give one. It gives you the four things that move the cost, so you can shape the scope before you ask and read a proposal when it comes back.

Four things decide most of the cost

How many systems the work has to connect

A process that lives in one system, say your accounting system, is the cheapest kind to automate. Every system you add brings its own connection, its own idea of what a customer or an order is, and its own ways of failing. A process that runs from a shared inbox to the CRM to the ERP and then into a spreadsheet has four of everything.

The age of each system matters as much as the count. A current system with a documented way to connect is quick. An older ERP, a CRM your team customised years ago, or a spreadsheet one person maintains needs work before the first record moves. That work has nothing to do with AI and can cost more than the AI part. Ask each firm which of your systems they've connected before and which would be new to them.

How many kinds of exception it has to handle

The routine case is rarely where the money goes. An invoice that matches its purchase order is easy. The one with a different total, from a supplier with two accounts, for an order that was half delivered, is where the design time goes. Every kind of exception needs a decision (handle it with a rule, send it to a person, or stop) and then it needs testing.

You cut this cost by deciding, before design starts, that every exception goes to a named person with the details attached. The system handles the routine and the person handles the rest. That design is smaller, quicker to build and usually what the team wants anyway. When the same exception keeps coming back, it can get its own rule later as a separate piece of work.

How much testing it takes before your team trusts it

A system goes into daily use when the people who rely on it believe it. That belief comes from running it against real cases from your own history, side by side with what your team did, and fixing every difference. More varied cases mean more testing. So does a higher cost of a mistake: a system that drafts internal notes needs less checking than one that sends a quote to a customer.

Testing also needs your people, because only they know what a correct result looks like. In a company your size that usually means the finance controller or the head of customer service giving up hours they don't have. A proposal that asks nothing of your team will either ask later or won't test properly, so plan for those sessions.

What it costs to keep running

After launch there are three ongoing costs: the services the system calls each time it runs, the monitoring that tells you when something has changed, and the person who fixes it when a supplier changes their invoice layout or one of your systems updates. Fixed automation steps cost almost nothing per run. Steps where an AI model reads a document or drafts a reply cost something every time, so they should be kept to the steps that need them. AI agents or workflow automation explains how to tell those steps apart.

With no data team and a small IT team, this line deserves more attention, because nobody inside will pick up the maintenance by default. A proposal should name all three costs and who is responsible for each.

What barely moves the cost

• The number of steps. Ten steps in one system cost less than three steps spread across four systems.
• Volume, within reason. A system that handles two hundred invoices a week costs about the same to build as one that handles twenty. The saving from the first is ten times larger.
• Which AI model is used. It affects the running cost and the quality of the reading steps, but it is a small share of the build and can be changed later.

The same process, scoped two ways

Take a hypothetical finance controller who wants supplier invoices handled automatically. The first brief reads: invoices arrive by email, by post and through a supplier portal; match them to orders in the ERP and to project codes in a spreadsheet; handle part deliveries, credit notes, duplicates and foreign currency; post them to the accounting system. That's four systems, a paper channel that needs scanning, and five kinds of exception, each needing a rule. The proposals come back large and far apart, because every firm guessed differently about the exceptions.

The second brief reads: invoices that arrive by email, matched to orders in the ERP and posted when the totals agree. Anything that doesn't agree goes to the controller with the order and the invoice side by side. That's two systems, one channel, and every exception handled by a person for now. The business and the goal haven't changed, the design and testing are a fraction of the first brief, and the proposals can be compared. The post, the portal and the credit notes can follow once the first version has earned its place.

What you control before you ask

Three of the four drivers are set by which process you pick and how you describe it. Pick one that runs in one or two systems you can connect to. Decide that exceptions go to a person. Pick one with a measure you can take today, so testing has something to compare against. Which AI use case should you fund first? covers how to choose.

Then describe the process to each firm in the same words: the systems, the weekly volume, the exceptions you know about and the measure. Proposals written against the same description can be compared line by line. Proposals written against a one-line brief can't.

Reading a proposal when it arrives

1. Does it list the systems it will connect, and say which ones the firm has connected before?
2. Does it say what happens to exceptions, and who sees them?
3. Does it describe testing with your real cases, and the time it needs from your team?
4. Does it separate the build from the running cost, and name who looks after the system after launch?
5. Does it name the measure, and commit to reporting against it?

A proposal that answers all five is one you can hold a firm to. One that answers none of them is a number that will change.

What to do this week

1. Pick the process you have in mind and list every system it touches, including the spreadsheets.
2. Write down the exceptions you know about and who handles each one today.
3. Decide which exceptions will go to a person in the first version.
4. Take a reading of the measure, so testing has something to compare against.
5. Send the same one-page description to every firm you ask.

If you'd like help scoping the process before it goes out, that's part of a strategy engagement. We map the systems and exceptions with you and tell you which ones would drive the cost.

Get the next article when it's published.