A CRM pipeline should show the evidence needed to advance an opportunity, explain why it was lost and make reporting assumptions visible. Define stage exit rules before trusting a forecast. Test the same fictional records through operational and analytical views so that filters, archived records and ambiguous outcomes cannot quietly change the story.
A column called Proposal can mean several things: a quotation was drafted, sent, discussed or accepted in principle. Choose the meaning your team needs and record the evidence that supports it. The number of cards in that column becomes useful only when people interpret the stage consistently. This guide concentrates on that evidence and on checking the reports built from it.
The documented examples come from Odoo 19. They describe that product rather than a universal CRM standard. The original stage-and-report reconciliation below is a proposed exercise with fictional opportunities; it is not an audited sales result. For broader context, use CRM selection and business systems.
What should permit an opportunity to leave a stage?
Start with the decision being made. A suggested Qualification exit rule might require a recorded business requirement and an agreed next conversation. A suggested Proposal exit rule might require the particular offer under discussion to be identifiable. These are example operating rules for a fictional business, not controls established by the documentation or assertions that Odoo enforces them.
Ask the sales owner to define what insufficient evidence looks like. A meeting booked without an identified requirement might remain in qualification. A prepared quotation that nobody has sent should not be described as a customer response. Avoid using activity completion as a substitute for evidence of the decision that the stage represents.
Test the agreed rule in a separate database. Give the demonstrator an opportunity with the stage field populated but the supporting note absent. Ask whether the proposed configuration blocks movement or merely relies on staff discipline. Record the observed behaviour and the owner of any remaining process control. Do not call an instruction an enforced restriction.
How should lost work remain explainable?
Odoo provides a Lost Reason field when marking an opportunity lost. Odoo also provides a Closing Note for additional comments. The lost-opportunity documentation describes these separate places for structured classification and context. Decide what your business needs from each rather than filling both with the same vague word.
Odoo does not require either the lost reason or the closing note. This distinction between a software default and a reporting requirement is consequential. If management wants to compare reasons, ask how missing classifications will be shown. Do not quietly omit unclassified losses from a review and then describe the remaining subset as the whole pipeline.
Odoo allows a new lost reason to be created from the loss dialogue. That flexibility can help an operator record a genuine exception, but your proposed review should check whether similar descriptions need consolidation. An exception owner can assess the wording without inventing a customer’s motive. Preserve unknown where the reason has not actually been established.
Odoo can restore a lost opportunity from its detail form. Include reopening in the test scenario. Write the new evidence that would justify reconsidering the opportunity, and ask the demonstrator to explain what the restored record means to the current pipeline report. Restoration should be an accountable decision, not a way to improve the appearance of a result.
| Stage or outcome | Proposed exit evidence | Question for the reviewer |
|---|---|---|
| Qualification | Requirement and next conversation recorded | Does the note establish the intended buying problem? |
| Proposal | Identifiable offer and its actual communication status | Is this a draft or something the customer has received? |
| Decision pending | Customer’s outstanding decision or question | Is the expected closing date supported or merely convenient? |
| Lost | Known reason, or an explicit unknown, plus useful context | Is this record represented in the reporting population? |
| Reopened | New information and a named owner | Does the current report explain the changed status? |
This table is a proposed evidence contract. It is not a product feature list, a guarantee of forecasting accuracy or a statement of any customer’s actual sales process.
Why can two pipeline reports disagree?
Odoo’s default Pipeline Analysis graph covers opportunities created in the current year. That default is documented in Pipeline Analysis. A manager asking about expected closures this month is asking a different question. Record the selected date field and period before interpreting the graph.
Odoo’s My Pipeline filter restricts results to the current user’s opportunities. A demonstration performed under one salesperson’s account may therefore answer a narrower question than a team review. Keep the account and active filters with the screenshot. Ask whether the same underlying records appear when the intended team scope is applied.
Odoo automatically archives lost opportunities, but not every archived opportunity is lost. Odoo warns that win/loss reports may omit archived losses without the relevant archived-record inclusion. These documented qualifications make the report population part of the acceptance test. A loss filter alone is not sufficient evidence that the displayed count includes every intended loss.
Odoo applies selected report groupings in sequence. Record their order alongside the filters. A chart grouped first by stage can present a different visual emphasis from one grouped first by salesperson even when both contain the same records. Ask the reviewer to explain the grouping before attributing a difference to staff performance.
Original stage-and-report reconciliation exercise
Prepare a fictional set consisting of an active qualified opportunity, an active proposal, a won opportunity, a lost opportunity and an archived record that is not lost. Give each a simple identifier and an explicit creation date within the test period. Do not attach real customer names or send any email. Write the expected membership of each proposed report before running it.
Begin with the operational pipeline and identify the records that should be visible there. Then inspect the analysis under a normal salesperson’s account. Note the date basis, active filters and grouping order. Reconcile the displayed records with the paper list. Where a record is absent, investigate its scope and status rather than changing its data to make the graph look right.
Next, prepare the win/loss view and examine the archived-loss case. Check membership in the underlying list as well as the total. Two totals can agree by coincidence while containing different records. Preserve the record identifiers, report settings and explanation of each exclusion so another reviewer can repeat the comparison.
Finally, restore the fictional lost opportunity with a new note explaining the hypothetical reason. Re-run the relevant views and document the changed membership. This is a proposed test of interpretation; it does not claim that the same change has occurred in a live business. Leave unanswered behaviour as unresolved and assign someone to investigate it.
Use the exercise to agree a stage dictionary, loss-classification owner and report definition. Keep forecast assumptions separate from actual outcomes, and retain unknown rather than manufacturing certainty. When a sale progresses into billing, the distinct handoff is covered in CRM invoicing. To discuss the specific configuration questions, get started with the reconciled fictional record list.
By Spout Team. AI-assisted drafting by Codex from the linked Odoo documentation. No sales performance, implementation outcome or human professional review is claimed.