AI automation pricing, and how to tell a real quote from a sales number

The five ways this work gets priced

Before you can judge a number you have to know what the number is for. Five pricing models are in common use, and providers rarely say which one they are quoting, which is a shame: the model tells you more about what happens after the build than the figure does.

Most real arrangements stack two of these: a project fee for the build, and a platform fee underneath it that arrives monthly whether or not anybody touches the system. Ask which parts of a number are one time and which repeat, before you compare two proposals.

• Fixed scope project. You pay once for a defined set of workflows, delivered and handed over. You are buying a finished thing, and the risk of it running long sits with the provider.
• Monthly retainer. You pay for continued access to a team. You are buying attention rather than an artefact, which suits work that keeps changing and suits nobody whose scope is finished.
• Per seat licence. You pay for each person with a login. You are buying software, and your bill grows with headcount rather than usage, which is good or bad depending on which of those grows faster here.
• Per execution platform fee. You pay by how many steps the automation runs. You are buying capacity, and a busy month costs more than a quiet one.
• Hourly. You pay for time. You are buying flexibility, and carrying the risk that the estimate was optimistic.

The variables that actually move the number

The count of workflows is a weak predictor of cost. What decides the real figure is a short list of conditions inside your business, and every one of them is knowable before anybody writes a line of code.

Only two of those are about AI. The rest is integration and documentation, which is why two businesses buying what looks like the same thing receive quotes nowhere near each other, and why both can be honest.

• How many separate systems the process touches. Each connection is its own piece of work, and that count matters far more than the count of steps.
• Whether any of them has no interface for software to use. One application that has to be driven through a screen built for a person can outweigh everything else in the project.
• Whether the process is written down. If the only description of it lives in the head of the person doing it, mapping it is a phase of its own and somebody pays for that phase.
• How many exceptions the process really has. The ordinary path is quick to build, and the awkward cases are where the hours go.
• Volume, which decides the platform tier and the model usage rather than the build.
• How many people need training, and whether they sit in one place or several.
• Whether it runs on infrastructure you host or on a platform that bills per operation. n8n can be self-hosted; Make and Zapier cannot, and that choice changes the shape of the running cost permanently.

The number that decides whether any price is reasonable

A price is only expensive or cheap relative to something, and the something is what the task costs you today. Most owners have never worked it out, which is why quotes get judged on instinct or on whichever number arrived first.

Work it out roughly, on paper, before you speak to anyone. Count how many times the task happens in a normal week and how long one instance takes, including the interruption around it rather than only the typing. Multiply that across a year and put an honest value against the time of the person doing it. You now have a ceiling. A price meaningfully below it is worth a conversation, and a price above it needs an argument that has nothing to do with hours.

Run the same exercise on the second and third tasks on your list. It usually reorders them, because the loudest annoyance in a business is rarely the most expensive one.

Our manual work cost calculator runs that arithmetic and gives you the annual figure to hold a quote against.

How to read a quote that arrives before the questions

If a number reaches you before anybody has walked the process end to end and listed the systems it touches, the number was not calculated. It was chosen: low to win the work and revised once the awkward system appears, or high to cover an unknown nobody wanted to investigate.

A real estimate arrives with its working. Every system named, every exception acknowledged, mapping priced separately if the process is undocumented, and a clear line between what is charged once and what recurs. Five questions will tell you which kind you have received.

• Which systems did you assume this connects to, and what changes if there is another?
• Which parts of this number arrive again next month?
• Is mapping the process included, or billed once you see how undocumented it is?
• What happens to the running cost if our volume doubles?
• Who owns the accounts, the workflows and the data on the day the project ends?

The list of systems is the estimate. A number arriving without the list is a position, not a price.

What keeps costing after the build is signed off

A project price answers one question and leaves three unanswered. Anything touching live systems carries a running cost, and owners who budgeted for a build get an unpleasant surprise in the second quarter.

Maintenance is the line that decides whether the system is still running a year later. Something has to notice a failure within the week rather than the quarter, and that something is either a person you employ, a support arrangement you buy, or nothing at all. Two of those are a plan. Ask in writing which one you are being sold.

