Record the expected behaviour, observed result and accepted requirement before classifying a request. Separate a defect against agreed scope from a new customer requirement or clarification. Preserve actual investigation and correction effort, then apply the reviewed commercial treatment rather than letting an issue label alone decide whether the customer should pay.
Understand the decision
A customer can reopen an item after acceptance because the environment changed or a previously undisclosed scenario matters. The team needs the requirement and version context to investigate fairly. Commercial review should follow that evidence while delivery staff retain a clear owner for the unresolved outcome.
Work through the requirements
- Capture expected and observed behaviour.
- Reference the accepted requirement and version.
- Review classification and commercial treatment.
| Record or decision | Why it matters |
|---|---|
| Issue evidence | Shows the reproducible gap and context. |
| Requirement reference | Connects behaviour to accepted scope. |
| Change decision | Records agreed priority and charging treatment. |
What would a passing test show?
Use these hypothetical cases in a demonstration. Mark the evidence you have reviewed, then download the checklist. Selections stay in this tab.
Watch for this failure
Relabelling a difficult issue as a change request does not establish a new commercial entitlement. Keep reproducible evidence and the accepted requirement available, and separate technical classification from the responsible customer's decision about additional scope.
Continue the evaluation
This example defines what to verify, rather than promising a particular Odoo feature. Keep a record of the demonstrated result, configuration, unresolved gaps and person who accepts it.
Read the wider implementation guideBring your workflow to the conversation.
Discuss requirements for Software consultancies in a business needs review. Start with your current systems, the handoff that fails and the result you need to prove.
Sources & scope
The linked product documentation is a starting point for validating your chosen version, edition, apps and hosting. The scenarios and acceptance criteria are editorial planning guidance, not customer case studies or a guarantee of built-in functionality. See how this library is prepared.
Odoo 19: project management ↗Odoo 19: project milestones ↗Odoo 19: timesheet configuration and recording ↗