Nobody will give you a number, and there is a reason for that. But "it depends" is a useless answer, so here is what it actually depends on, and where the money genuinely goes.
Three separate costs
Most confusion comes from treating this as one number. It is three.
Build. One-time. Someone works out what the process actually is, then implements it. This is the biggest single line and it scales with how messy the current process is, not with how impressive the automation looks.
Run. Ongoing infrastructure. A small server, a platform subscription, phone or messaging fees. This is usually the smallest of the three and the most predictable.
Model usage. Variable, and the one people forget. If the automation calls a language model, you pay per use, and the amount depends on volume and on how much text moves through it each time.
What drives the build cost
Four things, roughly in order of impact.
How stable the process already is. Automating a process that people perform consistently is straightforward. Automating one where three people each do it differently means someone first has to decide which way is correct, and that is a business conversation, not a technical one. It is also where most of the time goes.
How many systems have to talk. One system is simple. Two systems with a clean API is fine. Five systems where two have no API and one is a spreadsheet somebody emails around is a different project entirely.
How bad the failure would be. Automation that drafts an internal summary needs far less engineering than automation that sends messages to customers. Error handling, retry safety, and approval gates are most of the work in anything customer-facing, and skipping them is how you end up with a system nobody trusts.
How much is genuinely new. Common patterns like missed-call follow-up or review requests are well understood. Something specific to how your business works costs more because nobody has solved it before.
The costs that catch people out
Model spend with no ceiling. An automation that loops on a failure can run up a surprising bill overnight. Usage limits should exist before launch, not after the first bad month.
The maintenance nobody scoped. Automations break because something upstream changed, not because they degraded. An API version, a renamed field, an expired credential. Someone has to notice and fix it. If that person was never named, the automation quietly stops working and the money spent building it is gone.
Migration off a per-task platform. Per-task pricing is comfortable at low volume and uncomfortable at high volume. If you are heading somewhere busy, work out the crossover before you build, because moving live automations later is considerably more annoying than choosing correctly at the start.
The process work. Frequently the largest hidden cost. You are often paying to have a fuzzy process made explicit for the first time, which is valuable but is not what people think they are buying.
What makes it worth it
The honest test is not cost, it is whether these three things are true:
- The same work repeats often enough that the pattern is obvious
- The manual version already works consistently
- The delay or the effort is costing something real
If all three hold, automation usually pays back quickly, because you are removing a recurring cost with a one-time one. If any of them is shaky, the automation will be expensive relative to what it returns, and the right answer is to fix the process first.
Why we do not publish prices
Because a number quoted before anyone understands your systems is a guess, and a guess anchors the conversation in the wrong place. Two businesses asking for "the same" automation routinely differ by a large multiple, entirely because of how much already works.
What you should expect is a written scope and a written price before any work starts, and a clear split between what is a fee and what is a vendor cost.
More on how our pricing works, or tell us what you are trying to automate and you will get a straight answer, including when the answer is that automation is not your problem.