I need my team to perform.
Rehearse against the hardest buyer.

The Objection Library — demo run

Input: sample-objections.md, six objections across four deal stages.

1. "Your number is nearly 40% more than [Competitor], I don't see how I justify that internally." — Proposal

• Category identified: A. Price / Budget
• Deal stage: Proposal
• What's actually being tested: The number is real now — they're testing whether it's negotiable, or whether they misjudged the deal size internally before bringing it to you.
• Response guidance: Don't react to the 40% gap by moving toward it. Ask what's included in the [Competitor] number they're comparing against — most competitor comparisons at this stage are list-price-to-list-price, not scope-to-scope. Unbundle your own price so they can see what's actually inside it, then ask which specific piece they'd cut if the number needs to move — let scope or timeline absorb the pressure, not price.
• Don't: Don't lead with "we can probably do something on price" — that confirms the number was soft and invites them to keep pushing on it instead of on scope.

2. "It's not a priority for us this quarter. Check back in Q2." — Discovery

• Category identified: B. Timing / Priority
• Deal stage: Discovery
• What's actually being tested: Could be genuinely not urgent, or a polite decline wearing a timing excuse — the two look identical from the outside.
• Response guidance: Ask directly: "What would need to change for this to become a Q1 problem instead of a Q2 one?" If they can name something specific (a renewal date, a headcount change, a deadline), that's a real trigger worth calendaring against. If they can't name anything, this is a soft no — log it as such and don't spend more cycles chasing a re-engagement that isn't coming.
• Don't: Don't accept "check back in Q2" as a scheduled follow-up on its own — get the specific reason first, or the Q2 touch will get the same answer.

3. "We just rolled out [Incumbent Tool] eight months ago, not sure leadership has the appetite to rip that out." — Evaluation

• Category identified: C. Incumbent / Status Quo
• Deal stage: Evaluation
• What's actually being tested: Whether the pain from the incumbent is real enough to justify the cost — financial and political — of switching only eight months in.
• Response guidance: Name the switching cost yourself before they raise it again: acknowledge that ripping out an eight-month-old rollout is a real cost, not a trivial one. Then ask what specifically isn't working with the incumbent today — if there's no answer, this deal likely isn't ready to move regardless of your pitch. If there is a specific gap, quantify what it's costing them against the switching cost you just named, using their numbers.
• Don't: Don't ignore or downplay the switching cost — naming it first is what makes the rest of the conversation credible instead of salesy.

4. "This needs to go through legal and security review before we can sign." — Negotiation

• Category identified: E. Authority / Procurement, Legal, Security Review
• Deal stage: Negotiation
• What's actually being tested: Whether this is genuinely the last step, or a new blocker appearing this late in the process.
• Response guidance: Ask for the specific review still outstanding and the named person or team running it — "legal and security review" as a phrase covers a lot of ground; get it down to an actual owner and an actual open item. In parallel, get your own security questionnaire and DPA moving now rather than waiting to be asked, since being the reason for delay at this stage is avoidable.
• Don't: Don't accept "it's with legal" without a name and a specific remaining item — a vague answer this late is often a stall from someone still not fully sold, not a real procurement step.

5. "We've been tracking this in a shared spreadsheet and it's fine. Not sure we need a whole tool for it." — Discovery

• Category identified: D. Build vs. Buy
• Deal stage: Discovery
• What's actually being tested: Real ownership pride in a process that works well enough, or a cost that's never actually been counted because "the spreadsheet" doesn't show up as a line item anywhere.
• Response guidance: Ask who maintains the spreadsheet today and how much of their week it takes — not rhetorically, get an actual estimate. Let them do the labor-cost math themselves rather than asserting it for them; if the honest answer is "twenty minutes a week," this genuinely may not be worth solving yet, and that's a fair outcome to leave the call with.
• Don't: Don't imply the spreadsheet is primitive or that "a real company" wouldn't run this way — it got them this far, and the person on the call may be the one who built it.

6. "Can you send case studies from companies actually our size? I've been burned by vendor promises before." — Evaluation

