Who can tell me whether an AI quote I received is reasonable?

Start with the shape of the document, not the number at the bottom. A quote you can judge has a one sentence statement of the problem in your words, a list of what gets built with each piece named, the specific systems it connects to, who does the work, a timeline with milestones, a payment schedule, what you own at handover, what happens in the weeks after launch, and a short list of assumptions and exclusions. Nine items. A quote missing four of them is not a quote, it is a price tag with a logo on it.

The exclusions matter more than people expect. A good vendor writes down what is not in scope, because that is where change orders come from later. If the document never says what would count as extra work, then everything is extra work later, and the number you agreed to is the floor rather than the price. Ask directly: what would make this cost more than the figure on this page, and get the answer in the document rather than in an email.

Compare it against how the work is normally structured so you can spot an outlier. Our own builds ship in 14 to 21 business days, smaller single workflow projects in 7 to 10, payment is milestone based and split in half, 50% at kickoff and 50% at launch, and every project includes one week of post launch support. Those are our terms, not an industry rule, but they give you something to hold a quote against. A build quoted at six months with everything due up front and no support window is not automatically wrong, and it might be a genuinely large project, but it is a question you should make them answer.

One line item deserves its own scrutiny: who does the work. Ask whether the person in the meeting writes the code, or whether the build goes to a team you will never speak to. That single answer explains most of the gap between two quotes for what looks like the same thing.

Whose account does this run in? That is the first question, and the whole review turns on it. If the automation lives in the vendor's workspace, under the vendor's logins, on the vendor's phone numbers, then you are not buying a system, you are renting access to one, and the quote should be read as a subscription no matter what it calls itself.

Demand four things in writing. First, the accounts are registered to your business and you hold the admin login. Second, the credentials that connect your tools, the API keys and app authorizations, are created under your emails rather than theirs. Third, the build exports in a format another developer can read, and you get a copy at handover. Fourth, you get documentation: what runs, when it runs, and what it touches. Everything we build works this way as standard, in your own accounts with your own credentials, and plenty of independent implementers work the same way. It is a normal thing to ask for and an unusual thing to be refused politely.

Then run the exit test on the quote in front of you. If I revoke your access and stop paying you next month, what breaks? The honest owned answer is nothing: the automations keep running, the logs keep writing, and the next developer reads what exists. If the answer involves a migration project, an export request, or a wind down period, the price on the quote is not the price of the system. It is a deposit on a relationship you cannot leave cheaply.

Ask what happens to the phone number and the data, specifically. Numbers can be ported, and conversations, transcripts, and records should be exportable in a normal file format on request rather than trapped in a dashboard. If a vendor cannot tell you plainly how you would take your own call history with you, that is a fact about the product, not a paperwork detail.

Almost every AI build has a running bill under it, and a reasonable quote separates that bill from the build fee instead of leaving you to discover it in month two. The usual sources are the AI model usage itself, which is billed by the underlying vendor per unit of text or per minute of speech, telephony minutes if there is a phone line, the subscription for whatever automation tool the workflows run on, hosting if anything needs to sit somewhere, and paid tiers on your own software that the integration suddenly requires. Any of those can be modest. All of them together, unmentioned, can double what you thought you agreed to.

Ask three questions about that layer. Are these costs passed through at cost or marked up, and by how much? Do the accounts belong to me, so I see the real invoice? And what does my monthly bill look like if volume doubles? That last one exposes the pricing model that hurts quietly: per task or per execution billing means the bill grows every time the automation succeeds, so a build that pays for itself at today's volume can stop paying for itself precisely because it worked.

Now the phrase that deserves its own paragraph. When a vendor says we host it for you, translate it as: the system runs in our account, on our subscriptions, under our control, and your monthly payment includes our margin on infrastructure you never see. Sometimes that is a fair trade and worth paying for, particularly if you have nobody technical and no wish to have one. But it changes what the quote is. You are buying an ongoing service, so judge it as a service: what is the monthly figure, what does it include, what happens to it at renewal, what notice period applies, and what do I walk away with if I cancel. If the answer to the last one is nothing, the setup fee was never a purchase.

Finally, ask what a support retainer covers before you agree to one. Ours is optional and priced to how much the client wants covered, and any honest version of it should list what is included: monitoring, fixes, changes, or all three. A retainer with no scope is a subscription for peace of mind, which is a real product, but you should know that is what you bought.

Everyone who reviews an AI quote for you has an incentive, and ours is obvious: we build these systems. So apply the same skepticism to the reviewer that you are applying to the quote. The single most useful test is to ask the reviewer to name what is good in the document. A review that finds every line wrong, every price inflated, and every term dangerous is not a review, it is a pitch with a clipboard.

Ask three things of anyone offering a second opinion. What in this quote is fine, and why? What would you need to know about my business before you could say the number is wrong? And are you quoting me for the same work? The second question is the important one, because a price cannot be judged without knowing how many systems have to talk to each other, whether those tools have usable connections, what volume runs through them, how messy the existing data is, and how much human review the work needs. Anyone who declares a number too high without asking about those is guessing at your expense.

The strongest reviewers are the ones with nothing to sell you: a developer you already trust, a peer in your industry who bought the same thing last year and will tell you what the second year actually cost, or an advisor billed for advice rather than for the build. If you have one of those available, use them first. Bring us in when you want someone who has shipped the specific kind of system in question and can tell you whether the scope is real.

For the record, here is the commitment we make on those calls. If the quote is reasonable, we will tell you to sign it. If the number is fair but the ownership terms are not, we will say that instead, because that is usually a redlining problem rather than a vendor problem. And if the quote is fair and the vendor knows the domain better than we do, saying so costs us nothing worth keeping. A firm that cannot tell you a rival did good work is not a firm whose opinion is worth much.

If the amount at stake is small and the commitment is short, sign it and learn. A month of a self serve tool teaches you more about your own workflow than a week of evaluation will, and the cost of being wrong is one month. Reviews earn their keep on the builds that are hard to reverse: the ones touching revenue, the ones with a long contract, and the ones where leaving means rebuilding.

The bigger reason to walk away from the whole conversation is that the process underneath is not ready. If nobody in the business can describe what happens today, step by step, with who does what and in what order, then no quote for automating it can be reasonable, because nobody knows what is being bought. Automating an undefined process does not fix it, it just makes the confusion faster and harder to see. Write the current process down first. That costs an afternoon and it frequently reveals that two of the five steps exist for reasons nobody remembers, which is a free improvement no vendor will ever sell you.

The same goes for a demand problem. If the phones are quiet and the pipeline is thin, a quote for handling calls better is answering a question you do not have, and automating a quiet office only makes it quietly cheaper. Fix where the work comes from first. And if your processes change every month, buy later: a build ranks and hardens stable work, and you have nothing stable yet.

If you already know your one bottleneck, you do not need a diagnosis either. An owner who can name the job that bleeds money every week should ask for a quote on that one fix, from us or from whoever wrote the quote you are holding, and skip the audit entirely. We will give one without selling you the audit first, and we will say so on the call if the audit is not worth it for your business.