Pitch Paid Discovery Before Quoting the Full Delivery

By pitch.dogFoundation15 min read20 September 2026

Business

The request arrives with a deadline attached, and it usually sounds like this: build us a customer portal. You know enough to price something. What you don't know is whether the thing they asked for is the thing causing the trouble.

Quoting anyway produces a guess with a number on it. Pad the price to absorb the uncertainty and you look expensive next to someone who didn't pad. Price it tight and meet the real constraint in week three and you look unreliable. Neither failure is a failure of nerve. It's a proposal that never said what was still unknown.

Paid discovery is a small, bounded piece of investigation sold on its own terms. It has four working parts: a named uncertainty that could change what gets built, an examination described by what it will settle, an output the customer can use even if they never hire you again, and an end condition that includes stopping. Get those right and the proposal mostly writes itself. Get them wrong and you've either sold a workshop that teaches nobody anything, or dressed up a fixed delivery project as a study.

The unknown has to be able to change the answer

Start with the specific thing you don't know, not with the fact that you don't know things. Useful unknowns tend to fall into four groups:

The actual problem. They asked for a portal; the trouble may be a phone line, a form, a handoff, or a decision nobody has authority to make.
A system constraint. A connection the whole approach depends on may not be possible, or may only be possible in a form nobody wants.
The work behind the interface. What people do today, in what order, with what fallback when it fails, is usually undocumented and occasionally decisive.
The people affected. Who absorbs the cost of the current arrangement, and whether the people asking are the people paying it.

Each unknown earns its place by connecting to a possible change. If the constraint is real, the approach changes. If the problem is somewhere else, the scope shrinks or vanishes. That connection is the whole argument, and it should be visible in the proposal — not implied by the word "discovery."

Three questions sort the real ones from the decorative ones.

If the answer came back one way, would we build something different? If it came back the other way, would we not build it at all?
Could we answer it from evidence that already exists — the ticket log, the analytics, the last two attempts at this?
Will the customer act on the answer, including acting on an answer they don't like?

A question that fails the first test is not discovery. It's a delay with a name badge. A question that passes the second test should be answered now, in the conversation, for free, and then you quote the work you can already see. And a customer who won't act on the answer — who needs the project to happen for reasons of their own — is not buying information. Charge them for the thing they actually want and stop calling it research.

This is where a standard sales process is a bad guide. Plenty of teams run a discovery step because it's step one, and the workshop produces a requirements list for the build that was always going to happen. That's not inquiry; that's a toll gate. The test isn't whether the engagement fits your process. It's whether the customer's next decision could go a different way because of what you find.

Describe the examination, not the calendar

A proposal that lists six weeks of interviews has told the customer what you'll be doing. It hasn't told them what they'll know.

Those are different things, and the second one is the deliverable. "Understand the current customer journey" is an activity. "Establish where in the current journey people give up and telephone instead" is an answer, and it implies the activity. Lead with the answer. Let the activity follow as the method.

Two shapes that work:

A workflow inquiry. You follow a single question from the customer's side — where they look first, what they find, who they eventually speak to — and you establish where the breakdown occurs. The useful output is a location, not an impression: at this handoff, between these two teams, for this kind of question.

A bounded technical investigation. You establish whether an assumed connection is viable before anyone depends on it. The useful output is a verdict on feasibility, with the conditions attached, and a clear statement of what you couldn't test.

Both are specific enough that the customer can argue with them before you start, which is a feature. If they read the examination and say "that's not where we think the problem is," you've learned something useful at the cheapest possible moment.

What to avoid is the calendar as deliverable. A list of workshops, interviews, and review sessions is an itinerary. The customer can't use an itinerary to make a decision, and neither can you. If they can't predict what they'll know at the end from reading the middle of your proposal, rewrite the middle.

Say what the output is, and what it isn't

Usable outputs are concrete artifacts. Among the ones worth naming:

An examined problem boundary. A written statement of what you looked at, what you found, and where you stopped — with the evidence behind each.
Supported options. Two to four routes, each with what it depends on, what it costs in effort and change, and what it leaves unsolved.
An identified prototype question. The one thing that only building a small version would settle.
An account of consequential constraints. System limits, ownership, regulatory requirements, staffing — anything you found that would shape any route.

Then say what the output will not establish, in the same proposal, in plain sentences. Discovery narrows uncertainty; it does not eliminate it. It does not produce a fixed delivery quote. It does not prove a solution works. It does not decide for the customer. And an identified prototype question is not a tested prototype — the sentence you write should describe a question you would take into a prototype, not results from one.

