What's the playbook when a buyer says they have no budget but still wants a demo and proof of concept in 2027?

What "no budget, but show me anyway" actually means

The sentence almost never means the company has zero dollars. Companies that genuinely have no money also have no appetite for a four-week evaluation — they cancel meetings, not schedule them. When a buyer simultaneously says "we have no budget" and "can you run a proof of concept," those two statements are in tension, and the tension is the information. Somebody is willing to spend organizational time on you. Time is the scarcer currency in most B2B orgs. A director who commits three engineers for two weeks has already spent something more expensive than the software license.

So the phrase is doing other work. In practice it resolves to one of five underlying states, and your entire playbook depends on which one you're in.

No allocated line item, but a discretionary path. The most common case. There is no budget code labeled with your category, but the department has a discretionary pool, an underspent line elsewhere, or an executive who can approve at a certain threshold without a formal cycle. The buyer isn't lying; they're describing the org chart, not the bank account. Your job is to find the threshold — many orgs let a VP sign at $25K, a director at $10K, and require procurement above that. A deal sized under the local signing authority converts on a completely different timeline than one that needs a committee.

Budget exists but is spoken for. They're mid-CRM-migration, mid-compliance-project, mid-layoff. The dollars are committed to something with more political weight. This is a real "no," but it's a dated one. The correct move is to establish the date and get out cleanly, because a proof of concept run against a distracted team produces weak results even when the product is good — and a weak result becomes the reason you lose next cycle.

Budget authority sits above the person you're talking to. The champion says "no budget" because "I can't approve this and I'm not sure I can convince my boss" is a harder sentence to say out loud. This is the most salvageable case and the most commonly misread one. The test is simple and non-confrontational: offer to help them build the internal case, and ask who else needs to see it. A real champion says a name. A blocked or unwilling one changes the subject.

No trust yet. They don't believe the claims, so they're not going to fight for money against a thing they think might not work. Budget is a socially acceptable proxy for skepticism. Here a proof of concept is actually the right instrument — that's exactly what it's for — but it needs to be scoped tightly enough that it settles the specific doubt rather than becoming an open-ended feature tour.

They're harvesting. They want architecture diagrams, a competitive datapoint for a renewal negotiation with an incumbent, or free consulting for a project they intend to build internally. This is rarer than jaded reps assume but it is real, and it's expensive: an enterprise proof of concept commonly consumes 40–120 hours of solutions-engineering time plus product and support attention. At loaded cost, that's a real number sitting on your P&L with nothing to show for it.

For RevOps, the distinction matters beyond the individual deal. Every one of these states produces a different pipeline signal, and if your CRM records them all as "Stage 3 — Evaluation," your forecast is fiction. Teams that instrument this properly add a required field on any opportunity entering a technical evaluation: funding path (allocated / discretionary / needs approval / next fiscal / unknown). Six months of that field turns "no budget" from a rep anecdote into a segmentable dataset. You will usually find that one of those five states converts at a rate several times higher than the others, and that reps have been spending their proof-of-concept capacity on the wrong ones.

The other reason to care: unqualified evaluations are the single largest hidden cost center in most go-to-market orgs, because the cost is absorbed by a shared team that doesn't own quota. Solutions engineering capacity gets consumed by deals that were never going to close, and the deals that *were* going to close wait in a queue. RevOps owns that queue whether or not anyone has said so out loud.

The step-by-step process

Run this as a sequence, not a script. Each step is a gate — if it fails, you stop or downgrade rather than continuing on hope.

Step one: acknowledge without flinching. "Totally fine — most of the evaluations we run start before there's a line item." This does two things: it removes the buyer's expectation of a fight, and it establishes that starting without budget is normal in your world rather than a favor you're granting. Never argue with the objection. Reps who push back immediately ("well, what if I could show you an ROI…") signal that they think budget is the obstacle, which teaches the buyer that budget is a lever they can keep pulling.

