We publish no price for anything, including the AI Audit: fixed fee and fixed scope, four weeks, half at kickoff and half when the plan is delivered. Every build is quoted to its own scope, and we do not publish a range for builds because any range wide enough to be honest is too wide to be useful, and any range narrow enough to be useful would be a guess dressed up as a fact.
So this page does the more useful thing. It sets out what actually moves the number, what a real quote itemizes line by line, how to read a quote that is suspiciously cheap or suspiciously vague, and when the right answer is to spend nothing at all.
Start with what the job is worth, not with a price list
Pick the one process you would automate first and count what it currently costs you. Hours per week, whose hours, and their loaded cost, meaning salary plus payroll tax and benefits, not the hourly rate you imagine. Then add the money that leaks rather than gets spent: calls nobody picked up, invoices that went out late, orders re-keyed into a second system with a typo in them, quotes that took three days when the customer wanted one. That leakage is easy to miss, and it is the part most owners never total up.
At 20 people this is countable by hand. Ask the two people closest to the process to keep a tally for one week: every time they retype something, chase something, or fix something that should not have broken. A week of tallies from real people beats a month of estimating from a spreadsheet, and it also tells you whether the process is stable enough to automate at all.
Now you have the number that governs everything else. A build worth having should pay back its cost inside a year, and that is a bar you can hold any vendor to out loud in the sales call. If the process is losing you very little, a quote to automate it is not worth taking whatever the number on it is. If the process is bleeding serious money every month, the question stops being what it costs and becomes how quickly it can ship and how confident anyone is that it will hold.
That ranking exercise is the whole substance of an audit. For Nobel Tip Kitabevleri, a medical publisher and retailer, we audited 100% of departments in person (measured) and delivered one prioritized AI roadmap, which the company then executed (measured). The client reports operating costs down 18% since (client-reported). The ranking is what made the spend decidable: not a list of things AI could do, but an ordered list with a value and a build time attached to each line.
What actually moves the number on a build
Five things move it, and everything else is detail. The first is how much of the project is still undecided. Nobody can price what has not been decided, so an undecided scope is priced with a risk margin baked in, and you pay for that margin whether or not the risk shows up. The single cheapest thing you can do to lower a quote is to arrive with the process written down, the exceptions listed, and the decision already made about what happens when the automation is unsure.
The second is integrations: how many separate systems have to talk to each other, and whether they have usable connections. Two systems with real APIs is ordinary work. The same two systems where one is an older package with no API, or a portal a person has to log into, is a different project with a workaround at the center of it, and workarounds cost more to build and more to keep alive. Ask any vendor to name the connection method for each system before they name a price.
The third is the state of your data. If your customer records live in three places with three spellings of the same company name, someone has to reconcile that before anything automates cleanly, and that someone is either your team for free or the vendor for money. The fourth is exception handling and human review: a workflow that runs unattended is cheaper than one where a person approves each result, and the approval step is often the right call, but it is a design decision with a cost, not an afterthought.
The fifth is ownership. A build that lives in your own accounts, with credentials in your name, costs more up front than one assembled inside a vendor's platform, because you are buying the build rather than renting access to it. Our builds work that way as standard, and the honest tradeoff is that the invoice is larger on day one and the running cost afterward is your own usage at cost, with nothing marked up on top. Which is cheaper for you depends on how long the automation lives and how hard it runs.
What a real quote itemizes
A quote you can actually evaluate names the exact processes in scope and, just as importantly, what is explicitly out of scope. It lists each system it will touch and whether new access has to be created. It says what happens to exceptions, meaning the cases the automation cannot handle, because that is where every disappointing project goes wrong. It names the deliverable in terms a non-technical person can check on the day, and it names who owns the accounts and credentials at handover.
It also separates two kinds of money that get blurred together constantly: what you pay the vendor, and what you pay your own suppliers afterward. Model usage, phone minutes, and any platform subscriptions are running costs you carry directly in accounts you hold. A quote that folds all of that into one monthly figure is hiding which part is the vendor's margin and which part is the meter. Ask for it split.
Ours states the payment schedule plainly: milestone based and always split in half, 50% at kickoff and 50% at launch for a build, and the same split for consulting except the second half falls when the plan is delivered, because nothing launches in that engagement. Typical builds ship in 14 to 21 business days, and smaller single-workflow projects in 7 to 10. Every project includes one week of post-launch support, and ongoing support after that is an optional retainer priced to how much you want covered.
If what arrives is one line and one number, it is not a quote. It is a hope with a total at the bottom, and the gap between the hope and the work will be settled later as change orders, at a moment when you have already paid a deposit and lost your leverage.
How to judge any provider on price, including us
Get two or three quotes, but make sure every vendor saw the same written scope. Different vendors quoting from different conversations produces three prices for three different projects, and comparing them tells you nothing except who was most optimistic. Write one page describing the process, the systems, the volume, and the exceptions, and send that same page to everyone. This is the highest leverage hour you will spend on the whole purchase.
Then ask each of them two questions: what would make this price go up, and what would make it go down. A vendor who has actually priced the work answers immediately and specifically, because they know which assumptions are load bearing. A vendor who cannot answer has priced the logo, the industry, or their read of your budget rather than the job.
A suspiciously cheap quote has three possible readings and you should find out which. Either they misunderstood the scope, which is the common one, and the difference arrives later as change orders. Or the low number is a setup fee attached to a permanent monthly subscription, where the real price is the next three years and the workflow stops the month you do. Or they have genuinely built this exact thing before and it really is cheap, which is the good case, so ask to see the one they built and ask what happens when an unusual case shows up.
A vague quote is the other failure. If the proposal sells transformation, strategy, or enablement without naming a thing that will be different in 30 days, ask what specifically changes, who does it, and what you still own if you stop paying. And if you handle patient or client data, no quote and no vendor makes you compliant, ours included: ask what data leaves your systems, where it is stored, who can read it, whether they will sign a BAA if you are in healthcare, and what their breach notification window is in writing. A vendor who deflects that question has answered it.
When not to buy, and when the cheaper answer is fixing the process
Automating a broken process makes it break faster and at higher volume. If the reason your team retypes data is that a form asks for the wrong fields, fix the form. If the reason quotes take three days is that one person has to approve them and that person travels, change the approval rule. At 20 people a surprising share of what looks like an AI problem is a settings problem in software you already pay for, and those fixes cost nothing but an afternoon of somebody's attention.
If the volume is small, do not buy anything. A task that takes one person twenty minutes a week is cheaper left alone than automated by anyone, us included, and the maintenance attention a build quietly demands is a real cost that never appears on a quote. Automate what hurts by lunchtime, not what merely annoys you on a Friday.
If your process changes every month, wait. A build encodes a process, so it is only worth what the stability of that process is worth, and a business still figuring out how it works should keep figuring rather than pour concrete around this quarter's version. Wait until the same steps have run the same way for a few months, then automate them.
And if cash is genuinely tight, do not buy the audit either. Do the tally week yourself, take the free thirty minute call, or use our free intake, where we send back within two business days with a ranked map of the three places AI or automation would pay back fastest for you, and if the honest answer is that nothing pays yet, the map says that. The audit is worth buying when you have several candidate projects, no way to rank them, and a decision that is expensive to get wrong. If you already know your one bottleneck, skip the diagnosis and ask for a quote on that single fix.