The Discovery Questions That Set Your AI Automation Price
Learn the discovery-call questions, scoping method, and milestone structure that turn AI automation projects into defensible, well-priced proposals.
How do you price an AI automation project without guessing?
You price it by turning the client’s own numbers into a value estimate, then anchoring your fee to a percentage of that value instead of your hours or your costs. That means running a real discovery call before you ever say a price out loud: uncovering how much time or money the current process burns, what happens if the problem isn’t solved, and why the client is talking to you instead of building it themselves. The number you land on should be defensible enough that you can explain exactly where it came from if a client asks.
TL;DR
- Discovery comes before price. Quoting a number before you understand scope and value is how sellers underprice or overpromise on AI builds.
- Value beats hours. Hourly billing rewards slowness, so pricing should anchor to the value the system creates, not the time spent building it.
- The 10x rule is a useful gut check: if the client’s estimated annual value is roughly ten times your fee, the investment becomes an easy yes.
- Three question buckets (why this, why now, why me) surface objections and urgency before they can quietly kill a deal later.
- Proxy questions let you size a project even when clients won’t share exact costs or salaries, using volume, headcount, and frequency instead.
- Maintenance retainers should cover keeping a system working as scoped, not free ongoing feature development, and need to be priced so they don’t lose money.
- Capturing a baseline metric up front matters because it’s the only way to later prove the system worked and win expansion business.
Other agents start typing. Remy starts asking.
Scoping, trade-offs, edge cases — the real work. Before a line of code.
Why does discovery matter more than the price itself?
Most pricing mistakes in AI automation work trace back to skipping or rushing discovery. A vague scope leads to a guessed number, and a guessed number is impossible to defend when a client pushes back or asks how you arrived at it.
The fix is treating the first call as a scoping and value-finding exercise, not a sales pitch. Before quoting anything, walk the client through how the solution would work, what testing looks like, and how it changes their operations. Then explain that giving an accurate estimate requires understanding the complexity of the system once it’s actually integrated into their business.
This isn’t stalling. Clients who push for a number immediately, before any real conversation about their process, are often shopping quotes across multiple vendors just to compare cheapest labor. That’s a legitimate signal to disengage, because that buyer isn’t looking for a partner or consultant, they’re looking for the lowest bid.
What questions actually uncover the value of a project?
Start by letting the client talk without steering them. Ask what they’ve tried before, what’s worked, and where things get stuck. Take notes, listen, repeat back what you heard, and probe gently. Then pivot to the after-state: what does the business look like once this is running successfully? What’s the best-case outcome?
From there, run three buckets of questions:
Why this. Confirms that what the client is asking for actually solves their problem. Clients often request an AI agent when the real fix is a simpler deterministic script and a notification.
Why now. Surfaces urgency. A closing window or competitive pressure signals real financial stakes tied to speed, which affects what the project is worth to them right now.
Why me. The uncomfortable one. Ask directly why they wouldn’t just build this internally, hand it to an intern, or vibe-code it themselves. This question exists to pull objections out into the open while you’re still on the call, where you can respond to them, instead of letting those doubts quietly sink the proposal later. When a client admits “yeah, my nephew could probably build this,” don’t argue. Agree, then ask who’s going to monitor it when a model updates at 2am, or who handles it when usage scales past what they expected. Then stop talking and let them answer, because their answer is usually the real reason they need outside help.
How do you size a project when clients won’t share exact numbers?
Clients rarely hand over salaries or internal costs directly. They don’t need to. Three sizing questions work as reliable proxies:
- How long does this take you today?
- How many people touch it?
- What happens when it goes wrong?
- ✕a coding agent
- ✕no-code
- ✕vibe coding
- ✕a faster Cursor
The one that tells the coding agents what to build.
These measure the ceiling of value, not the build itself. Stack on more proxy questions depending on the business: number of locations, volume on the busiest day, how often the issue occurs. Even in marketplace settings where you’re forced to quote a price before a conversation happens, job posts usually reveal volume or complexity clues. State your assumption openly in the proposal, something like pricing based on an estimated 200 occurrences a month, and invite a short call to adjust if that assumption is wrong. That turns a cold quote into a reason to talk.
If you genuinely can’t land on a number after gathering this information, that’s a signal you don’t understand the value well enough yet, and the proposal isn’t ready to be written.
Why doesn’t hourly billing work for AI automation work?
Hourly billing pays you more for being slow. Two developers billing the same rate: one finishes a feature in a day, the other takes three days. The slower one just tripled the fee for worse output. As AI tools make experienced builders faster (a task that used to take a week now taking an afternoon), hourly billing directly punishes that improvement by shrinking the bill.
Hourly rates aren’t useless everywhere. For a first project or two, when there’s no track record or proof to point to, a simple hourly rate is an easier ask for both sides and a reasonable place to start. Past that point, the incentive problem makes it worth moving to value-based pricing.
The relationship to keep in mind is: cost is the floor (the number below which the work isn’t worth doing), value to the client is the ceiling (the most the solution is worth to their business), and price sits somewhere between those two. Cost doesn’t justify price. Price justifies cost. A vendor raising rates because their own expenses went up, without the client getting any more value, isn’t a pricing model that holds up.
How do you turn value into an actual number and structure the deal?
Once you have an annualized value figure (time saved multiplied by hourly cost, multiplied by frequency, projected across a year), a common approach is pricing the build at somewhere between 10% and 20% of that annual value. A useful gut check is aiming for the client’s return to look like roughly a 10x multiple on their investment over the first year, since that math makes the decision easy to justify internally.
Alongside the build price, a maintenance retainer covers keeping the system doing what was originally scoped: fixing breakage, adjusting for API or model changes, handling edge cases. It is not free ongoing feature development. New functionality is a separate, additional conversation and quote. Retainer pricing needs to stay above what it actually costs to support the system, or it becomes a loss on every client.
One mistake worth avoiding: failing to capture a baseline metric before the system goes live, and failing to re-measure it a month, two months, and three months after launch. Without before-and-after numbers, there’s no way to demonstrate the system’s real impact, which weakens your position when trying to win expansion work or renew a retainer. Surfacing those numbers isn’t bragging, it’s often the only way the business actually notices the value being delivered.
Frequently Asked Questions
What’s the first question to ask on an AI automation discovery call?
Remy doesn't write the code. It manages the agents who do.
Remy runs the project. The specialists do the work. You work with the PM, not the implementers.
Open broadly: ask the client to explain everything about the problem, what they’ve tried, and where it breaks down. Avoid jumping straight to price or technical scope until you understand the current process and its cost.
How do you price an AI project if the client won’t share their internal costs?
Use proxy questions instead: how long the task takes today, how many people are involved, and what happens when it fails. Combine those with volume indicators like locations, busiest-day counts, or frequency to build an estimated value figure without needing exact salary data.
What’s a reasonable AI automation price relative to the value it creates?
A common range is 10% to 20% of the client’s estimated first-year value from the automation, with a target of showing roughly a 10x return on their investment to make the decision straightforward.
Should AI automation maintenance retainers include new features?
No. Maintenance retainers should only cover keeping the system functioning as originally scoped, fixing breakages, and adjusting for changes like API updates or model releases. New feature requests are a separate, additional quote.
Is hourly billing ever appropriate for AI automation work?
It can work for early projects when there’s no track record to point to, since it’s an easier, lower-risk ask for a new client. Once you have proof of results, value-based pricing avoids the problem of hourly rates penalizing you for working faster.