CRM lead management should establish whether an enquiry merits a sales opportunity, who owns the next action and what evidence closes that action. Start by separating qualification from forecasting. Then test assignment, duplicate handling and follow-up using fictional records before relying on a pipeline view to describe the team’s work.
An enquiry can be genuine without being ready for a quotation. A person might ask about a service without explaining the requirement, decision process or intended scope. Your qualification rule should tell staff what to find out next. It should also permit an honest outcome of insufficient information rather than encouraging a speculative opportunity simply to keep the dashboard busy.
This guide uses Odoo 19 documentation as a concrete software example. The proposed lead-triage worksheet is an original exercise, not a report of a Spout implementation. It focuses on qualification and ownership. Broader platform selection belongs with choosing a CRM; the enquiry route can be discussed through business systems.
When should an enquiry become an opportunity?
Odoo describes leads as a qualification step before a formal opportunity. Its lead-conversion documentation gives an example of a system that distinguishes these records. Use that distinction to ask a practical question: what new information justifies moving this enquiry into the active sales process?
Write the answer in business language before configuring a field. For a fictional equipment enquiry, the missing information might be the intended use and the person who can confirm the requirement. For a service enquiry, it might be the outcome being requested. These are suggested questions for the exercise, not universal qualification standards or instructions to collect unnecessary personal information.
Odoo’s Leads setting applies to all sales teams by default. Odoo also allows leads to be disabled for a specific sales team. These documented details matter when testing a change: a global configuration decision and a team’s actual working process need not be identical. Record which teams the proposed process covers and check a representative user from each relevant group.
Avoid interpreting a button label as proof that your qualification rule is enforced. Ask the demonstrator to convert a fictional lead with a deliberately incomplete qualification note. Record whether the application prevents the transition, warns the user or permits it. That proposed negative test establishes the difference between a written team rule and an observed software restriction.
Who owns the enquiry and its next action?
Odoo does not require a salesperson or sales team when converting a lead. That is a documented software choice, not a recommendation to leave a live enquiry unowned. If your business needs accountable ownership, write down how an unassigned record will be detected and who will decide the assignment.
Odoo can populate the sales team from the selected salesperson. Check the result in a test copy when a person belongs to the intended team. Do not assume that selecting a familiar name proves every routing rule has run correctly. Keep the expected person and team on the worksheet, then compare them with the resulting opportunity.
Activity ownership deserves its own check. Odoo activities are follow-up tasks attached to leads and opportunities. The activities documentation describes how those tasks relate to the sales record. Agree whether the person responsible for the opportunity should also own each task, or whether preparation and specialist review need different owners.
Odoo assigns an activity to its creator when its Default User is blank. This can be easy to overlook during a demonstration led by an administrator. Have a representative salesperson create the fictional task and inspect its assignee. The expected result should come from your proposed process, not from whichever account happens to be running the demonstration.
| Fictional enquiry condition | Proposed decision | Evidence to retain |
|---|---|---|
| Requirement is incomplete | Continue qualification | Missing question, named owner and next contact action |
| Scope is understood | Consider conversion | Qualification note and expected salesperson |
| Similar enquiry already exists | Investigate duplication | Both record identifiers and the merge decision |
| No responsible person is selected | Treat ownership as unresolved | Actual assignee fields and escalation owner |
| Follow-up has been completed | Record the outcome | Completion note and the next justified action |
The table is a proposed operating worksheet. It does not claim that Odoo enforces these decisions automatically or that every CRM uses the same data model.
How should duplicate enquiries be handled?
A repeat message might be another contact attempt, an additional requirement or a different person at the same organisation. Establish which case you are looking at before merging anything. Keep the original record identifiers so the reviewer can explain why the records should represent one opportunity rather than two.
Odoo prioritises the oldest lead or opportunity when merging similar records. That behaviour makes a merge demonstration more useful than simply showing that a duplicate warning exists. Prepare fictional records with different creation order, ownership and notes. Ask which information remains on the resulting record and compare the answer with the intended business record.
Do not rehearse merges on customer records. Use an isolated test database and keep a copy of the exercise inputs. If the proposed application cannot show the resulting history clearly, leave that issue open. A tidy pipeline is not sufficient evidence that the underlying enquiry history remains understandable.
What counts as follow-up evidence?
A reminder says that somebody should act. A completion note should explain what happened. For the fictional enquiry, record whether the contact answered, what requirement was clarified and why another action is needed. Keep the note proportionate; it need not become a transcript or a collection of unrelated personal details.
Odoo can calculate the next deadline from the preceding activity’s completion date. Odoo can also trigger the next activity when the previous activity is marked Done. These are distinct configuration choices. Ask whether the desired sequence follows a calendar commitment or waits for real completion, then demonstrate the chosen behaviour with a deliberately late fictional action.
A triggered task is not proof that its business prerequisite was satisfied. If the first action is marked complete without the required evidence, the next task may look reassuring while the qualification gap remains. Include that scenario in your review and decide who should correct an unsupported completion note.
Original lead-triage and handover worksheet
Create a fictional enquiry called Sample Request A. Write its question, known requirement, missing information and intended owner on paper before entering it. Add a second fictional record that appears similar but contains a different contact detail. State explicitly that neither record represents a real customer and that no outbound message is to be sent during the exercise.
First, ask a normal sales user to record the enquiry and schedule the next action. Capture the lead identifier, opportunity status, task assignee and due-date basis. Compare those fields with the worksheet. Next, have a different authorised test user review the record without changing it and explain who should act next. Disagreement identifies an ownership problem worth resolving before rollout.
Then demonstrate the duplicate review and conversion separately. Retain the before-and-after identifiers and the qualification note. Finally, complete a fictional follow-up late and inspect what happens to the next task. Mark each requirement demonstrated, unresolved or outside scope. These are proposed acceptance categories, not a certification of the product.
Use the resulting record to define the outstanding configuration and training questions. For a related sector example, see automotive CRM ownership. To discuss a bounded lead-handling workflow, get started with the worksheet and the unresolved decisions.
By Spout Team. AI-assisted drafting by Codex from the linked primary documentation. No customer outcomes, installed configuration or professional review is claimed.