What decides the cost of an AI implementation?

You've asked two or three firms for a price and the answers are so far apart that you can't tell whether one of them is wrong or they're quoting different things. They probably are quoting different things. Without a shared way to describe the work, every proposal is a guess about your business dressed as a number.

This article doesn't give you a figure, because any figure given without seeing your process would be a guess too. 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 arrives.

How many systems have to be connected

A process that lives in one system, say your CRM, is cheap to automate. Every system you add brings its own connection, its own way of describing a customer or an order, and its own failure modes. A process that touches the website form, the CRM, the accounting package and a shared mailbox has four of everything.

The age of the system matters as much as the count. A modern tool with a documented interface connects in a known way. An older system, a tool your team has customised heavily, or a spreadsheet that one person maintains, needs work before the first record moves. That work has nothing to do with AI and often costs more than the AI part. Ask a firm early which of your systems they've connected before and which they'd be meeting for the first time.

How many exceptions the process throws

The happy path is rarely where the cost is. An invoice that matches its purchase order is easy. The invoice with a different total, from a supplier with two accounts, for an order that was partly 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 the run. Then it needs testing.

You cut this cost by deciding, before the 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. It's a simpler design, it's faster to build, and it is usually what the team wants anyway. Over time, as the person sees the same exception again and again, it can be handled by a rule. That's an extension, not the first build.

How much testing it takes before your team trusts it

A system goes into daily use when the people who depend on it believe it. That belief is built by running it against real cases from your history, side by side with what your team would have done, and fixing every difference. The more varied your cases, the more testing. The more a mistake would cost, the more testing. A system that drafts internal notes needs less than one that sends a quote to a customer.

Testing also needs time from your people, because they're the only ones who know what a correct result looks like. A proposal that asks nothing of your team is either going to ask for it later or isn't going to test properly. Expect a few review sessions and plan for them.

What it costs to keep running

After launch there are three ongoing costs: the services the system uses 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 your CRM updates its interface. Automation steps cost almost nothing per run. Agent steps, where a document is read or a reply drafted, have a cost per run and should be kept to the steps that need them. We explain that split in AI agents or workflow automation.

A proposal should name all three as lines, with who is responsible for each. If it doesn't, ask. The question we'd want answered is what happens in the month after launch when something upstream changes, and who notices.

The same process, framed two ways

Here is how framing changes a proposal. A finance lead asks for supplier invoices to be handled automatically. The first version of the brief says: invoices arrive by email, in the post and through a supplier portal; match them to orders in the ERP and the project tool; handle part deliveries, credit notes, duplicates and foreign currency; post them to accounting. Four systems, a paper channel that needs scanning, and five kinds of exception each needing its own rule. The proposals that come back are large and far apart, because each firm has guessed differently about the exceptions.

The second version says: invoices arriving by email, matched to orders in the ERP, posted to accounting when the total matches; anything that doesn't match goes to the finance lead with the order and the invoice side by side. Two systems with modern interfaces, one channel, and every exception handled by a person for now. The same business, the same end goal, a fraction of the design and testing, and proposals that can be compared. The post and the portal and the credit notes can follow once the first system has earned its place.

What barely matters

• The number of steps. Ten rule-based steps in one system cost less than three steps across four systems.
• The volume of work, within reason. A system that handles two hundred invoices a week costs about the same to build as one that handles twenty. The saving, though, is ten times larger.
• Which AI model is used. Model choice affects the running cost and the quality of agent steps, but it is a small share of the build and it can be changed later.

What you control before asking for a proposal

Three of the four drivers are decided by which process you choose and how you frame it. Pick a process that runs in one or two modern systems. Decide that exceptions go to a person. Pick one with a measure you can take today, so testing has something to test against. We covered choosing that process in what should you automate first.

Then describe the process to each firm the same way: the systems, the volume, the exceptions you know about, and the measure. Proposals written against the same description can be compared. 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 it 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. A proposal that answers none of them is a number, and it will change. If you'd like help framing a process before you send it out, that's what the first call with us is for.