Qualification
Recording why sales accepted or rejected an enquiry
Capture sales acceptance, clarification and rejection with specific reasons, an accountable next action and a record of the rule used.
Record sales acceptance as a decision with a next action, not merely a stage change. For non-acceptance, record a reason explaining what happened to the request. Keep ‘awaiting review’, ‘needs clarification’ and ‘rejected under the agreed rule’ separate, so unfinished work is not reported as poor-quality leads.
Define acceptance at the decision point
A workable rule might be: sales has reviewed a genuine request, considers it within work the business can handle, and agrees to a named follow-up action. Adapt the rule to the service. Assignment to a salesperson is not acceptance if nobody has assessed the request. A scoping discussion may be accepted even when final project fit remains to be confirmed.
Capture the enquiry identifier, received and decision dates, decision maker, status, primary reason, and next action or owner. Authorised reviewers should keep the original request available to check the reason against it. Leave missing source or project details as unknown.
Choose reasons that explain different actions
| Status | Example reason | What the next reviewer learns |
|---|---|---|
| Accepted | Relevant service request; first discussion agreed | Sales has an actionable next step |
| Needs clarification | Site location missing | One fact is needed before deciding |
| Not accepted | Requested service is not offered | The business cannot take this work under the current rule |
| Sent elsewhere | Existing-customer support request | The enquiry is genuine but belongs to another team |
| Excluded from enquiry review | Confirmed test or automated spam | No customer request was assessed |
This is a proposed reason set, not a CRM default. Use reasons specific enough to guide action and few enough to apply consistently. A short note can explain an unusual case, but ‘bad lead’ or a guess about someone’s seriousness does not explain a decision. Avoid sending personally identifiable information to Google Analytics.
Keep an intake rejection separate from a later lost opportunity. The first concerns an enquiry that did not meet the intake rule; the second concerns work pursued and then not won.
Preserve the decision history
When criteria change, record the rule’s effective date or version. If a request is reconsidered after clarification, preserve the earlier decision and add the later one. A reviewer should be able to see what was known, who decided, which rule applied and what response followed.
For a hypothetical engineering consultancy, missing site location is a reason to seek clarification if location determines availability. If a later reply places the work outside the firm’s area, ‘outside service area’ is a new finding. The two reasons should not be made to look like the same original decision.
Review reasons before using the counts
Sample records under each common reason. Does ‘outside scope’ match the request? Is ‘no budget’ being used when nobody asked about budget? Are pending cases left without an owner?
Correct classification errors and clarify the rule before using counts to change a campaign. Compare reasons by page or offer only when the source is known and the decision rule is consistent. Repeated service mismatches may call for clearer copy; repeated missing facts may call for a better clarification question. Record the change and review later enquiries under the new rule.
