CRM means customer relationship management: the business practice of organising customer relationships and the software used to keep that work connected. Follow 3 parts of a customer journey: identify the customer, record the conversation and own the next action. A contact list stores names; a useful CRM connects those names with enquiries, commitments and outcomes.
In a fictional enquiry, a customer asks about a service, a colleague records the need, another follows up and the team records whether the opportunity progressed or ended. CRM is the continuing process; the application is its shared record. Staff still decide what the customer needs and which commitment they can make. Odoo’s CRM overview provides a concrete software example: tracking leads and opportunities, organising a pipeline and managing meetings and next activities. The workflow below explains those concepts before evaluating a proposed configuration.
Which customer records and pipeline decisions should the CRM support?
Start with the information a colleague needs to continue a conversation. The customer identity, relevant contact, subject of the enquiry and agreed next action should be understandable together. Do not begin by collecting every possible field. An unused field can increase data-handling work without making the next decision clearer.
Define how contacts and organisations relate. A person may contact you for an organisation, change roles or appear in more than one conversation. Your proposed design should explain how staff avoid creating a new customer every time an enquiry arrives. This is an evaluation requirement, not a claim that every CRM automatically resolves duplicate identities.
Make pipeline stages mean something observable. A stage should reflect a business decision or condition, not simply how optimistic a salesperson feels. Write the entry and exit meaning in plain language. Where your team uses “qualified”, identify the information that makes the request suitable for the next step rather than inventing a universal score.
Odoo’s activity documentation describes activities as follow-up tasks tied to leads and opportunities and visible in the chatter. That offers a concrete next-action model to examine. Ask who is responsible for the activity, what it means and how a colleague can see whether it still needs attention. The presence of a task list does not establish that somebody owns every enquiry.
The documentation describes preconfigured activity types and the ability to create custom types. Use a small, meaningful vocabulary that matches your workflow. A different activity type for every minor variation can make reports harder to interpret. Do not confuse the ability to customise with evidence that more custom fields will improve adoption.
Lost opportunities need an explicit meaning too. Odoo’s lost-opportunity guide describes recording a lost reason and closing note. It says these fields are not mandatory in the documented form, while recommending their use. If your business requires an explanation, treat enforcement as a configuration or operating requirement to demonstrate rather than assuming the default screen guarantees it.
Use this original CRM brief to compare the proposal with the work people actually need to do.
| Business task | Evidence during the trial | Question to resolve |
|---|---|---|
| Find an existing customer | Correct record located without creating a duplicate | What identifies the same organisation or person? |
| Continue an enquiry | Relevant history and next action visible | Can another colleague understand the commitment? |
| Move a stage | Reason matches the agreed stage definition | Does the stage represent evidence or optimism? |
| Close an unsuitable request | Meaningful outcome and reason retained | Is unresolved work being hidden as lost? |
| Return to a prior opportunity | History remains understandable | Does reopening preserve context? |
| Correct a record | Authorised change and clear responsibility | Which system is authoritative? |
How do you test usability and adoption without inventing a success rate?
Run a short task trial with fictional or properly redacted enquiries. Ask intended users to find a customer, record a conversation, schedule a next action and explain what another colleague should do. Observe where they need assistance. Do not turn a polished vendor demonstration into a claim that your team has adopted the product.
Include a handover between users. One person records the enquiry and another continues it using only the intended system record. Identify missing context and unclear ownership. A successful handover is useful evidence about that tested scenario; it does not justify an invented percentage improvement in response time or conversion.
Demonstrate lost-opportunity handling. Odoo documents filtering lost records and restoring opportunities. Use a fictional case to show how staff locate the earlier discussion and what reopening means. The same guide warns that merging lost and active opportunities can bring records back into the pipeline, so include merges in the governance discussion rather than treating them as harmless tidying.
Agree a controlled lost-reason vocabulary. A reason should explain a useful distinction the business can act on, not become a place for blaming a customer or recording unnecessary personal information. Keep a separate route for an unresolved request that still needs work. Closing it as lost solely to clear a dashboard would obscure the operational problem.
Check permissions with ordinary user accounts. Staff should be able to perform the intended tasks without receiving broad administration access for convenience. Test an action that should be refused as well as one that should succeed. A configuration demonstrated only through an administrator does not establish the right access boundaries for the team.
Evaluate data import and export separately from screen usability. Ask how existing records will be matched and how meaningful references survive outside the system. A clean-looking import can still create duplicate customers or detach history. Use representative relationships in the rehearsal and retain the rejected or unresolved records rather than hiding them from the report.
Plan the work that remains outside the CRM. If invoicing, support or stock lives elsewhere, identify the authoritative source and the handover rule. Do not promise a connection just because the vendor lists an integration category. The proposed connector and its exception path need their own evidence.
Record the adoption plan as responsibilities, not predictions. Name who maintains stage definitions, helps users correct records and checks unowned next actions. Use feedback from the task trial to improve the configuration. No universal training duration or usage threshold is asserted here, because the right arrangement depends on the team and the tasks being tested.
Finish selection with a decision note: observed strengths, unresolved gaps and required configuration. For related application requirements, see Spout’s web development page. For the later billing handover, use the separate CRM invoicing workflow rather than expanding this article into accounting instructions. Get started with the task trial and the record problem your team needs to solve.
By Spout Team. AI-assisted drafting by Codex, grounded in the linked primary documentation.