Separate customer relationship work from fulfilment work by defining who owns the customer’s commitment and who owns the movement needed to fulfil it. Connect those responsibilities through identifiable records and exception handovers. Use the worksheet below to compare CRM and supply-chain requirements without assuming that a won opportunity means goods have been delivered.
Which decision belongs to the customer relationship?
Start with an enquiry and follow the information needed to understand the request, prepare an offer and record the customer’s response. In this working comparison, give the relationship owner responsibility for the agreed customer requirement and communication history. Make that proposed responsibility explicit in the operating brief.
Odoo can create and deliver a quotation from a qualified CRM opportunity. Documentation. Odoo requires its Sales application for the opportunity New Quotation button. Documentation. This provides a concrete example of connected applications with distinct steps. Review how an enquiry becomes an opportunity and how the proposed order record preserves the agreement. Avoid asking a single pipeline label to stand in for every subsequent operational event.
Odoo requires customer information to be added or linked before a quotation is sent. Documentation. Identify the customer reference used at the handover, including the account and intended delivery information. Ask who resolves an ambiguous or incomplete customer record before work moves to the operational team. A shared customer name is less useful than an agreed reference and a clear process for corrections.
Where does fulfilment responsibility begin?
Write the point at which an accepted requirement becomes an operational instruction. Specify the order reference, agreed items, quantities, destination and any conditions the next team needs. Ask who can change each part and how the other owner is informed when the customer’s request changes.
In the documented one-step workflow, confirming a sales order exposes a Delivery smart button. Documentation. The documented one-step delivery reaches Done when the delivery is validated. Documentation. Review the actual records between those states when assessing a system. In the proposed handover, distinguish order confirmation, delivery preparation and evidence of completion. The receiving team needs to know which event it is being asked to act on.
Odoo permits different numbers of steps for incoming and outgoing shipments. Documentation. Match the fulfilment brief to the organisation’s real operating route. A simple receipt or delivery example can illustrate a record boundary, while a process involving picking, packing or other steps needs its own documented configuration and acceptance exercise.
An original customer-to-fulfilment handover matrix
Use this practical checklist to assign responsibilities for a representative order. It is an original requirements aid, with questions to resolve before comparing products or integrations. Populate it with the actual record names and owners used by the business.
| Handover | Relationship owner’s information | Fulfilment owner’s information | Question to settle |
|---|---|---|---|
| Request | Customer need and communication reference | Feasibility question requiring review | Who answers an operational constraint? |
| Offer | Proposed items and agreed scope | Availability or delivery assumptions | Which assumptions are confirmed? |
| Acceptance | Accepted offer version and customer reference | Instruction to prepare the order | What makes the instruction actionable? |
| Change | Customer’s revised request | Work already committed or performed | Who approves the revised commitment? |
| Dispatch | Customer-facing update to send | Actual dispatch record and destination | Which evidence supports the update? |
| Completion | Follow-up or unresolved customer issue | Delivered record and outstanding quantity | Is the commitment complete? |
Include a shared exception reference when the normal route cannot proceed. Both owners should be able to locate the same issue without maintaining contradictory descriptions. Record who makes the next decision and what the customer has already been told.
Keep ownership separate from visibility. A relationship manager may need to see a fulfilment status without being responsible for changing it. Equally, an operational colleague may need delivery instructions without unrestricted access to every customer conversation. Include those access questions in the system brief.
How should connected records preserve the agreement?
Odoo exposes attached quotations through an opportunity smart button. Documentation. Odoo can preview a quotation in the customer portal. Documentation. Use the proposed evaluation to trace a quotation from its opportunity to the customer-facing version. Ask which reference identifies the approved offer and how a later revision is communicated. Keep the displayed offer and the operational instruction aligned through an explicit rule.
Odoo moves confirmed quotations into the opportunity Orders smart-button view. Documentation. Review the record link during a demonstration instead of treating the opportunity’s overall status as the only evidence. Ask the team to show which order carries the commitment, which delivery record carries the movement and which communication reference records the customer’s latest response.
After the documented complete delivery, the sales order displays the delivered quantity. Documentation. Include a quantity comparison in the proposed acceptance worksheet. Check the intended interpretation of ordered, delivered and outstanding values against the actual workflow and the product’s documentation. A completed example should be distinguished from any partial or exceptional route still requiring evaluation.
Hypothetical example: the customer changes the destination
Imagine a customer accepts an offer, then asks for a different delivery address after preparation begins. The relationship owner receives the message while the operational team is working from the original instruction. This hypothetical case tests whether the system makes the changed commitment visible to the right people.
Put the original accepted version, the change request and the current fulfilment state on the worksheet. Ask who can approve the change and which record they update. Rehearse how the operational owner acknowledges the revised instruction before the relationship owner confirms it to the customer.
Then suppose the change arrives after dispatch. The next action now depends on what has actually happened, not merely on whether an address field can be edited. Ask the team to locate the dispatch evidence and define who contacts the relevant party. Retain the original reference so the investigation remains understandable.
How should you compare CRM and supply-chain software?
Give each candidate the same handover matrix and difficult change scenario. Ask where it records the agreement, the operational instruction and the exception. Identify which functions are native, which need another application and which require a manual control. Request evidence for the proposed arrangement rather than comparing feature labels alone.
Keep the wider CRM selection process with choosing a CRM. For stock-and-transaction integration questions, use POS inventory reconciliation. Those guides cover broader decisions; this worksheet concentrates on customer and fulfilment responsibility.
A useful implementation brief identifies the customer task, record references, handover owners and the exception that currently causes confusion. See web development and get started with that evidence if you want to discuss the proposed workflow with Spout.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.