Once a team is selling alongside the founder, making this the standard for everyone is part of fractional revenue leadership.
A proposal request can hide several different questions
Someone asks you for a proposal. You take it as a good sign and promise to send one by Friday.
Before you do, it's worth finding out what they need it for. They might be choosing between suppliers. They might need a rough number for next year's budget. They might be trying to understand what your product actually does.
Each is a reasonable reason to ask. Each needs a different response.
A rough price range could help the person planning a budget in minutes. A detailed scope might help the person comparing suppliers. Giving both people the same proposal can create work for you and leave their actual question unanswered.
One seller describes the familiar disappointment: "You spend time doing it, you tell your manager so he's proud of you. You send the proposal and then.... nothing."11 Public seller discussion, “Selling a quote or proposal”. The quoted passage describes one person's account of proposal work without a response; no frequency or measured time saving is inferred.https://www.reddit.com/r/sales/comments/1h6ecak/selling_a_quote_or_proposal/ That is one person's account, but the missing question is useful: what was supposed to happen after the proposal arrived?
Sending it was within the seller's control. Getting a buying decision wasn't. When the second is uncertain, it's tempting to keep doing more of the first: another version, another demo, another follow-up.
You can end up working harder on a deal without understanding it any better.
Accurate CRM records are part of pipeline hygiene. RevPartners defines it around auditing and standardising CRM data.22 Adam Statti, RevPartners, “HubSpot CRM Pipeline Hygiene”. First-party advice used to compare a data-quality definition with the work-allocation question developed here; not an effectiveness study.https://blog.revpartners.io/en/revops-articles/hubspot-crm-pipeline-hygiene You need that. But the record also needs to explain why the next task belongs on your calendar.
I would start with one question, before the next substantial piece of work:
To make this useful, what are you trying to work out?
Then ask:
If it answers that, what would you do next?
That is suggested wording, not a demand for a promise to buy. You're trying to understand the job the buyer needs your work to do. Once you know that, you can often offer something more useful than the thing they initially asked for.
Match the response to the decision
Consider four hypothetical buyers asking for more information. These are invented examples to show the judgment, with suggested replies you can adapt.
The first buyer needs to check whether refunds reach their finance system without creating duplicate entries. Their engineer will review the result with finance on Friday. They want a demonstration because that behaviour could stop them proceeding to a technical evaluation.
There is a specific question here. Before building anything, check whether an existing connector report or standard walkthrough answers it. If it does, send that and arrange to discuss the result.
If their particular retry behaviour remains untested, a small custom test could earn its place. Use a sandbox and synthetic test transactions. Agree the expected number of entries and the reconciliation total before running it. That makes the result something both sides can inspect.
A useful reply would be:
Could we test the duplicate-refund case and review the reconciliation result together? That should tell us whether this part needs more work before you evaluate further.
Confirm the setup and access needed before committing your team. The buyer's Friday review gives the test a purpose. It does not mean they have promised to buy, or that every other part of the purchase is settled.
The second buyer says they need a rough number for next year's plan. Their decision is whether to include an allowance. They aren't asking their team to choose a supplier yet.
Send the range, the assumptions behind it and the things that could change it. If price depends on volume, show the volume assumption. If implementation costs extra, make that visible. A bespoke proposal can wait until there's a scope to price.
You could say:
I'll send the range and the assumptions behind it. When you need to price a specific scope, we can work through that together.
You have answered the buyer's question without pretending a purchase is further along than it is. Keep their planning date in the notes. Don't turn it into a close date unless they have described a purchase process that supports one.
The third buyer says handoffs keep going wrong, but they don't know whether software would help. There is a problem worth exploring and no clear product question yet. A broad demo would ask them to spot their answer among your features.
Offer a smaller conversation:
Would it help to walk through one recent handoff and see where it broke?
The fourth buyer is browsing. They say the team won't consider this until its November planning meeting, and they don't want to investigate anything now. Send a useful overview. Leave the custom work off this week's plan.
If they want a follow-up, suggest reconnecting after that meeting. If they don't, keep the history and respect that. Preserving a relationship doesn't require inventing a task for it every week.
When the buyer doesn't know, help them find out
A buyer whose handoffs keep failing may not know whether software would help. In this hypothetical situation, start by helping them understand the failure.
Start with the last time the problem happened. Who was handing work to whom? What should the next person have received? What arrived instead? What happened because of the gap?
A redacted summary can be enough. Don't make a buyer gather a pack of evidence just to prove they're serious. Ask for information because you need it to understand the problem, and offer an easier way to explain it when possible.
In a short first conversation, you might discover that the receiving team never knew the work was ready. That gives you a specific thing to investigate: how the handoff is signalled and whether the signal reaches the right person.
Or you might discover that the notification arrived, but nobody had agreed who should act on it. A more elaborate product demo would leave that responsibility question open. Help the contact establish ownership before proposing a technical fix.
Those are hypothetical outcomes, but they show what makes discovery useful. The conversation changes your view of what should happen next. You aren't just collecting more detail about an opportunity you've already decided to pursue.
For this example, offer a 30-minute first conversation around one handoff. That's a suggested scope, not a rule about how long discovery should take. The purpose is to finish with a clearer problem and a decision about what is worth investigating next.
Budget may still be unknown. Your contact may not be able to introduce the person who approves spending. Record those gaps honestly. You can help someone understand a problem before they know how their company would pay to solve it.
MEDDICC describes qualification as a continuous process throughout the deal.33 Andy Whyte, MEDDICC, “MEDDICC versus other qualification frameworks like BANT”. The publisher's description of qualification as a continuous process, not independent comparative validation.https://meddicc.com/resources/meddicc-versus-other-qualification-frameworks-like-bant That leaves room for this learning. You don't need a complete buying plan at the first meeting, but you do need to notice what each conversation adds.
If the next call would repeat the last one, pause and ask what is missing. Perhaps a colleague needs to explain the handoff. Perhaps the buyer wants to wait. Perhaps there is no useful question for you to answer at the moment.
A pause is reasonable when neither side can name useful work to do now. Missing budget alone doesn't tell you that. Neither does a buyer declining an arbitrary task. The decision rests on whether you can help them resolve something that matters.
Stalled deals, where the buyer has gone quiet, need a different approach: start from the last thing the buyer confirmed.
Count the work before you promise it
A custom proposal can look like a single task while making claims on several people's time.
For the hypothetical refund test, suppose sales preparation needs three hours, technical validation needs four and your review needs one. The proposed commitment is eight team hours. Put all of them beside the request before accepting it.
| Contribution | Planned time |
|---|---|
| Sales preparation and scope | 3 hours |
| Technical validation | 4 hours |
| Founder review | 1 hour |
| Total | 8 team hours |
That is an illustrative estimate, not a claim that the work will take this long in your business. It also doesn't tell you to reject the test. Eight hours could be well spent resolving a question that is blocking a worthwhile purchase.
The estimate lets you ask a better question: is this the smallest useful way to answer it?
If the uncertainty is duplicate entries, test duplicate entries. You may not need a polished demonstration of the entire product, a redesigned workflow and a full commercial proposal at the same time.
A useful test still has to compete with your other commitments. If two deals need the same engineer this week, compare the cost of delay, the commercial value you can support and the buyer's actual timing. This check helps you scope the work; it doesn't rank every deal for you.
This is where the distinction pays off for a founder. You can stay helpful while being specific about what your team is agreeing to do. You don't have to choose between accepting the whole request and making the prospect feel unwelcome.
A useful boundary sounds like:
We can answer the pricing question now. For the tailored test, let's agree which behaviour you need to check so we can scope the work properly.
Use this before promising discretionary work. If you've already made a commitment, honour it or discuss a change openly. A new internal process isn't a reason to quietly withdraw what the buyer was told to expect.
Put the buyer's next step beside your own
Open the opportunities with substantial work planned this week. Write down what the buyer is trying to decide, what is still unknown and what you have agreed to do about it.
Keep a buyer-confirmed step separate from a step you hope they'll take. The difference matters when the plan is reviewed by someone who wasn't on the call.
For the four hypothetical examples, the completed review looks like this:
| Buyer situation | Decision and missing answer | Buyer next step | Seller response and effort |
|---|---|---|---|
| Refund integration | Whether to proceed to technical evaluation; duplicate handling is untested | Engineer reviews the result with finance on Friday | Check existing material first; scope a sandbox test if needed. Illustrative estimate: 8 team hours, subject to agreed access and scope |
| Next year's budget | Whether to include an allowance; needs a price range | Planning date known; purchase step unknown | Send standard pricing and assumptions. Effort not yet estimated; no bespoke proposal planned |
| Broken handoffs | Whether to investigate a fix; cause of a recent failure unclear | Discovery conversation offered, not yet agreed | Propose one 30-minute walkthrough. Preparation and other team time not yet estimated |
| Browsing before November | No current decision or investigation requested | November meeting known; follow-up not yet agreed | Send overview; pause custom work. Standard-response effort not yet estimated |
If you're looking at your own deals and still unsure which deserve more work, bring that question to founder-led sales coaching. We can work through what to ask, what to offer and what to do next.
For your own deals, add an owner and a review trigger. Also note why existing material cannot answer the question whenever you choose custom work. That short explanation makes an expensive request easier to challenge without challenging the person who brought it in.
One sales representative describes their tendency plainly: "My biggest flaw as an SDR rn is I get happy ears easily."44 Public sales representative discussion, “How do you disqualify fast and identify tire kickers?”. The quotation illustrates self-reported optimism, not its prevalence or a verified performance result.https://www.reddit.com/r/sales/comments/10mp9mh/how_do_you_disqualify_fast_and_identify_tire/ Keep the enthusiasm. Write the buyer's actual answer beside it so someone else can see where the confidence comes from.
After the work, return to the question it was meant to answer. Did the test resolve the uncertainty? Did the price range fit the plan? Did the handoff conversation reveal something worth fixing?
If the answer is no, find out why before producing another version. The test may have been inconclusive. The information may not have reached the right person. The buyer's priorities may have changed. Silence doesn't tell you which explanation is true.
Gong's analysis of recorded meetings from 28,833 closed deals found more first-meeting discussion of next steps among faster deals.66 Chris Orlob, Gong Labs, “Short sales cycle”. Original observational analysis of recorded meetings from closed deals; association between first-meeting next-step discussion and sales-cycle speed, not proof of causation or a PAIN performance benchmark.https://www.gong.io/blog/short-sales-cycle That association doesn't prove that these questions speed up a sale. The practical reason to ask is simpler: both sides should understand what the work is for.
Let qualification change the work you choose
The PAIN Threshold asks you to establish the problem, who can decide, why the buyer would act now and whether budget exists.55 PacedRevenue framework registry, PAIN Threshold and Qualification Debt. House definitions, not validated performance benchmarks.https://pacedrevenue.com/insights/pipeline-physics/glossary/ Use those questions to spot what you still need to understand.
For the handoff buyer, the problem is becoming clearer while the budget and decision process remain unknown. For the refund buyer, a technical question and review step are clear, but that still doesn't establish the entire commercial case.
Keep those gaps visible. One encouraging answer cannot stand in for all the others.
Carrying unanswered questions forward while committing more work creates the cost described by Qualification Debt.55 PacedRevenue framework registry, PAIN Threshold and Qualification Debt. House definitions, not validated performance benchmarks.https://pacedrevenue.com/insights/pipeline-physics/glossary/ The review sheet gives you a place to see that cost before adding another task.
On the PACED map, this sits within Capture: helping an interested buyer work through a purchase. If the obstacle is an unanswered question in an existing deal, adding more leads leaves that question open and gives the team more work to juggle.
Your sales pipeline stages should reflect the buyer's progress. Sending a proposal can be recorded as a task completed. Moving the deal forward needs the evidence your stage definition requires.
Keep this separate from forecasting. The worksheet tells you what to work on; it contains no tested probability that a deal will close. To check the revenue prediction itself, see how to measure forecast accuracy.
At your next pipeline review meeting, start with one demo or proposal already on the calendar. Fill in its buyer decision, unresolved question, next step and full team effort. If a field is unknown, use the next conversation to find out.
If you need help locating the wider problem, the free PACED diagnostic is a starting point. You can use this check now: before agreeing to the next custom piece of work, make sure you understand what it will help the buyer decide.