Skip to main content

CRM Lead Qualification

Purpose​

CRM Lead Qualification adds a separate qualification pipeline for leads. It checks the evidence your team requires before conversion to an opportunity, records stage history, and supports manager review and reasoned exceptions. Qualification stages do not replace the native opportunity stages.

This guide follows the Odoo 19.0 implementation. The workflow and practice case are source-derived and have not been executed as part of this documentation review.

Before you start​

Install the package matching your Odoo major version through your normal addon installation process. The 19.0 manifest depends on CRM (crm) and declares no Enterprise-only dependency or other paid Corvus addon. Enable and use CRM leads, and have an administrator arrange the required sales access. Prepare your sales teams, lead sources, and destination opportunity stages before configuring qualification.

Access and roles​

Sales users can read qualification stages and policies and operate the qualification wizards on CRM records they can access. Sales Managers configure stages and policies, approve or return reviews, and create overrides. A person who requested a review cannot approve that same review or their own qualification override.

Company rules restrict configuration and audit records. Sales-user history and override access also follows assignment, unassigned leads, or team membership; managers have company-scoped audit access. History and override records cannot be edited as ordinary business records.

Setup and menu​

  1. Under CRM → Configuration → Lead Qualification Stages, create stages for the lead-only process. Choose their company, optional sales team, sequence, and aging warning in hours. Zero disables the aging warning. A stage can also propose a default opportunity stage.
  2. Open Qualification Policies in CRM Configuration. Set the company and any applicable team, source, campaign, medium, priority, or business category. The most specific matching policy wins; lower sequence then record order breaks ties.
  3. Select default, review, and disqualified qualification stages where needed, and the target opportunity stage. Team-specific stages must match the policy team.
  4. Add requirements and choose whether each is Blocking or Warning. Available checks include contact, company/customer, email or phone, source, salesperson, team, notes, expected need/value, tags, attachment, planned next activity, and an approved custom field.
  5. Enable manager review if conversion must receive approval, and choose override validity in days. Test Policy opens candidate leads to inspect the scope; it does not certify the policy or execute a conversion.

Workflow​

  1. Open CRM → Sales → Qualification Pipeline and create or open a lead. Set its company, team, salesperson, qualification stage, and qualification details. The pipeline includes leads with an open qualification outcome.
  2. Select Check Readiness. Review the percentage and missing-requirement summary. The percentage is the share of satisfied requirements, not a predictive win score. Blocking failures prevent conversion; warnings remain visible without blocking it.
  3. Complete the missing evidence and check again. If the policy requires review, choose Assign for Review. Blocking requirements must be resolved first. The lead enters Submitted status and may move to the policy's review stage.
  4. A different Sales Manager opens Qualification Review Queue, then Qualify & Convert, chooses Approve Review, and applies the decision. Return for Correction requires a reason. Review the queue filters: it also includes returned, overdue, and blocked leads.
  5. Choose Qualify & Convert and the conversion operation. Confirm whether to create a customer, link an existing one, or leave it unlinked; review salesperson, sales team, and target opportunity stage. The 19.0 implementation delegates conversion to Odoo's native conversion wizard and checks the qualification gate before proceeding.
  6. Use Qualification History, Lead Qualification Analysis, or Qualification Cycle CSV to inspect outcomes and cycle duration. Use Keep as Lead or Disqualify with a reason when conversion is inappropriate. These outcomes remove the record from the open qualification pipeline; keeping a lead is not the same as converting it.

Practice scenario​

In an authorized test database, create fictional lead “Northbridge Workshop — service enquiry.” Configure two blocking requirements: email or phone, and expected need. Leave both empty and run Check Readiness; the intended result is Blocked with both missing. Enter a fictional contact channel and “annual machine servicing,” then submit for review. Have a different manager approve and convert into your selected opportunity stage. Inspect the resulting opportunity and qualification history. Use test-only contact details and your organization's safe test procedures.

Troubleshooting and limitations​

No Policy means no qualification gate matched; the source permits conversion without a policy. Investigate scope if you expected a block. A ready percentage does not replace required manager approval. Material lead changes can return an approved review for correction and invalidate overrides; policy changes also invalidate exceptions. An expired or used override does not remain a permanent bypass.

If combining this addon with CRM Lead Nurture on 19.0, obtain a combination-specific compatibility check before rollout: their policy resolution overlaps in the reviewed source.

The 20.0 implementation uses different native conversion hooks and shares readiness method/field names with the 20.0 CRM Stage Validation addon. If installing both together on 20.0, obtain a combination-specific compatibility check before rollout. This guide does not establish that combined workflow.

The catalogue lists 15.0–20.0 packages. Earlier versions use their native view and conversion conventions; 15.0–18.0 opportunity stages have different team scoping from 19.0. The steps above are reviewed for 19.0, with targeted comparison of the other branches, not all-version runtime verification.