What is quiz lead routing QA?
Quiz lead routing quality assurance is a reproducible check that a declared route policy becomes the same operational outcome across the quiz, saved completion, CRM or native contact record, owner assignment, notification or sequence, and analytics. It tests implementation and recovery after completion; it does not decide whether the qualification policy is fair or predictive.
Freeze the policy under a rule version before testing. Keep supplied answers, calculated score, route decision, decision reason, owner, action status, and later human status separate so a reviewer can reconstruct where a mismatch began.
Related: Define the routing policy before testing it · Define the CRM handoff field contract
Create a routing evidence record before the test
Record the rule version, synthetic completion ID, supplied inputs, calculated score, expected band, expected route, expected owner or queue, expected event, expected participant-facing state, expected action key, and cleanup procedure. Mark test records unmistakably and block them from reaching real sellers or customers.
The expected record is the oracle for the test. Do not infer success from a green front end, a single CRM row, or an analytics event alone; compare each observed layer with the same declared case.
Use this eight-path routing test matrix
Run at least one clean synthetic completion for every reachable outcome and blocking state. Add organization-specific cases where ownership, permission, or integration rules create more paths.
| Case | Expected route | Verify | Blocking failure |
|---|---|---|---|
| Sales-ready | Assigned seller | One task with the required context | Missing or duplicate task |
| Manual review | Review queue | Reason, queue item, and service owner | Silent backlog |
| Nurture eligible | Approved sequence | Correct segment and permission state | Wrong or unauthorized sequence |
| Suppressed | No outreach | Stored suppression reason | Any prohibited send or sales task |
| Missing owner | Fallback queue | Alert and recoverable record | Random or dropped assignment |
| Timeout | Pending, bounded retry, then recovery | Attempt count and final state | Endless or duplicate retry |
| Edited answer | Recomputed route | Obsolete action cancelled or superseded | Stale route survives |
| Duplicate completion | Existing action reused | Stable action key and no second task | Duplicated action |
Related: Apply the consent and suppression precedence matrix · Use deterministic keys to prevent duplicate actions
Run the end-to-end method in eight steps
Use a clean session for the ordinary path, then repeat with the controlled failure injected at the layer named by the case. Retain the evidence needed to compare the expected and observed states.
- Freeze the route, ownership, permission, and suppression rules under version identifiers
- Write expected outputs for every reachable route and blocking state
- Run each synthetic completion from a clean session
- Inspect the participant-facing result and saved completion or contact record
- Inspect the owner, task, notification, sequence, and analytics event
- Inject timeout, retry, resumed-session, edited-answer, and duplicate paths
- Clean up test data and retain the evidence record
- Block release for any mismatch, silent drop, duplicate action, or unauthorized action
Worked example: a missing review-queue action
A synthetic completion is expected to enter manual review because the score passes but the region is missing. The quiz shows the correct result and the stored decision says manual_review, but no queue item appears. The test fails even though the front end looks correct.
The repair must create the review item exactly once, retain the missing-region reason and rule version, expose the item to a monitored recovery queue, and pass the same case again. This example is illustrative; it is not an observed product test or performance benchmark.
Validate events without making analytics the source of truth
Use stable completion, route-decision, and action identifiers. Record the decision, action attempt, successful action, and later sales outcome as separate events. A retry may create another attempt; it must not create another lead, route decision, or completed handoff.
Google Analytics recommends distinct lead-generation events including generate_lead, qualify_lead, disqualify_lead, working_lead, close_convert_lead, and close_unconvert_lead. These events support funnel measurement, but the saved operational record should remain authoritative for ownership, permission, suppression, and recovery state.
Related: Define denominator-safe quiz funnel metrics
Sources: Google Analytics, Recommended events
Test validation and status messages accessibly
W3C input-validation guidance supports identifying errors in text, associating them with the affected control, and helping people correct mistakes. Validate on the server as well as the client, preserve answers where practical, and test required fields, formats, keyboard use, visible focus, zoom, and back or resume behavior.
When delayed or failed submission adds a status message without moving focus, WCAG status-message guidance calls for a programmatically determinable role or property so assistive technology can announce the update. Keep the message useful to the participant without exposing confusing internal routing detail.
Related: Run the complete quiz accessibility checklist
Sources: W3C, Validating input · W3C, Understanding status messages
Block release until every route is observable
A passing happy path is insufficient. Release only when ordinary outcomes, blocking states, retries, and recovery all produce the declared record and exactly one permitted action.
- Every policy outcome has at least one synthetic case
- Every owner rule has an active target and named fallback
- Timeouts and retries are bounded, observable, and idempotent
- Suppressed and test records cannot trigger outreach
- Edited answers cancel or supersede stale actions safely
- Duplicate completions cannot create duplicate tasks
- Recovery queues have a named owner and response expectation
- Test records are removed or retained under a documented policy
Evidence
How to reproduce the method
Reproduce the checklist with a versioned route policy, the eight-case matrix, marked synthetic records, expected-versus-observed evidence across the visible result, saved state, owner, downstream action, event stream, retry log, and recovery queue, plus proof that cleanup completed. The worked example is synthetic and no product was tested.
Limitation
Where this conclusion stops
Routing QA cannot validate the predictive quality or fairness of the qualification model, guarantee downstream sales response, prove legal compliance, or cover an undocumented third-party change. A passing synthetic suite must be paired with production monitoring, named recovery ownership, and periodic reruns after rule or integration changes.
Sources and verification
What this guide relies on
- Google Analytics, Recommended events
- W3C, Validating input
- W3C, Understanding status messages
- The Lead Quiz Review editorial methodology
Sources and method checked October 4, 2026. External standards are linked to their primary publishers. Request a factual correction.