A good reject protects the motion
Define hard boundaries with product and commercial owners: unsupported integrations, unsuitable annual value, incompatible use cases, no relevant operating problem or delivery requirements you cannot fulfill. Research should apply these before contact acquisition and outreach.
Some conditions are temporary or uncertain. Record whether a rejection is permanent, needs later review or depends on new evidence. Do not turn a broad rule into a blind exclusion that hides viable accounts. Review a sample of rejections with a seller and product expert to keep the boundaries accurate.
| Decision | Evidence to use | What changes next |
|---|---|---|
| Confirmed mismatch | Evidence of a hard product or economic boundary | Reject with a specific reason |
| Missing key evidence | Plausible fit but unresolved adoption or role coverage | Assign a bounded research action |
| Temporary constraint | Buyer confirms fit but no feasible timing or capacity | Set a justified review condition, not endless follow-up |
Work through the decision
Illustrative account: the buyer requires a deployment model your product does not offer. That is a product boundary, not an objection to overcome with a discount. Another account's documentation is unclear about its integration model; this is a research gap, not yet a rejection.
Keep both records, but give them different actions. The first is excluded until the product capability changes. The second receives one targeted validation step. This preserves learning and prevents a team from confusing 'not enough information' with 'not worth selling to.'
Every objection is treated as something to overcome
Some objections reveal genuine mismatch. A responsible seller can stop. Track those cases so targeting and the offer improve rather than rewarding persistence that wastes buyer and team time.
A concrete next step
Write five disqualifiers from recent losses and have product and commercial owners validate them. Apply the rules to the next account cohort before outreach.
Sources and research notes
- Schematic product documentationCompany product description
- GitLab commercial opportunity stagesCompany operating handbook
Primary sources reviewed October 6, 2026. The operating recommendations and worked scenarios are Daavid’s analysis. Illustrative numbers are assumptions, not measured client results. Company marks identify sources and prior experience; they do not imply a customer relationship or endorsement.
Schematic