Step two: quantify the pain in their numbers, not yours. Ask for one operational metric you can do arithmetic on. Not "what's this costing you" — that's too abstract and buyers deflect it. Ask for the mechanism: how many hours per week does the team spend on the manual step, how many deals slipped past quarter-end last quarter, how long does onboarding a new rep take before they're productive, what's the error rate on the current process. Then do the math out loud and let them correct you. "So six reps, four hours a week each, at a fully loaded rate — that's roughly a quarter of a headcount burning on data hygiene. Does that feel right or am I overstating it?" Letting them correct your estimate downward is more persuasive than defending an inflated one, because the number ends up being theirs.

Step three: ask the funding question directly. This is the pivot the entire playbook hangs on. "Assuming the proof of concept works exactly the way we both hope — what happens next? Where would the money come from?" Then stop talking. The answer sorts them into the five states above within about ten seconds. "I'd take it to Dana" is a path. "We'd have to see" is not. "It'd go into next year's planning cycle, which starts in October" is a path with a date on it. Write down the literal words in the CRM; they're the most predictive thing you'll collect all cycle.

Step four: trade scope for commitment. Do not say yes or no to the proof of concept. Say "yes, and here's what it costs you" — where the cost is denominated in commitment, not dollars. Specifically: a written success criterion both sides sign, access to the systems required, named participants who will actually show up, a fixed end date, and an agreement about what happens if it succeeds. That last clause is the one people skip and it's the load-bearing one. "If we hit the number we agreed on, you'll bring it to Dana with a recommendation within two weeks" is a small, reasonable, entirely non-financial ask that a genuine buyer accepts without blinking and a harvester will not.

Step five: downgrade rather than decline. If they won't commit, you don't say no — you offer the cheaper rung. There's a ladder here: recorded demo → live tailored walkthrough → a short diagnostic or assessment against their own data → sandbox with sample data → full proof of concept against production data. Each rung costs you more and should cost them more commitment. Almost nobody needs the top rung to make a decision; they ask for it because nobody offered them rung three. A two-hour diagnostic that produces a one-page findings document often does more to unlock budget than a three-week build, because it gives the champion something they can forward.

Step six: instrument the outcome. Whatever happens, the funding-path answer, the rung you landed on, and the eventual result go into the system. This is what converts a rep's judgment into an org-level capability.

Costs, timelines, and typical ranges

Be honest about what these things cost, because the discipline only holds if you can price the thing you're protecting.

What a proof of concept actually consumes. A light sandbox evaluation — sample data, standard configuration, a couple of guided sessions — typically runs one to two weeks and consumes somewhere in the range of 10–25 hours of solutions-engineering time. A production-data proof of concept with integrations, security review, and custom configuration is a different animal: three to six weeks elapsed, commonly 40–120 hours across SE, product, and support, plus whatever the buyer's own team spends. At fully loaded rates for senior technical staff, that middle case lands in the low tens of thousands of dollars of internal cost. It is entirely reasonable to say that number out loud to a buyer. "This is a real investment on our side too" reframes the conversation from you-asking-them-for-money to two organizations deciding whether to spend together.

Elapsed time is the enemy. Long evaluations decay. Champions change roles, priorities shift, the sponsor's budget gets reallocated, and the momentum that made the evaluation possible dissipates. Anything past about four to six weeks tends to lose more to organizational entropy than it gains in technical proof. If the technical question genuinely requires eight weeks to answer, that's a signal to narrow the question, not extend the clock. Pick the single riskiest assumption and test only that.

Structure the calendar as gates. For a two-to-three week evaluation: a kickoff where success criteria get signed, a checkpoint around the one-third mark where you show early signal and explicitly ask whether this is still solving the problem you both named, a second checkpoint around two-thirds where you surface the preliminary economics and ask whether to prepare a proposal, and a close-out where you either move to proposal or document why not. The mid-point checkpoints are where you learn things. A buyer who won't take the two-thirds meeting has already decided and hasn't told you.