• The platform. Whatever the workflows run on charges monthly, and charges more as volume grows.
• Model usage, billed by how much text goes in and comes back, so a busy month costs more than a quiet one.
• Maintenance, which almost nobody quotes. An interface changes, a credential expires, a message template gets rejected, a workflow starts failing quietly at four in the morning.

Two situations where the honest answer is do not buy yet

If the task happens a handful of times a month, the arithmetic above will tell you so, and no pricing model rescues it. A build has a floor. Somebody maps the process, connects the systems, tests the awkward cases and maintains the result, and that floor does not shrink because the task is small.

The second case is a process nobody describes the same way twice. Automating it means encoding one person's version, and you will pay again the moment the other versions surface. Write it down first. That work is worth doing whether or not anything gets built on top of it, and you can do it without paying anybody.

There is a third, quieter case. If your business is about to change shape, through a new product line, a new market or a migration already scheduled, wait for the new shape. Automating the current one buys something you are about to throw away.

What one supplier does with this question, and what it refuses to do

An example of the argument above, from the company publishing it. Wobble puts no price on any page, which is inconvenient and consistent. What is published instead is the work with figures attached: a delivery line rebuilt as one audited automation of 34 AI nodes for Quillon, and voice agents running more than 500 calls a day for Big Texas Land Buyers. The company is based in Karachi, bills month to month and is answerable for what it operates across 25 engagements in six countries, which is the arrangement that keeps a running cost visible instead of buried inside a project fee.

Underneath the pricing model question sits an ownership question. A build you hold outright and a subscription you rent produce identical demonstrations and completely different positions in month eighteen. Ask where the workflows, the credentials and the data live, and whether you own the system in a form somebody else could pick up. If the honest answer is a login to a supplier's product, the number you were quoted is not the price. The price is that number plus whatever it costs to leave.

The cheapest quote is frequently not to buy at all. A task that is genuinely rules-based, happens many times a day and touches one system your own team can already reach is within range in-house, and the floor a build carries is exactly why: somebody has to map the process, connect the systems, test the awkward cases and maintain the result, whether that somebody sits inside or outside. Where the person inside enjoys this and will still be there next year, what you would be buying is their attention rather than the capability. Haad, the co-founder who owns growth and client solutions, does the diagnosis that decides which of those two you are, and the answer is sometimes the second one.

One running cost is easy to miss because it is not paid in money. Anything worth automating also needs a stop, and somebody has to stand on the other side of it. Spending, pricing, anything published in your name and any serious complaint should wait for human approval, and a workflow meeting a case it was not built for should hand it to a person rather than improvise. Budget the hour a week for reading what came through that stop. A system nobody reviews still costs money and produces confidence rather than output.

Common questions

How much does AI automation cost?

There is no standard figure. The price is set by how many systems have to connect, whether any of them lacks a proper interface for software, whether the process is documented, and how much volume runs through it. Before speaking to anyone, work out what the task costs you today. That gives you a ceiling, and a ceiling turns a quote into a decision.

Why will nobody publish a price on their website?

Publishing a number invites comparison against a scope nobody has agreed, and in this market the standard reply to a price question is a request to take it to a direct message. That habit has costs of its own, borne by whoever then answers every enquiry personally. The reasonable middle is a provider who explains the pricing model and the variables in public, then quotes after seeing the process.

Is a fixed price or a monthly retainer better?

They answer different questions. A fixed scope project suits a finite build with a defined end and puts the risk of overrun on the provider. A retainer suits work that genuinely keeps changing. The arrangement to watch for is a finished build billed as a retainer, because you are then paying monthly for something that is not changing.

What is the difference between the build price and the running cost?

The build price covers mapping, connecting, testing and handover, and happens once. The running cost covers the platform the workflows sit on, the model usage they consume, and the maintenance that keeps them alive when an interface changes. That last part is the easiest to leave out of a proposal, so ask for it separately and in writing.

How do I compare two quotes that are far apart?

Ask both parties for the list of systems they assumed and the split between one time and recurring charges. Wide gaps usually come down to one side having spotted an application with no usable interface, or having included process mapping the other intends to bill for later. Comparing totals without the lists compares two different projects.

Can we start small to keep the cost down?

Yes, and it is usually the right sequence. One workflow, chosen because it repeats often and its rules fit on a page, gives you a real number for the next one and a real answer about whether your systems cooperate. Committing to a whole programme first is buying an estimate rather than a result.