That distinction matters beyond pedantry. A proposal that borrows the authority of research that hasn't happened yet will be read, later, as a promise. Say it in the future tense: you will have, we expect to find, this will not tell you.

Here's what those sentences look like on the page:

At the end of this engagement you will have: a written boundary of the problem we examined, with the evidence behind it; two or three routes with their dependencies and their gaps; the single question we would need a prototype to answer; and a list of the constraints we found but could not resolve within this scope. You will not have a fixed delivery quote, a tested design, or a working system.

That paragraph does more selling than any amount of confident prose about transformation, because the customer can picture the thing they're buying.

Make their participation part of the scope

Discovery is a joint activity, and the proposal should say so before it says what you'll charge. Name what you need and who can authorize it:

Records. Contact logs, ticket categories, analytics, the last failed attempt at this.
Systems. Read access, a sandbox, or — when access isn't given — the documentation and one session with someone who knows the system.
People. A named set of staff with actual time attached, not "availability as required."
An authorizer. One person who can grant the access above and receive the findings.

Then explain how missing participation would limit the answer, in advance, while it's still a hypothetical. Without the contact records, you can describe what customers say publicly but not whether the recurring questions are the ones everyone believes they are. If the three people who run the process can't be released for an afternoon, the finding narrows to what the written record shows. Saying this early turns a later shortage into a scheduled limitation instead of an argument.

Two things to keep out of this section. Don't presume access to sensitive systems or unlimited staff time as though they were obviously available; the customer's constraints are part of what you're scoping, and putting them in the proposal is a courtesy, not a demand. And don't quietly bundle the follow-on build into the discovery offer. Fees, ownership of the outputs, reuse, and any later work belong in the actual agreement, described honestly, which usually means saying plainly that commissioning discovery is not approving implementation. The customer keeps the findings either way. If that sentence makes the proposal harder to sell, it's doing the work that "no obligation" is supposed to do without being vague about it.

Why charge at all? Because the customer's decision is the product, and a decision someone has paid for gets made. Unpaid versions of this tend to collapse into sales calls with better stationery — shorter, thinner, and almost impossible to end honestly, because nobody wants to be the person who spent a week and delivered bad news for nothing. A fee sets a floor under the work. It also gives you the standing to say stop.

Give the engagement an end decision

A discovery proposal without an end condition is an open tab. Say what would make the inquiry sufficient to proceed, sufficient to change approach, and sufficient to stop.

Sufficient to proceed: the problem boundary is supported by evidence the customer accepts, at least one route survives the constraints you found, and the remaining uncertainty is one a prototype could answer.

Sufficient to change approach: the evidence points somewhere other than the assumed solution — the phone line, the content, the ownership of a page, the terms of a contract.

Sufficient to stop: the assumed solution isn't the cause, or the constraints rule it out, or the fix turns out to be something the customer can do themselves with the account you've written.

The UK government's service manual, in its guidance on how the discovery phase works (GOV.UK service manual, How the discovery phase works, reviewed 20 September 2026), treats discovery as learning about a problem and deciding whether to proceed — with stopping as a legitimate outcome rather than an exception to be managed. It also describes reframing a predefined solution, which is exactly the move this whole article is about. That's the distinction worth borrowing. It is UK government service-development guidance, written for a different context; it doesn't prescribe a phase structure to import wholesale, an indicative duration, or a commercial arrangement, and it certainly doesn't establish paid discovery as any particular studio's offer or guarantee later work.

So take the distinction and leave the scaffolding. What matters is that the customer's decision, not your pipeline, determines the outcome — and the proposal should say so in language they'd use.

A fictional example

Nothing below has been researched. The customer, the unknowns, the options, and the stopping outcome are stipulated to make the comparison work; the point is the shape of the two proposals, not the particulars.

Setup. Halden Water, a fictional regional utility, asks a services team for a self-service portal for household accounts. Three things are true and unexamined. First, the contact center handles a lot of repeat contacts, but call reasons are logged under a short fixed category list — the records don't separate "I can't find my bill" from "my bill is wrong." Second, the public web pages are owned by a digital team; the contact center manager can't change them and is vague about how long a correction takes. Third, the billing system is third-party, and whether it can serve account data to anything outside itself is unverified.

Each unknown maps to a possible change. If the repeat contacts are mostly people who couldn't find a simple answer, clearer existing pages may do most of the work, and the portal shrinks or disappears. If the repeat contacts come from the page-ownership split — content can't be corrected quickly, so people ring to check — then a portal fixes nothing and governance does. If the billing system can't serve account data, the portal's central feature isn't viable in the assumed form.