Paid pilots and their trade-offs. Charging for the evaluation — a nominal fee, often credited against the first year if they buy — is the sharpest qualification instrument available. Someone who will approve a small amount has demonstrated a funding path, which is the exact thing you were trying to learn. But there are real costs. A fee introduces a procurement step that can add weeks, may require legal review, and in some organizations is harder to approve than a much larger annual contract because it's an unbudgeted new-vendor payment rather than a planned one. Paid pilots work best in enterprise motions with genuine implementation complexity and land badly in product-led or mid-market motions where the buyer expects to self-serve. Judge by the friction of the buyer's own approval process, not by your desire for a signal.

Discount pressure downstream. Extended free evaluations reliably erode price. The buyer has now spent weeks with the product for nothing and has internalized a zero-dollar price point. Sales cycles that include a long unpaid proof of concept tend to close at lower realized rates than ones that didn't, partly because the free period established an anchor and partly because the buyer's leverage grew with your sunk cost. If you run a free evaluation, keep it short and keep the commercial conversation running in parallel rather than deferring it until after — the price should be on the table before the evaluation ends, not introduced as a surprise at the finish line.

Capacity math for RevOps. Model your evaluation capacity like any other constrained resource. If you have three solutions engineers who can each carry two concurrent evaluations, you have six slots. If the historical win rate on evaluations that started with a named funding path is meaningfully higher than on those without — and it almost always is — then the slot allocation policy writes itself. Publish it. A written rule ("technical evaluations require a documented funding path and a named economic buyer") is far easier for a rep to enforce with a customer than a case-by-case judgment call, because the rep can point at the policy rather than appearing to distrust the buyer.

Where teams get it wrong

Treating the objection as a pricing problem. The instinct is to discount, and it's almost always wrong here. Discounting into a no-budget objection when there's no funding path just makes a nonexistent purchase cheaper. It also tells the buyer your price was soft, which follows you into the actual negotiation. Cut scope before you cut price — a smaller first phase with a narrower footprint is a real answer to a real budget constraint. A 30% discount on the same scope is a concession without information.

Confusing enthusiasm with authority. The most engaged person in the room is frequently the person with the least budget authority — the analyst drowning in the manual process, the engineer who hates the current tool. Their enthusiasm is genuine and valuable and completely uncorrelated with whether money moves. Teams overweight it constantly. The correction isn't to dismiss the champion; it's to explicitly ask them to introduce you upward and to notice what happens when you do.

Running the evaluation against the wrong question. Buyers ask for a proof of concept to answer a doubt, and reps deliver a feature tour instead. Before you build anything, ask: "What would you need to see to be convinced?" and then build only that. An evaluation that proves eleven things nobody was worried about and doesn't address the one thing they were fails even when everything works.

No written success criteria. Without a signed definition of success, the goalposts move — not usually out of bad faith, but because new stakeholders join mid-evaluation and bring new requirements. The one-page criteria document is the cheapest insurance in the entire motion. It should specify the metric, the threshold, the data source, the timeframe, and what both parties do if the threshold is met.

No agreement about what "pass" triggers. This is the biggest one. Teams negotiate hard over what the evaluation will prove and never negotiate what happens if it proves it. Then it succeeds and the buyer says "great, we'll revisit in the fall." The commitment clause needs to be established at kickoff, when goodwill is high and the ask sounds procedural, not at the end when it sounds like pressure.

Letting evaluations run open-ended. An evaluation without an end date isn't an evaluation, it's a free trial with a support contract. Set the date at kickoff, communicate it, and honor it. Extending once, for a concrete reason, with a new fixed date, is fine. Extending twice means the deal is dead and the team hasn't noticed.

