Build the Lead Qualification Test Pack
Create expected outcomes for positive, negative, incomplete, duplicate, stale, ambiguous and failure cases.
What you will complete
Complete a lead test pack with inputs, expected score components, route, human decision, evidence and pass criteria.
Use cases that expose assumptions
Start with a clear positive case and a clear non-fit. Then test the cases where simple models fail: incomplete data, conflicting evidence, duplicates, existing customers, referrals, stale activity, changed circumstances, unavailable owners and downstream errors.
Sanitize real examples when possible. Synthetic cases can test mechanics, but they cannot prove that the rules fit the business. Keep a held-back recent lead for final review so you do not tune every rule to the same examples used during design.
For each case, record the expected score components and confidence, not only the final band. State the expected route, person responsible, allowed action and evidence to inspect.
Test matrix
| Case | Condition | Expected decision |
|---|---|---|
| Positive | Strong fit, meaningful request, enough evidence | Priority review; human SQL decision |
| Negative | Confirmed unsupported market or request | Decline, refer or resource with reason |
| Incomplete | Required field unknown | Enrich or review; no invented value |
| Duplicate | Same event enters twice | One active action and preserved history |
| Stale | Old engagement with no current request | Decay or later review, not priority by history alone |
| Ambiguous | Evidence conflicts or score sits near threshold | Named human review with sources shown |
| Failure | Assignment or destination write fails | Visible error, safe retry rule and accountable fallback |
Worked example: Harborline test cases
Fictional example: Harborline writes twelve cases. One Ontario manufacturer with a current manager-training request should reach priority review. An individual seeking a public certification course should receive the public-course path. A referral missing company size should reach review with the field marked unknown.
An existing customer using a personal address should match the account and preserve its owner. Two identical form events should create one review action. A lead whose only engagement happened nine months ago should not keep current priority. A company with a supported industry but an unsupported request should show the conflict rather than hiding it inside a total.
Harborline also marks every reviewer away and simulates a failed task write. It checks the CRM record, queue, owner, alert and history after each run.
Complete section 6 of the workbook
- Create at least one case in each category: positive, negative, incomplete, duplicate, stale, ambiguous and failure.
- Add existing-owner, all-away, changed-circumstance and sensitive-request cases where relevant.
- Write the expected component scores, confidence, route, owner and allowed action before execution.
- Identify the destination records, alerts and history that prove the result.
- Set pass, fail and not-tested statuses. Never convert not tested into pass.
Grade disagreements as evidence
When a reviewer disagrees with the expected result, capture the rule, source or ownership question behind the disagreement. Decide whether the case reveals a model defect, an unclear business policy, missing data or legitimate human discretion.
Fix the smallest responsible layer and rerun affected tests. Keep the original result and model version. Stop after repeated failed repair cycles and narrow the scope or name the blocker rather than declaring an unreliable system ready.
Check your decision
1. When should expected routing be written?
2. What does a successful workflow run prove by itself?
3. A reviewer disagrees with one result. What should the team record?
Return to Build a Lead Qualification and Sales Handoff System