Connect CRM and inventory by separating a customer’s interest, an order’s confirmation and stock reserved for that order. Define which inventory record answers availability, when reservations occur and who handles shortages. Test competing orders and changed quantities before letting a sales screen imply that stock has been committed.
A product visible in a CRM does not tell a salesperson whether it can be promised. The important questions concern the selected item, location, quantity and reservation state. A useful integration makes those distinctions understandable and preserves the underlying order reference when work passes from sales to delivery.
This guide uses Odoo’s documented quotation and reservation workflows as a concrete example. The original two-order exercise is a proposed acceptance test for an isolated copy, designed to reveal misunderstandings between sales language and inventory behaviour.
Where should the customer enquiry become an order?
Odoo requires its Sales application for the New Quotation button to appear in CRM. The quotation guide makes this dependency explicit. Odoo requires customer information to be added or linked before a quotation can be sent. Check customer identity before the handoff. An opportunity with a company name in a note is not the same as a quotation linked to the correct customer record.
Odoo quotations distinguish invoice and delivery addresses. Verify each address for its intended use and keep the delivery destination in the test card. A correct stock allocation for the wrong destination still leaves the customer journey broken. Ask the demonstrator which address the downstream delivery uses and where an authorised correction should be made.
Confirmed quotations in Odoo become sales orders. Keep that transition separate from marking an opportunity won. Write which action your process treats as the operational handoff and which record the delivery team receives. The CRM should let a salesperson trace the order, not merely display a reassuring stage label.
Specify who owns the next action when a confirmed order has insufficient stock. Sales may need to discuss an alternative with the customer; the inventory team may need to investigate the position. Give the exception an owner and a visible state so neither side assumes the other has already resolved it.
What does the reservation method actually do?
Odoo documents At Confirmation, Manually and Before scheduled date reservation methods. These methods are described in Odoo’s reservation documentation. Select the method to match the intended operation, then inspect the configured behaviour. Do not assume the same method applies to every delivery simply because it is available in the product.
Odoo’s At Confirmation method reserves only when the order is confirmed and stock is available. The stock condition is essential: confirmation is not an unconditional promise that the requested quantity has been reserved. Include a shortage in the demonstration and record the actual reserved quantity separately from the ordered quantity.
Odoo’s manual method requires a manual availability check and reservation after confirmation. Under this method, identify the person responsible for that manual step. A workflow that depends on a human check needs a queue or other agreed way to make the pending action visible. Copying a quantity into CRM does not perform the reservation.
Odoo configures reservation methods on individual operation types. Odoo’s documented reservation methods require the Sales and Inventory applications. Record the relevant operation type and installed applications in the evidence. Odoo reservation methods are not available when the operation type is Receipt. Use the correct operation when testing, rather than treating a missing reservation setting on a receipt as proof that the feature is broken.
| Sales question | Inventory evidence to request | Wording to avoid until established |
|---|---|---|
| Does the item exist in the system? | Correct product identifier and unit | Available for this order |
| Is stock shown at the intended location? | Location-specific stock view and its meaning | Already allocated to the customer |
| Has the order been confirmed? | Confirmed order reference | Fully reserved |
| What is reserved? | Reservation state and quantity | Ready to dispatch |
| What remains unresolved? | Shortage or pending manual-action record | Delivery guaranteed |
How should sales see shortages and changes?
Decide what the CRM should show when ordered and reserved quantities differ. Use plain operational language that reflects the configured system. Give the salesperson a route to the relevant record and an owner for questions rather than exposing an unexplained technical flag.
Also decide how old availability information is identified. Record when the value was obtained and what event refreshes it in the proposed integration. A screenshot of a quantity without its source and timing is weak evidence for a customer commitment. If an update fails, define what the salesperson sees and how the issue is escalated.
Changes deserve their own test. Ask what happens when an order’s quantity, item or planned delivery changes. Identify which system accepts the change and how the other view is updated. Do not let staff repair disagreements by editing both sides independently without a rule for which record wins.
Original two-order reservation test
Use a hypothetical stock item with five units in a test location. Prepare two fictional customer orders requesting three units each. The arithmetic creates a deliberate shortage: combined demand is six units against five. These are exercise values, not a claim about a live stock position or a particular configured result.
Record the baseline: Note the item identifier, unit, location, shown quantity and operation type. Record the configured reservation method. Ask the inventory owner to explain the meaning of each quantity before any order is confirmed.
Process the first order: Follow the selected documented workflow in the test copy. Retain its order reference, ordered quantity and observed reservation. For a manual method, record the position before and after the authorised manual action so its responsibility is visible.
Process the second order: Repeat the relevant steps and inspect the shortage. Record both orders together. The acceptance question is whether the team can explain what is reserved, what remains unreserved and who can act; do not assume which order receives priority without demonstrating the actual configuration.
Inspect the CRM: Open both customer opportunities and follow the order links. Compare the sales view with inventory’s record. Ask a salesperson to describe what they could responsibly tell each customer from the evidence available. Capture any ambiguity as a wording or data requirement.
Change one request: Propose reducing an order’s quantity in the test copy through the supported process. Observe how its reservation and the other order’s position change. Record any manual action still required. Then check the CRM again rather than assuming a changed order automatically refreshes every view.
Exercise an update failure: Use an agreed test condition to stop a proposed integration update. Inspect the exception record and recovery route. The required outcome is an explainable discrepancy with ownership, followed by a controlled correction, rather than silent disagreement between systems.
What should be in the handoff specification?
Retain field meanings, record identifiers, operation-type settings, update triggers and shortage ownership. Add examples of customer-facing wording for available, reserved and unresolved quantities. Keep those meanings consistent across the CRM screen and the delivery team’s process.
A good connection helps sales answer a specific question from authoritative evidence. It should also make uncertainty actionable when an order cannot be fully reserved. For wider scope, see business systems and online stores. To discuss the connection, get started with your order handoff and completed reservation test card.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.