Not routing the "no" back into the business. When an evaluation fails on a genuine product gap, that's the highest-quality product feedback the company can get — a specific, named, dollar-attached reason someone didn't buy. Most organizations lose it entirely because it lives in a rep's notes. A structured loss reason on failed evaluations, reviewed quarterly with product, turns wasted SE hours into roadmap input. This is squarely a RevOps responsibility and it's rarely anyone's job.

Applying enterprise discipline to a self-serve motion. All of the above assumes a considered purchase with a technical evaluation. In a product-led motion the answer is the opposite: give them the product, remove every gate, and let usage do the qualifying. Demanding a funding path before a free trial in a self-serve business is friction that costs you far more than the unqualified trials do. Match the discipline to the deal size.

Ignoring the incumbent-renewal pattern. A specific and recognizable version of harvesting: a buyer with a renewal coming up runs an evaluation to generate leverage against their current vendor. Signals include a hard interest in pricing details early, reluctance to involve technical staff, a timeline that suspiciously matches a renewal date, and no interest in implementation logistics. It's not malicious — it's procurement doing its job — but it should change how much you invest. The tell is asking about implementation timeline: a genuine buyer engages with that question, a leverage-seeker doesn't care.

Decision framework: when to choose what

The framework is two axes. First: is there a credible funding path, meaning a named person, a mechanism, and a rough date? Second: is there a specific technical doubt that only a hands-on evaluation can resolve? Those two questions produce four quadrants, and each one has a clean answer.

Funding path plus a specific doubt. Run the full proof of concept. This is what the instrument is for. Scope it to the doubt, set the date, sign the criteria, get the commitment clause.

Funding path but no specific doubt. They don't need a proof of concept, they need a proposal. Buyers in this quadrant often ask for an evaluation out of process habit rather than genuine uncertainty. Offer a tailored walkthrough and a reference call with a similar customer instead, and move to commercial terms. You'll close faster and they'll thank you for it. If they insist on an evaluation anyway, that insistence itself is worth probing — it usually means there's an unstated doubt or an unstated stakeholder.

Specific doubt but no funding path. This is the "no trust, no money yet" case, and it's the interesting one. The doubt is real and resolving it may create the funding path. Run something cheap: a short diagnostic against their data, a sandbox with sample data, a targeted technical session with your architect. Timebox it hard. The deliverable should be a document the champion can forward upward, because the actual goal isn't proving the product — it's arming the champion.

Neither. Recorded demo, relevant content, a dated follow-up, and your attention goes elsewhere. Be warm and be brief. A clean, friendly exit preserves the relationship for when their situation changes, and situations change constantly — reorgs, new executives, a bad quarter that makes your category suddenly urgent. The rep who exited gracefully gets the call. The rep who spent three weeks building something free and then went cold does not.

Two refinements on top of the grid. Deal size sets the discipline level. Below roughly a mid-four-figure annual value, the qualification overhead costs more than the unqualified evaluations do — just let people try it. Above six figures, expect and welcome a formal evaluation as part of the process. The framework's strictness should scale with the cost of being wrong.

Strategic exceptions are legitimate but must be named. Sometimes you run a free evaluation for a logo you want, a new vertical you're trying to enter, or a design partner who'll shape the roadmap. That's a real business decision. It just needs to be made deliberately, at the right level, and tracked separately — not smuggled in as a rep's optimistic read on a stalled deal. The RevOps version: a small explicit quota of strategic evaluations per quarter, approved by a leader, reported on separately. That gives the org flexibility without letting the discipline erode by a thousand individual exceptions.

Related questions

How do I ask about budget without sounding like I'm interrogating them?

Frame it as sequencing, not screening: "So I scope this right — if it works, what does the approval path look like?" You're asking to be useful, not to gatekeep. Buyers answer that version readily because it sounds like planning rather than qualification.

What if the buyer says a proof of concept is the only way to get budget?

Often true, and it's a legitimate path. Accept it — but require the other commitments in exchange: signed success criteria, a named approver who's seen the plan, and an agreement to present within two weeks of a pass. Free work plus zero commitment is the combination to refuse.

