Why Crypto Projects Don't Buy: A Win/Loss Review Playbook
Imagine a crypto project declining your documentation proposal with one sentence: “It was a bit expensive for us.” You record price in your customer relationship management (CRM) system. Next time, you plan to quote less.
But what did the project actually do? Hire someone cheaper? Ask its own engineer? Postpone the launch? Decide that nobody could approve the work yet?
Win/loss reviews help service providers investigate the buying decision behind the recorded reason. Ask the buyer to reconstruct what happened, separate their account from your interpretation, and use the evidence to choose one change worth testing.
This playbook follows a fictional documentation studio through that process. The dialogue and completed notes below are teaching examples, not real customer conversations or evidence of improved sales.
Know which decision you are investigating
A lost proposal and a project that bought nothing can require different responses. Before the conversation, record the outcome you actually know:
- Won: the project commissioned your service. Investigate what made the purchase possible and what nearly prevented it.
- Lost to another option: the project chose another supplier or explicitly chose to do the work internally. Investigate that comparison.
- No purchase: the buyer confirms that the work was postponed or abandoned without commissioning it. Investigate what stopped the purchase.
- Unknown: the conversation ended without a confirmed decision. Keep the outcome unknown, even if your CRM requires you to close the opportunity.
Add the date and source of that classification. A salesperson's assumption and a buyer's confirmation should remain distinguishable. Silence cannot tell you that a competitor won.
Start with one question you need the conversation to resolve. For the documentation studio: “What prevented this team from commissioning the proposed work?” The answer could involve price, scope, proof, timing or a condition the seller never discovered. Do not choose the explanation before the conversation.
If you are deciding where those findings should lead your business next, the guide to selling services to crypto projects in the AI era covers the broader choice between improving delivery, the offer and distribution. Here, the task is to obtain better evidence for that choice.
Invite someone who took part in the decision
Choose recent, concluded buying conversations while participants can still recall the sequence. Keep a list of eligible wins, losses and confirmed no-purchase decisions. Do not let the list consist only of friendly customers or the largest embarrassing loss.
Speak with someone who evaluated the work or participated in approval. Your original contact may understand the evaluation but know little about the final budget discussion. Record that limit; if another participant is needed, ask for an introduction rather than bypassing your contact.
Where practical, ask a colleague who did not sell the engagement to lead the conversation. A colleague can ask an awkward follow-up without defending their own proposal. If you are a solo founder, you can still lead the conversation: acknowledge your role, explain that criticism is useful and resist answering it with a new pitch.
Use an existing, appropriate business conversation. Respect opt-outs and declines; do not chase someone across channels because they ignored a research invitation. A simple invitation could read:
Subject: A short review of our documentation proposal
Thanks for letting us know your decision. We are reviewing how we
scope documentation work and would value your perspective.
Would you be open to a 20-minute conversation about how your team
evaluated the proposal and what happened next? I will use the feedback
to improve our process, without asking you to reconsider the decision.
We would keep notes for our internal review. You can skip any question,
and we will not publish your name or comments without separate permission.
It is completely fine to decline.
Only make commitments you can honor. At the start, confirm who will receive the notes. Ask separately before recording or adding a transcription tool, and offer a notes-only conversation. Keep confidential project details out of shared summaries and use only tools permitted for that information.
The 20 minutes in this invitation is a practical scope for this example, not a proven optimum. Prepare a short guide so the promise is credible.
Reconstruct the decision before testing your explanation
The GOV.UK guidance on research conversations recommends open, neutral questions and concrete experiences, with follow-ups that clarify what the participant means. Those principles are useful here: let the buyer describe the events before introducing your theory.
Use these questions as a route through the conversation. Follow an important answer rather than mechanically reading the next line.
- “What was happening in the project when you first considered this work?” Establish the task or change that prompted the enquiry.
- “Walk me through what happened from that point to the final decision.” Let the buyer give their sequence before filling gaps.
- “Which options did your team seriously consider?” After the answer, check whether handling the work internally or postponing it was also discussed.
- “Who was involved, and what did each person need to decide?” Separate the person requesting the work from people approving money, technical accuracy or access.
- “What did you use to judge our proposal?” Ask which document, example, conversation or comparison affected the decision and how.
- “Where, if anywhere, did the decision become difficult?” Explore the specific moment, what remained unresolved and what happened next.
- “What did the team end up doing?” Confirm the outcome and any difference between the original plan and the work actually commissioned.
- “What have I missed or misunderstood?” Give the buyer room to correct your account.
When someone says “expensive,” ask what they were comparing and what the team did after discussing the cost. When they say “we needed more confidence,” ask what they needed to verify and whether they found it elsewhere.
Avoid opening with “Would a lower price have won the deal?” It invites an imagined alternative and places price at the center of the answer. A buyer's recollection of an actual comparison is more useful than an agreeable answer to your proposed fix.
Win/loss research provider Clozd recommends a topic guide with open questions and optional drill-downs, rather than treating the conversation like a rigid survey. Its guidance is practitioner advice from a company selling win/loss services, not evidence that this playbook will raise your win rate.
Work through a lost documentation proposal
Fictional example: a two-person documentation studio proposed a complete developer portal for a token project's software development kit (SDK). The package included a getting-started guide, integration tutorials and a reference-content review. The project declined. The seller recorded “price.”
The studio owner speaks with the project lead who requested the proposal. Here is the useful part of their invented conversation:
Studio owner: What was happening when you started looking for documentation help?
Project lead: We wanted external developers to try the SDK. Our engineer was answering the same setup questions.
Studio owner: What happened after you received our proposal?
Project lead: I liked having the whole portal covered. Engineering said the setup flow was still changing, though. We could not agree on who would review all the pages.
Studio owner: You mentioned cost in your reply. How did that enter the discussion?
Project lead: Paying for the whole portal felt difficult when we did not know what would be ready. We asked the engineer to fix the quickstart first and parked the rest.
Studio owner: What work was actually approved?
Project lead: Just that internal quickstart update. We did not approve an outside documentation budget.
The buyer has supplied a more specific account. The project wanted a usable starting path, while the proposal asked it to approve a larger body of work before a reviewer and stable setup flow were available.
That still does not prove price was irrelevant. The project lead may not know every budget discussion. A smaller engagement might also have been rejected. Preserve both uncertainties.
In this fictional scenario, the studio then checks the proposal and its own call notes. It records:
| Evidence available | What it supports | What remains unknown |
|---|---|---|
| Buyer says the team chose an internal quickstart update | There was an internal alternative to the proposed full portal | Whether outside help would have been considered for that smaller task |
| Buyer says engineering could not assign a reviewer | Review capacity was an unresolved condition in this account | Whether engineering would describe the obstacle the same way |
| Proposal covers the whole portal; call notes name no technical approver | The seller did not document that approval dependency before quoting | Whether a reviewer existed but was omitted from the notes |
| Buyer originally described the proposal as expensive | Cost was part of the explanation given to the seller | Approved spending limit, competing quote or acceptable price |
Keep the initial message alongside the later account. Do not erase “price” and replace it with another confident label. A useful updated record is: “Internal quickstart chosen; broader portal deferred. Buyer reports uncertain scope and review capacity. Outside budget and price threshold unconfirmed.”
The distinction between observation and interpretation follows the GOV.UK research analysis guidance, which separates what people said or did from findings and subsequent actions. The table above applies that distinction to this fictional buying decision.
Turn the feedback into one change you can check
The tempting response is to discount the same portal package. The evidence suggests a smaller first change: discover whether the team can approve the proposed work before committing effort to a full quote.
For the studio, a completed change brief could look like this:
Finding: In this buyer's account, the full-portal proposal arrived before the team had settled the starting scope and technical review responsibility.
Working explanation: The proposal required more approval than the project was ready to give. Price may still have mattered, but its independent effect is unknown.
Change: Add a review-readiness question to discovery. If only the quickstart is ready, discuss a separately scoped quickstart engagement; if no review capacity exists, pause the quote until that dependency changes.
Owner: The studio founder, who conducts discovery and prepares proposals.
First check: On the next comparable enquiry, establish the exact developer task, stable version or environment to document, review owner and acceptance criteria before quoting. Record whether those answers change the proposed scope or reveal that the job should wait.
Evidence against the explanation: A comparable buyer has stable requirements, a named reviewer and approval capacity, yet rejects the scope because its approved spending limit is lower. That would require investigating affordability instead of attributing the refusal to readiness.
This brief produces a concrete proposal change. For a future buyer who confirms that a smaller engagement is useful, the studio could write:
Proposed first engagement: Document one agreed developer quickstart against the version and test environment confirmed at kickoff. Deliver a setup guide and one runnable example, with one consolidated review round from your nominated technical reviewer. Acceptance means a developer can complete the agreed setup steps in that environment. Additional tutorials, a full reference rewrite and subsequent SDK changes are outside this scope and would be estimated separately.
That paragraph is an illustrative scope revision. The studio still needs to validate feasibility, estimate delivery and agree commercial terms. It has not demonstrated that the buyer would accept it or that it would improve conversion.
If the conversation instead establishes a genuine budget mismatch, use the Web3 service pricing worksheet and guide to check whether a different scope can work economically. For the rest of the buyer document, the one-page service offer guide covers turning agreed work into a clear purchase.
Read several buyer accounts without inventing a pattern
One conversation can justify checking a missing approval question. It is a weak basis for changing every package or lowering every price.
For each conversation, keep the service scope, project stage, participant's role, confirmed outcome, supporting evidence and unanswered questions together. Compare similar buying situations before combining them. A postponed SDK portal and a lost ongoing support contract may have very different constraints.
Include wins. Ask what almost stopped the buyer and what resolved it. Perhaps a winning project already had a technical reviewer, or perhaps it bought despite having the same uncertainty. The second answer would challenge the studio's explanation and deserves attention.
If two participants disagree, preserve their separate accounts and establish which decisions each observed. Do not turn their answers into a single story just to make the report tidy. If nobody accepts a conversation, review your records and keep the buyer explanation unconfirmed.
Keep the invitation denominator visible too: how many eligible buyers were invited, how many responded and which outcomes are missing. “Three buyers we spoke with mentioned review capacity” describes those conversations. It does not establish the percentage of all losses caused by review capacity.
Use recurring evidence to prioritize a change, then check what happens when you apply it. A before-and-after sales result can also reflect different buyers, timing or deal sizes. If your volume can support a controlled comparison, the A/B testing guide for Web3 service businesses explains the design questions. If it cannot, document the operational result without claiming a proven conversion lift.
For the documentation studio, the first useful result may be a quote paused before anyone spends days writing it. At the next discovery call, the owner now has a better question:
“Who will verify that a developer can complete this quickstart, and when can they review it?”