Should You Pay for a Discovery Phase, or Just Get Three Quotes?

Detailed Explanation

The honest answer to this question depends entirely on what you're actually buying, and the market makes that hard to tell from the outside — "discovery," "audit," and "assessment" are used by genuine, useful engagements and by sales funnels disguised as objective advice, often with near-identical marketing language. The buyer's real questions are rarely answered directly by either kind of provider: what do you actually hold at the end of it, is it useful if you decide not to proceed with that provider, does the fee count toward the eventual build, and — the sharpest test of all — is the "audit" capable of concluding you shouldn't automate this at all, or does it only ever conclude one way?

That last question is the cleanest way to separate the two. An auditor who never concludes your process isn't ready for automation isn't running an audit — they're running a funnel with an extra step. A genuine discovery phase treats "this needs process work first" or "this isn't worth automating yet" as legitimate possible outcomes, because the point of discovery is finding out what's actually true, not confirming a decision that was already made before the engagement started.

A discovery phase scoped to one specific process is a narrower cousin of the broader engagement some providers sell as an "AI readiness assessment" — see the actual AUD price bands and what that broader deliverable should contain if what you're weighing up covers more than a single process.

When a Paid Discovery Phase Is Worth It

A discovery phase earns its cost when at least one of these is true:

• The process is genuinely complex or poorly understood, even by the people who run it day to day — multiple systems involved, inconsistent exception handling, or a written procedure that doesn't match what actually happens. See what is process mapping, and do you need it before automating for why automating an unclear process usually just automates the confusion faster.
• Nobody inside the business has the time or the specific skill to map it themselves. Discovery is partly a labour substitute — someone has to interview the people doing the work, reconcile conflicting accounts of how it actually runs, and turn that into a scoped brief, and that's a real, billable task if nobody internal can do it.
• The stakes of getting the scope wrong are high — a process touching customer data, financial transactions, or a business-critical workflow, where a poorly scoped build is expensive to unwind.
• You genuinely want a provider-agnostic deliverable. A discovery phase that produces a real requirements brief and process map — something you could hand to a completely different provider — is a materially different product from a "free audit" that only makes sense read alongside that same provider's proposal.

When Three Quotes Is the Better Call

Skip the paid discovery step and go straight to comparing quotes when:

• The process is simple and well-bounded — a single trigger, a small number of systems, few or no exceptions — the kind of thing an experienced provider can scope accurately from a 30-minute conversation and a couple of follow-up questions.
• You've already done the internal legwork. If you've written your own requirements brief — what triggers the process, which systems it touches, what "done" looks like — much of what a paid discovery phase would produce, you've already produced yourself.
• The quotes you're getting are converging. If three independent providers land on a similar scope and similar price without needing a paid engagement to get there, that consistency is itself useful evidence the process is well enough understood not to need it.

The Four Questions That Tell You Which Kind of "Discovery" You're Being Offered

1. "What do we hold at the end of this, specifically?" A real answer names concrete artefacts — a process map, a documented set of requirements, named recommendations — not "a clear plan for how we'd approach the build." If the deliverable can't be described except in terms of the proposal it leads to, it isn't discovery.
2. "Is it useful if we don't proceed with you afterwards?" Ask this directly. A provider confident in the standalone value of their discovery work will say yes without hesitation, because a genuinely useful process map and requirements brief are useful to whoever ends up doing the build — including a business that decides to build it internally.
3. "Does the fee credit toward the build if we go ahead?" There's a reasonable answer either way (see the FAQ above), but a provider unwilling to give you a straight answer to this question before you've paid anything is telling you something about how the rest of the engagement will go.
4. "Could this conclude that we shouldn't automate this process right now?" This is the sharpest test. If the honest answer is no — if the engagement is structurally guaranteed to end in a proposal to build something — it isn't an audit, whatever it's called.

Things to Consider

• A discovery phase that costs money isn't automatically the trustworthy option, and a free one isn't automatically the funnel. The structure of the engagement — what's promised, and whether "don't automate this" is a genuinely available conclusion — matters more than whether money changed hands.
• Fund uncertain-scope work in stages, not as one open-ended commitment. A fixed-price discovery phase followed by a fixed-price (or fixed-price-per-phase) build replaces an open-ended budget guess with numbers you can actually hold a provider to at each step.
• The questions in this page work just as well applied to your own shortlist as a vetting exercise. See what should you ask an automation consultant before hiring them for the broader due-diligence list this sits alongside.
• Get the deliverable and the fee-crediting arrangement in writing before paying, not discussed verbally and assumed. This is the same principle as vetting any other part of the engagement — a clear written answer beats a confident verbal one.
• Scale the decision to what's actually at stake. A small, well-understood, low-risk automation doesn't need the same rigour as a project touching customer data or a business-critical process — see when should you hire an automation consultant instead of doing it yourself for that broader build-vs-buy decision.

Common Mistakes

• Assuming "free audit" means no cost is involved. A free audit is usually priced into the build it leads to, or exists specifically to produce a proposal — it isn't automatically worse than a paid discovery phase, but it isn't free in the sense of having no influence on what happens next either.
• Paying for discovery without asking what you'll hold if you walk away. If the answer turns out to be "not much beyond a proposal," you paid for a sales process, not an independent assessment.
• Treating scope uncertainty as a reason to commit to an open-ended budget. The right response to genuine uncertainty is a staged, fixed-price structure — discovery first, build second — not an unbounded commitment made before anyone has actually looked closely at the process.
• Never asking whether the audit could conclude "don't automate this." Skipping this question is how a business ends up automating a process that should have been fixed or left alone first, because nobody involved in the assessment had an incentive to say so.
• Comparing headline discovery prices without comparing what each one actually produces. A cheaper discovery phase that yields nothing reusable is a worse deal than a more expensive one that leaves you with a genuine requirements brief.