The predetermined version. A one-day requirements workshop with the call center, digital, and operations teams, followed by a fixed-price build proposal. This isn't stupid. If the recurring contacts really are what everyone believes, the workshop is a fast way to gather requirements, and the customer gets a quote in a week. Its weakness is that it treats the belief as a finding. The record that would settle the question isn't examined, and the people in the room are the same people whose current arrangements produced the problem. The workshop produces the input to the answer that was already chosen.

The inquiry version. Three weeks, fictional and stipulated: a sample of recent contact notes read closely, time with three agents across two shifts, the journey walked once from search to telephone, and one session with the billing vendor's integration documentation with the digital team's owner present.

The examination settles four things. Where a customer's question actually goes before it becomes a call. Where the repeat contacts actually come from, once the logged categories are read against the notes behind them. Who can change what, and how slowly. What the billing system will and won't expose. The output is a supported options account:

Route one. Fix the information path: faster corrections, a named owner, plain-language answers to the top recurring questions. Depends on the digital team shortening the correction path. Does not solve the cases where a customer needs something about their own account.
Route two. A small portal covering only the account actions that can't be answered any other way. Depends on the billing system exposing account data, and on those actions really being among the unresolvable ones. Does not solve the content problem if that's the main cause.
Route three. The full portal as originally requested. Depends on everything above. Not recommended until the split in contact reasons is known.

The account also names the open prototype question — whether customers who ring today would complete the top two account actions online unaided — and states what the engagement could not establish: what each route costs, whether the full portal would pay for itself, and whether the vendor integration holds up outside documentation.

The stopping outcome. Suppose the contact sample shows that most repeat calls are simple questions people couldn't find an answer to, and that the digital team can shorten its correction path. The recommendation is route one. No portal this year, no build proposal, and an options account that's still worth the fee — because the customer can now act on it, or hand it to their own team, or to someone else.

The honest ending

End the proposal with what the customer will be able to decide. Not what you'll deliver — what they'll be able to do.

At the end of this engagement you will be able to decide one of three things: build the portal as scoped, build a smaller version of it, or change something other than the portal and not build it at all. We will tell you which one the evidence supports, including when the answer is the third.

That last clause is the whole difference between a discovery proposal and a quote with a study stapled to the front. A customer who has been through a competent engagement can describe their own problem in terms a colleague will accept, name the two or three things they still don't know, and defend either decision — to build or not to build. That's what they're paying for.

And when you can't write that ending honestly — because the evidence is already in the room, or because the customer has decided and only wants a signature — don't sell the study. Quote the work you can see. Otherwise you're back where this started: a guess with a number on it.

Frequently asked questions

What are the four working parts of a paid discovery offer?

A named uncertainty that could change what gets built; an examination described by what it will settle; an output the customer can use even if they never hire you again; and an end condition that includes stopping. The proposal should make each part explicit rather than relying on the word 'discovery.'

How can I tell whether an unknown belongs in paid discovery?

Use three tests: if the answer came back one way, would you build something different, and if the other way, would you not build it at all? Could the answer be obtained from evidence that already exists, such as ticket logs, analytics, or earlier attempts? Will the customer act on the answer, including an answer they don't like? A question that fails the first test is delay; one that passes the second should be answered now for free; a customer who won't act is not buying information.

What should a discovery proposal describe instead of a calendar of workshops and interviews?

It should describe what the customer will know, not merely what you will do. 'Establish where in the current journey people give up and telephone instead' is an answer; it implies the activity. A calendar of workshops, interviews, and reviews is an itinerary the customer cannot use to make a decision. Two useful shapes are a workflow inquiry that locates a breakdown and a bounded technical investigation that returns a feasibility verdict with conditions and untested limits.

What should the output include, and what should it explicitly not establish?

Outputs worth naming include an examined problem boundary with evidence, two to four supported options with dependencies and gaps, the single question a prototype would need to answer, and an account of consequential constraints. The proposal should also say, in plain future tense, that discovery does not produce a fixed delivery quote, prove a solution works, decide for the customer, or deliver a tested prototype. An identified prototype question is not a tested prototype.

How should participation and the ending be scoped?

Name the records, systems, people with actual time attached, and one authorizer you need, then explain in advance how missing participation would limit the answer. Avoid presuming sensitive access or unlimited staff time, and do not bundle the follow-on build into the discovery offer. State end conditions: sufficient to proceed, sufficient to change approach, and sufficient to stop. Commissioning discovery is not approving implementation, and the customer should be able to use the findings either way.