Should I ever charge for a proof of concept?

In enterprise motions with real implementation complexity, frequently yes — a nominal fee credited against year one qualifies harder than any question. In mid-market or self-serve motions it usually adds more procurement friction than the signal is worth. Judge by their approval process, not your preference.

How long should I keep pursuing a no-budget account?

Set a date rather than a cadence. If they name a planning cycle, calendar it and check in once before, lightly. Continuous pursuit of an account with no funding path trains you to mistake activity for pipeline. Two to three touches per quarter is plenty.

What should RevOps actually build to support this?

A required funding-path field on any opportunity entering technical evaluation, a capacity model for solutions-engineering slots, structured loss reasons on failed evaluations, and a quarterly review comparing win rates by funding-path category. Four artifacts, all cheap, all durable.

FAQ

Is a demo ever worth giving to a buyer with no budget?

A standard demo, yes, almost always — it's cheap, it builds relationship, and situations change. The line isn't at the demo, it's at the custom build. A tailored walkthrough costs an hour; a production-data proof of concept costs weeks. Give away the hour freely and price the weeks in commitment.

How do I quantify their pain without them thinking I'm building a case to charge them more?

Ask for the operational mechanism rather than the dollar figure, then do the arithmetic out loud and invite correction. "Six reps, four hours a week — does that sound right?" People defend numbers they helped produce and dismiss numbers handed to them. Let them revise it downward; a conservative number they own beats a large one they doubt.

What's the single most predictive question to ask?

"If this works exactly the way we both hope, where does the money come from?" The answer sorts genuine opportunities from exploratory ones within seconds, and it's non-confrontational because it presumes success. Record their literal words in the CRM — that phrasing predicts outcome better than any stage field.

The champion won't introduce me to anyone with authority. Is that fatal?

Not immediately, but it's the strongest negative signal available. Ask once, directly, framed as help: "Would it be useful if I put together something you could take to your VP?" A willing champion says yes. Repeated deflection means they either lack standing or aren't as committed as their enthusiasm suggests — downgrade the rung accordingly.

What do I do when the evaluation succeeds and they still say there's no budget?

That's a kickoff failure surfacing late. You didn't establish what a pass triggers. Salvage what you can — ask for the introduction, the reference, the internal presentation slot — and then fix the process: from now on, the commitment clause gets agreed before any work starts, when it reads as procedural rather than as pressure.

Does any of this apply to a product-led or self-serve motion?

Mostly inverted. When the product qualifies itself through usage, gating access on a funding path is friction you can't afford. Reserve this discipline for considered purchases where a human team is spending real hours. Match the rigor to the cost of being wrong, not to a company-wide default.

Sources

• https://hbr.org/2012/07/the-end-of-solution-sales
• https://www.gartner.com/en/sales/topics/b2b-buying-journey
• https://www.gartner.com/en/sales/insights/b2b-buying-journey
• https://hbr.org/2017/03/the-new-sales-imperative
• https://blog.hubspot.com/sales/sales-qualification
• https://www.salesforce.com/resources/articles/sales-process/
• https://www.forrester.com/blogs/category/b2b-sales/
• https://www.mckinsey.com/capabilities/growth-marketing-and-sales/our-insights

Related on PULSE

• What's the best discovery question to ask when a buyer says they're "just exploring" with no clear timeline?
• How should marketing staff deals when sales says they're too early and need more nurture, but the deal keeps stalling?
• DevTools sales to engineering orgs: Why do technical evaluations take 4x longer than expected, and how should you compress the proof cycle?
• How do you run QBR pipeline reviews when Palantir AIP proof of concepts delay stage progression?
• Why Do Buying Committees Now Insist on AI-Generated ROI Proof Before Vendor Demos?
• Why are buying committees increasingly demanding proof of AI model bias mitigation in vendor RFPs?