“The leads are bad” feels decisive, but it is not an actionable data point. It can mean wrong market, duplicate record, no current need, unreachable contact, weak sales follow-up, misleading advertising or simply a deal that did not progress. When all of these outcomes share one label, marketing cannot improve acquisition and sales cannot show where the process failed.
A sales feedback taxonomy converts rejection into a small set of evidence-based reasons. Its purpose is not to force certainty into every record. It is to make the most common failure modes visible enough to act on.
Separate validity, fit, intent and process
Start with four different questions:
- Validity: Is this a real, usable person or organization record?
- Fit: Can and should the company serve this buyer?
- Intent: Is there a relevant need and credible next step now?
- Process: Did the team handle the inquiry as designed?
A person can be valid and fit but not ready. A high-intent prospect can be misrouted. A duplicate can represent genuine demand but should not count as a new lead. The taxonomy must preserve these distinctions.
A practical reason-code structure
| Family | Example codes | Primary owner of improvement |
|---|---|---|
| Invalid | Spam; fake details; test; unreachable data format | Acquisition, forms, data quality |
| Duplicate or existing | Existing customer; open opportunity; repeated inquiry | CRM and identity rules |
| Out of scope | Unsupported service; geography; company type; use case | Targeting, message, offer |
| Not ready | No active project; timing later; information only | Nurture and follow-up |
| Commercial mismatch | Budget, terms or procurement constraint | Offer, qualification, sales |
| Competitive outcome | Chose another option; stayed with current provider | Positioning, sales evidence |
| Process failure | Late response; no owner; missed follow-up; wrong routing | Sales operations and RevOps |
| Unknown | Insufficient evidence after required attempts | Process and data capture |
Keep the top level small. Add a subreason only when it changes an action. A list of 70 options creates false precision and inconsistent use.
Use mutually exclusive primary reasons
Many records have several problems. Choose one primary reason that best explains why the record did not move forward at the decision point. Store secondary observations separately.
For example, a prospect may be outside the target geography and have an incomplete phone number. If geography alone makes the company unable to serve them, “out of scope: geography” is the primary reason. The phone issue can remain a secondary data-quality note.
This makes aggregate reporting interpretable without discarding useful detail.
Define evidence for each code
A code should say what an operator must observe before selecting it:
- Unreachable might require a defined set of attempts across agreed channels, not one missed call.
- No budget should mean the buyer stated a constraint, not that the representative inferred it from company size.
- Not ready should include a review date or timing signal when available.
- Spam should have recognizable validation evidence, not merely an unfamiliar company.
- Bad fit should be replaced by a specific fit rule.
HubSpot allows companies to customize lifecycle stages and lead-status options. Salesforce also supports configurable lead fields and statuses. The tool can hold the taxonomy, but the organization must define the evidence and behavior behind each option.
Design the feedback loop
A taxonomy creates value only when it changes work. Establish a recurring review with three layers:
Weekly operational review
Look for sudden changes, unclassified records and process failures that need immediate correction. Sample records behind the largest categories.
Monthly acquisition review
Compare reason distribution by source, campaign, offer and landing page. Use rates, not only totals. A large campaign will naturally create more of every outcome.
Quarterly definition review
Check whether codes remain distinct, whether operators apply them consistently and whether any code has become a catch-all. Version changes so historical comparisons remain interpretable.
Measure the taxonomy itself
- share of records with a final reason;
- share using “unknown” or “other”;
- time from inquiry to disposition;
- agreement rate when a sample is independently reviewed;
- reason changes after manager review;
- process-failure rate by owner, route and period;
- re-entry rate for “not ready” records.
If “other” becomes one of the largest categories, the taxonomy may be missing a meaningful reason. If nearly every rejection is “no budget,” the definition may be too vague or the team may be using a socially convenient label.
Implementation checklist
- Sample recent rejected and stalled records.
- Group observed reasons without using the existing catch-all labels.
- Create a small hierarchy of families and specific codes.
- Write evidence and examples for every code.
- Name a primary improvement owner for each family.
- Test the taxonomy with several sales users.
- Run it in parallel with the old system for a limited period.
- Review disagreements and simplify.
- Publish a version date and effective date.
- Connect the monthly output to acquisition and process decisions.
The aim is not to prove that marketing or sales is at fault. It is to replace an argument with a diagnostic system. Once “bad leads” becomes a traceable set of validity, fit, intent and process outcomes, the team can improve the part that actually failed.
