Objection library builder

Help sellers understand a buyer's concern, respond with supported information, and agree an appropriate next step.

The same words can express different concerns. A price objection might concern budget, perceived value, an alternative, or timing. Choose a question that distinguishes the plausible explanations before recommending a response.

Diagnose. Buyer: "It's too expensive." Seller: "What are you comparing it with?" Ask about budget or value after hearing the answer.

Rebut. "I understand. Other customers felt that way and then saw 3x ROI in the first year."

For a reusable library, establish patterns from qualified evidence. Use call-insights-to-objections if a raw call set needs analysis. A single live-deal question can proceed from the buyer's wording and the available context.

Inputs

For a live response, use the buyer's words, situation, known constraints, and available proof. Ask only a question whose answer materially changes the response. For a library, also confirm:

1. Segment, persona, and stage scope
2. Qualified objection evidence, not anecdotes treated as frequency
3. Approved proof and policy limits
4. Who owns the library and what event forces a review

Reuse supplied context or relevant sections of .enablement/context.md when needed. Do not invent quotes, counts, proof, or approval status. Draft response language is a proposal, not an approved claim.

A response for an upcoming conversation

1. Consider what the buyer might mean without presenting a list of hypotheses unless it helps the seller.
2. Start with a short acknowledgement and one neutral question. Let the buyer answer before giving more argument; avoid questions that imply they have failed to see the value.
3. Offer a brief reply based on known facts, in a separate conversational turn. If you propose a capability as a reason to choose, establish whether it matters to this buyer. A buyer-reported competitor price remains a report, not a verified comparison. Keep internal proof notes outside spoken lines unless the buyer needs that caveat.
4. Give a conditional next move that follows from the answer. If a confirmed requirement cannot be met, say so. Pricing, security, legal, and delivery exceptions need the authorised owner; do not script unneeded branches.

Done when the seller has a question, a response they can say, and a clear limit on what they can promise. Do not build a taxonomy or require a full company intake for this branch.

Supporting material

Read references/objection-library-framework.md when building or reorganising a library. A single live response or narrow wording edit usually needs no reference.

Building or maintaining a library

1. Keep the evidence. Verbatim wording or a labeled paraphrase. Source, date, persona, stage. Anonymize names you do not need.
2. Label without overwriting. Short name and a root-cause guess, kept separate from what the buyer said.
3. Cluster by concern, persona, stage, and competitor.
4. Prioritize by deal impact, then prevalence. A rare blocker stays visible. Repeated mentions from one account are not market frequency.
5. Write the path. Acknowledge, diagnose, answer, prove, confirm the next step. One or two diagnostic questions per card.
6. Attach proof with owner, approved wording, and last-verified date. No source, no spoken proof.
7. Write do-not-say lines and escalation owners (legal, security, pricing, implementation).
8. Version the card. Name owner, status, and review trigger. Propose which existing version this replaces; retirement in a shared system requires explicit approval.

For positioning use value-prop-and-positioning. For compete counters use battlecard-builder. For practice use roleplay-scenario-builder.

What to return

For a live objection, put the short spoken exchange first and add only the proof limit or conditional next move the seller needs. For a library, include:

• Taxonomy with priority tiers
• Evidence register with source-linked wording
• Play cards for the objections that earn them
• Proof map with approval state
• Escalation matrix
• Lifecycle: owner, version, review trigger
• Manager notes only if someone will coach from this library
• Assumptions, if evidence was thin

Keep approval notes separate from customer-facing lines. Publishing or changing a shared library requires explicit approval.

Quality bar

• Diagnosis comes before the answer.
• Priority follows deal risk, not the loudest channel.
• Every quote and proof claim has a source.
• Escalation is specific enough to use on a live call.
• A rep can find the card and speak it without sounding read.