• Category identified: F. Trust / Proof (dominant)
• Secondary concern flagged: The "been burned before" clause is not fully answered by a case study. It's a risk-allocation concern — what happens if this doesn't work as promised — which the reference set's Trust category covers as proof of fit but not as protection against a bad outcome. Address both, separately.
• Deal stage: Evaluation
• What's actually being tested: Whether your proof matches their specific situation (size, vertical, use case), compounded by a stated history of vendor promises that didn't hold up.
• Response guidance: On the surface ask — give a reference matched specifically on size, not just industry; if the closest available case study is a different size band, say so plainly rather than stretching it. On the secondary concern, don't let it pass unaddressed: ask what happened with the previous vendor specifically, and consider whether a bounded pilot, a success-metric checkpoint, or an explicit exit clause addresses the actual fear better than another case study would.
• Don't: Don't answer only the case-study request and treat "been burned before" as a throwaway line — it's the more load-bearing sentence in what they said.

Honesty check

• 5 of 6 classified cleanly against a single category and stage. One (#6) was genuinely compound, and the reference set as built only covers the proof half of it cleanly — the risk-allocation half ("been burned before") is adjacent to Trust/Proof but isn't really the same concern, and forcing it into that cell would have under-served the actual objection.
• The stage mattered more than the wording in at least two cases: #1's price objection and #3's incumbent objection would both get meaningfully worse advice if answered as if they were Discovery-stage — "ask what the problem is costing them" is close to useless once a number is already on the table.
• What's still weak: the six-category set has no explicit slot for a "we were burned before" risk/trust-in-vendor-promises objection — it's distinct enough from generic Trust/Proof (which is about whether the product works for a company like theirs) that it may deserve becoming a seventh category rather than a permanent footnote on category F. Worth a real decision, not a patch.
• What to capture for sharper input next time: the buyer's literal words, not a paraphrase — #5's "not sure we need a whole tool for it" only reads correctly as Build vs. Buy because the spreadsheet detail survived the paraphrase; a looser summary ("buyer seemed lukewarm") would have been unclassifiable against this reference set.

Pitch Pressure-Test — demo run

Input: sample-pitch-and-persona.md — FlowMetrics 7-claim pitch outline, persona Dana Okafor (VP Sales Ops, industrial distributor, burned by a prior forecasting tool's failed 25% accuracy promise, one more swing of internal credibility left).

Persona frame

Dana Okafor owns forecast accuracy and answers for it to the CFO every month. Eighteen months ago she championed a tool that promised a 25% accuracy lift and delivered almost nothing, because the underlying CRM data her reps entered was too inconsistent for any model to work with — she had to explain that miss personally. The CFO now interrogates every software ROI claim she brings forward. She has enough credibility left internally for one more attempt at this category, not two. Every claim below gets read through that specific lens: does this pitch account for the failure mode that sank the last one, or is it making the same promise with a different number attached.

Claim-by-claim

Verdict

Stall, not kill — but only just. The pricing term is a genuine point in FlowMetrics's favor: no long-term contract directly reduces Dana's actual personal risk, which the pitch doesn't seem to realize is its strongest card. But every other claim in the deck — accuracy, implementation speed, and AI risk-detection — rests on the same unstated assumption: that the underlying CRM data is clean enough to make the model work. That is precisely the mechanism that sank Dana's last tool, and the pitch never addresses it once. Until FlowMetrics states what data quality it actually requires and what happens when a customer's data looks like Dana's, every accuracy and speed number in the deck is a repeat of the exact promise that already cost her credibility once. That's the single structural fix, not the pricing, not the case-study specificity — this one.

Honesty check

• The gate did real work here: five of seven claims scored 0, which is a low-evidence pitch by this rubric's own standard, not a pressure-test being unfairly harsh. A pitch this thin on proof would draw similarly hard pushback from most skeptical operational buyers, not just one shaped like Dana specifically.
• What's genuinely solid: every pushback line ties to something concrete in Dana's stated history (the 25% miss, the messy CRM, the CFO scrutiny) — none of it is generic "have you considered ROI" filler, and claim 7 shows the method can also concede a point in the pitch's favor rather than attacking everything reflexively.
• What's still weak: the persona was built from a rich, deliberately detailed input. A thinner persona (role and company size only, no scar tissue, no current-tool detail) would produce noticeably more generic pushback — the product's quality is directly gated by how much the customer is willing to tell you about their buyer, and that dependency should be stated up front to the customer, not discovered by them after a weak run.
• A real limitation noticed while running this: claim 6 didn't fit the 0/1/2 evidentiary scale cleanly — it's a feature description, not a falsifiable promise, and scoring it 0 by default slightly overstates how "unsupported" it is compared to claim 1's specific fabricated percentage. The rubric may need a fourth bucket for descriptive (non-quantified) claims rather than folding them into the same 0 as a bare invented number.