Business result
The operational behavior the client expects after delivery.
Odoo 19 reference guide for service providers
Build Odoo Services Clients Can Understand—and You Can Deliver Repeatedly.
A professional method for turning functional knowledge into defined service outcomes, disciplined discovery, controlled configuration, evidence-based acceptance, clear handover, and responsible support boundaries.
7elements of a defined offer
8client delivery gates
1agreed acceptance result
Service design 01 · Productize the outcome
“I know Odoo” is expertise—not yet a defined service
A client must be able to understand what changes, what remains outside the engagement, what evidence will be delivered, and which transaction proves completion. Define the service before a request forces you to improvise.
Functional scope
Applications, screens, data, users, documents, and transactions included.
Exclusions
Programming, migration, integration, infrastructure, compliance, and unrelated work not included.
Prerequisites
Access, edition, modules, data, responsible users, decisions, and safe test conditions.
Deliverables
Configuration, test record, evidence, procedure, findings, and handover note.
Acceptance test
The representative transaction and expected result that define “done.”
Support boundary
Correction window, included clarification, response ownership, and new-request rules.
Service design 02 · Separate levels of responsibility
Three service levels a client can distinguish
Do not mix advice, configuration, and complete workflow delivery inside one vague promise. Each level needs its own boundary, evidence, and acceptance condition.
| Service level | Appropriate outcome | Core deliverables | Boundary |
|---|---|---|---|
| Diagnosis & guidance | Clarify one setting, path, decision, or functional gap. | Relevant path, setup logic, dependencies, suggested test, short findings note. | No implementation unless explicitly included; unrelated configuration and specialist work remain excluded. |
| Bounded functional configuration | Implement one defined standard Odoo configuration area. | Discovery, prerequisites, approved setup, controlled test, validation evidence, handover note. | Only the agreed functional area; no new code, broad cleanup, migration, or unscoped applications. |
| End-to-end workflow delivery | Configure and validate one complete business cycle across relevant applications. | Workflow map, dependency review, configuration, representative transaction, acceptance evidence, procedure, handover. | Only the agreed workflow; integrations, custom modules, infrastructure, migration, and statutory advice require separate evaluation. |
Discovery is part of delivery—not a conversation before “the real work.”
Required business result and current workflow.
Odoo version, edition, and installed applications.
Users, roles, approvals, and permitted access.
Existing customization, integrations, and automation.
Shared products, partners, taxes, accounts, and warehouses.
Localization, currency, company, and data-quality conditions.
Normal transaction and material exception scenarios.
Client inputs, decisions, dependencies, and responsibilities.
Deliverables, exclusions, evidence, and acceptance criteria.
Handover, correction, support, and change-request boundaries.
Client delivery system
Eight gates that make the engagement repeatable
Speed should come from a reusable method—not from skipping the controls that protect the client, the database, and your professional reputation.
Discovery
Understand the operation, target result, environment, users, data, risks, and constraints.
Scope
State included work, exclusions, deliverables, assumptions, test, and “done.”
Prerequisites
Confirm modules, permissions, decisions, data, backups, and safe test conditions.
Configuration
Use standard Odoo first and record the settings that control the outcome.
Execution
Run the real document sequence with controlled or demo data before rollout.
Validation
Test normal flow, a material exception, dependencies, entries, and reports.
Evidence
Capture settings, documents, expected versus actual results, and known limits.
Handover
Transfer the procedure, roles, monitoring, support boundary, and change rules.
Result
The client can create an approved quotation, confirm the order, complete the intended delivery behavior, generate the correct invoice, and explain the final result.
Inputs
Version, edition, current process, products, customers, pricing, discounts, delivery, invoicing policy, taxes, user roles, and known customizations.
Included
Discovery for the agreed workflow, standard configuration, dependency and permission checks, representative test, evidence, and handover note.
Excluded
Custom code, API integration, migration, broad data cleanup, statutory certification, infrastructure, and applications not identified during discovery.
Acceptance
Create the agreed customer quotation, apply the intended rules, confirm it, complete delivery behavior, create the invoice, and verify the expected operational and financial result.
Support
Clarification and correction related to the agreed setup are handled within the stated boundary. New behavior or additional applications require fresh discovery and scope.
Change control
Recognize a new request before it becomes hidden scope
A request is not automatically “a small adjustment.” Classify it against the agreed business result, affected applications, risk, data, and acceptance test.
| Client request | Classification question | Professional response |
|---|---|---|
| Correction | Does delivered behavior fail the agreed acceptance test under the original conditions? | Investigate and correct within the stated correction boundary. |
| Clarification | Is the client asking how to operate the delivered workflow? | Refer to the handover procedure and clarify within the agreed support window. |
| Configuration extension | Does the request add new rules, roles, records, exceptions, or applications? | Run a focused impact review and define the additional functional scope. |
| Technical extension | Does it require code, an external system, infrastructure, security, or migration? | Separate the technical work and involve the appropriate qualified specialist. |
| Compliance request | Does it ask for statutory, tax, legal, audit, or jurisdiction-specific assurance? | Document the functional context and refer the assurance decision to the proper professional. |
Seven functional service blueprints
Build offers around outcomes you can scope, test, and hand over
Start with the application you understand best. Expand only when you can explain its dependencies and validate the complete downstream result.
Service nicheACAccounting
Possible service outcome
Configure and validate a traceable invoice-to-payment workflow
Scope may cover company accounting foundations, journals, accounts, taxes, terms, invoices, payments, reconciliation, permissions, and financial review.
Delivery sequence- Confirm localization, company, currency, policies, and roles.
- Review shared customer, vendor, product, tax, and account data.
- Run invoice, payment, reconciliation, and report validation.
Dependency and boundary
Sales, Purchase, Inventory, Manufacturing, Expenses, and POS may generate the accounting result. Statutory, tax, audit, or legal assurance remains outside a functional setup unless separately delivered by qualified professionals.
Acceptance evidence: document, journal items, tax behavior, settlement, balances, aging, and reports can be explained from the test.
Service nicheINInventory
Possible service outcome
Configure a controlled replenishment and stock-movement workflow
Scope may cover products, warehouses, locations, routes, receipts, deliveries, transfers, returns, reservations, reordering, traceability, counts, and validation.
Delivery sequence- Map physical flow before configuring digital locations and routes.
- Review units, tracking, lead times, supply method, and permissions.
- Test demand, replenishment, receipt, reservation, delivery, and exception.
Dependency and boundary
Sales and POS create demand, Purchase and Manufacturing create supply, while Accounting may receive valuation effects. Warehouse redesign, devices, migration, or third-party logistics integration needs separate scope.
Acceptance evidence: physical flow, stock documents, quantities, reservations, traceability, replenishment, and reports agree.
Service nicheMRPManufacturing
Possible service outcome
Configure and test one product’s end-to-end production flow
Scope may cover product structure, bills of materials, components, operations, work centers, planning, work orders, quality, by-products, scrap, and cost review.
Delivery sequence- Confirm product, quantities, operation sequence, resources, and quality points.
- Check component availability, replenishment, capacity, and access roles.
- Complete one production order including exception and cost evidence.
Dependency and boundary
Sales demand, Purchase supply, Inventory movement, and Accounting valuation affect the outcome. Engineering design, machine integration, IoT, advanced planning, or custom costing require separate expertise and scope.
Acceptance evidence: correct consumption, output, operations, traceability, quality status, scrap, stock, and understandable cost.
Service nichePOPurchase
Possible service outcome
Configure a controlled multi-vendor procure-to-bill cycle
Scope may cover vendors, supplier prices, products, units, currencies, lead times, RFQs, comparison, approvals, receipts, returns, bill control, taxes, and payment terms.
Delivery sequence- Define the procurement requirement and decision criteria.
- Configure vendor conditions, approvals, products, and receipt logic.
- Test RFQ, order, receipt, exception, bill matching, and payable handoff.
Dependency and boundary
Inventory, Manufacturing, Sales, or POS may generate the need; Accounting receives the liability. Supplier negotiation, legal contracting, customs, and external procurement integrations remain separate work.
Acceptance evidence: vendor decision, authorization, order, receipt, exception, bill, tax, and payment terms remain consistent.
Service nicheSOSales
Possible service outcome
Configure and validate a controlled quotation-to-invoice workflow
Scope may cover teams, customers, products, pricelists, discounts, quotation templates, approvals, orders, delivery, returns, invoicing, payments, and analysis.
Delivery sequence- Define commercial rules, responsibility, products, pricing, and approvals.
- Confirm supply, delivery, invoicing, tax, and payment dependencies.
- Test the normal sale and one discount, return, or partial-delivery exception.
Dependency and boundary
Inventory, Purchase, Manufacturing, and Accounting continue the sales promise. CRM strategy, custom eCommerce, integrations, code, data migration, or legal terms require separate scope.
Acceptance evidence: quotation, approval, order, supply, delivery, invoice basis, payment, and analysis match the agreed behavior.
Service nichePOSPOS & Kitchen
Possible service outcome
Configure a restaurant order-to-kitchen-to-close workflow
Scope may cover POS configuration, products, taxes, floors, tables, preparation areas, kitchen routing, payments, refunds, cash control, sessions, stock, and reporting.
Delivery sequence- Map customer service, preparation, payment, and closing roles.
- Configure products, routing, payment methods, permissions, and sessions.
- Test order, preparation, settlement, refund, stock, and close.
Dependency and boundary
POS shares products, reduces Inventory, may drive Purchase or Manufacturing, and hands financial results to Accounting. Hardware, payment acquiring, network, kitchen devices, or custom integration need separate technical scope.
Acceptance evidence: order, preparation status, receipt, payment, refund, stock effect, totals, difference, and session close reconcile.
Service nicheEXExpenses
Possible service outcome
Configure an evidence-to-approval-to-reimbursement workflow
Scope may cover policy, categories, receipts, currencies, descriptions, users, managers, permissions, approvals, payer responsibility, reimbursement, analytics, accounting, and reporting.
Delivery sequence- Define permitted costs, required evidence, roles, and approval path.
- Configure category, payer, currency, account, and analytic behavior.
- Test submission, correction or refusal, approval, reimbursement, and reports.
Dependency and boundary
Expenses connects employees and Accounting while remaining distinct from procurement, stock, production, and POS spending. HR policy, tax deductibility, payroll, and statutory advice require separate professional review.
Acceptance evidence: receipt, business purpose, decision history, payer, reimbursement, employee balance, accounts, and cost analysis remain traceable.
Inside the guided workspace
Ten examples of delivery thinking across connected applications
Read each preview like a client-delivery record: outcome, confirmed path, controlling fields, dependencies, test transaction, evidence, and next decision.
Build one responsible offer first
A practical 30-day service-building roadmap
Choose one outcome narrow enough to understand, execute, test, document, and support. A defined service can then be improved through evidence rather than expanded through promises.
Select the niche
- Choose one application and business result.
- Define the ideal client and required environment.
- List capability limits and specialist boundaries.
Design the offer
- Write result, scope, exclusions, and prerequisites.
- Define deliverables and acceptance transaction.
- Create discovery and change-control questions.
Prove delivery
- Configure the workflow in a safe environment.
- Test normal and exception cases.
- Capture evidence, limits, and lessons.
Prepare handover
- Create the operating procedure and evidence pack.
- Define correction and support boundaries.
- Review the offer before presenting it to a client.
Professional guardrails
A clear boundary protects the client, the database, and your reputation
Accept understood work
Accept only outcomes you can scope, configure, test, explain, document, and support responsibly. A larger promise is not a stronger service.
Separate specialist work
Code, integrations, infrastructure, migration, advanced security, legal, tax, audit, and statutory requirements need their own qualified expertise and scope.
Protect data and permission
Use authorized access, appropriate test methods, safe data, change records, and client-approved evidence. Never expose credentials or confidential information.
Do not imply affiliation
Do not claim official Odoo certification, partnership, endorsement, or authority unless you are entitled to make that exact claim.
Use portfolio evidence responsibly
Reuse only authorized, anonymized material. Client names, screenshots, results, or business processes require appropriate permission.
Avoid commercial guarantees
A disciplined offer may improve clarity and delivery, but it does not guarantee clients, marketplace approval, reviews, revenue, or profit.
Continue the learning path
Define the first service before the first client request arrives.
Choose one outcome, document the scope and exclusions, build a safe delivery workflow, create the acceptance test, and prepare the handover. Expand only as verified capability grows.
Odoo 19 reference guide for service providers
Build Odoo Services Clients Can Understand—and You Can Deliver Repeatedly.
A professional method for turning functional knowledge into defined service outcomes, disciplined discovery, controlled configuration, evidence-based acceptance, clear handover, and responsible support boundaries.
7elements of a defined offer
8client delivery gates
1agreed acceptance result
Service design 01 · Productize the outcome
“I know Odoo” is expertise—not yet a defined service
A client must be able to understand what changes, what remains outside the engagement, what evidence will be delivered, and which transaction proves completion. Define the service before a request forces you to improvise.
Business result
The operational behavior the client expects after delivery.
Functional scope
Applications, screens, data, users, documents, and transactions included.
Exclusions
Programming, migration, integration, infrastructure, compliance, and unrelated work not included.
Prerequisites
Access, edition, modules, data, responsible users, decisions, and safe test conditions.
Deliverables
Configuration, test record, evidence, procedure, findings, and handover note.
Acceptance test
The representative transaction and expected result that define “done.”
Support boundary
Correction window, included clarification, response ownership, and new-request rules.
Service design 02 · Separate levels of responsibility
Three service levels a client can distinguish
Do not mix advice, configuration, and complete workflow delivery inside one vague promise. Each level needs its own boundary, evidence, and acceptance condition.
| Service level | Appropriate outcome | Core deliverables | Boundary |
|---|---|---|---|
| Diagnosis & guidance | Clarify one setting, path, decision, or functional gap. | Relevant path, setup logic, dependencies, suggested test, short findings note. | No implementation unless explicitly included; unrelated configuration and specialist work remain excluded. |
| Bounded functional configuration | Implement one defined standard Odoo configuration area. | Discovery, prerequisites, approved setup, controlled test, validation evidence, handover note. | Only the agreed functional area; no new code, broad cleanup, migration, or unscoped applications. |
| End-to-end workflow delivery | Configure and validate one complete business cycle across relevant applications. | Workflow map, dependency review, configuration, representative transaction, acceptance evidence, procedure, handover. | Only the agreed workflow; integrations, custom modules, infrastructure, migration, and statutory advice require separate evaluation. |
Discovery is part of delivery—not a conversation before “the real work.”
Required business result and current workflow.
Odoo version, edition, and installed applications.
Users, roles, approvals, and permitted access.
Existing customization, integrations, and automation.
Shared products, partners, taxes, accounts, and warehouses.
Localization, currency, company, and data-quality conditions.
Normal transaction and material exception scenarios.
Client inputs, decisions, dependencies, and responsibilities.
Deliverables, exclusions, evidence, and acceptance criteria.
Handover, correction, support, and change-request boundaries.
Client delivery system
Eight gates that make the engagement repeatable
Speed should come from a reusable method—not from skipping the controls that protect the client, the database, and your professional reputation.
Discovery
Understand the operation, target result, environment, users, data, risks, and constraints.
Scope
State included work, exclusions, deliverables, assumptions, test, and “done.”
Prerequisites
Confirm modules, permissions, decisions, data, backups, and safe test conditions.
Configuration
Use standard Odoo first and record the settings that control the outcome.
Execution
Run the real document sequence with controlled or demo data before rollout.
Validation
Test normal flow, a material exception, dependencies, entries, and reports.
Evidence
Capture settings, documents, expected versus actual results, and known limits.
Handover
Transfer the procedure, roles, monitoring, support boundary, and change rules.
Result
The client can create an approved quotation, confirm the order, complete the intended delivery behavior, generate the correct invoice, and explain the final result.
Inputs
Version, edition, current process, products, customers, pricing, discounts, delivery, invoicing policy, taxes, user roles, and known customizations.
Included
Discovery for the agreed workflow, standard configuration, dependency and permission checks, representative test, evidence, and handover note.
Excluded
Custom code, API integration, migration, broad data cleanup, statutory certification, infrastructure, and applications not identified during discovery.
Acceptance
Create the agreed customer quotation, apply the intended rules, confirm it, complete delivery behavior, create the invoice, and verify the expected operational and financial result.
Support
Clarification and correction related to the agreed setup are handled within the stated boundary. New behavior or additional applications require fresh discovery and scope.
Change control
Recognize a new request before it becomes hidden scope
A request is not automatically “a small adjustment.” Classify it against the agreed business result, affected applications, risk, data, and acceptance test.
| Client request | Classification question | Professional response |
|---|---|---|
| Correction | Does delivered behavior fail the agreed acceptance test under the original conditions? | Investigate and correct within the stated correction boundary. |
| Clarification | Is the client asking how to operate the delivered workflow? | Refer to the handover procedure and clarify within the agreed support window. |
| Configuration extension | Does the request add new rules, roles, records, exceptions, or applications? | Run a focused impact review and define the additional functional scope. |
| Technical extension | Does it require code, an external system, infrastructure, security, or migration? | Separate the technical work and involve the appropriate qualified specialist. |
| Compliance request | Does it ask for statutory, tax, legal, audit, or jurisdiction-specific assurance? | Document the functional context and refer the assurance decision to the proper professional. |
Seven functional service blueprints
Build offers around outcomes you can scope, test, and hand over
Start with the application you understand best. Expand only when you can explain its dependencies and validate the complete downstream result.
Service nicheACAccounting
Possible service outcome
Configure and validate a traceable invoice-to-payment workflow
Scope may cover company accounting foundations, journals, accounts, taxes, terms, invoices, payments, reconciliation, permissions, and financial review.
Delivery sequence- Confirm localization, company, currency, policies, and roles.
- Review shared customer, vendor, product, tax, and account data.
- Run invoice, payment, reconciliation, and report validation.
Dependency and boundary
Sales, Purchase, Inventory, Manufacturing, Expenses, and POS may generate the accounting result. Statutory, tax, audit, or legal assurance remains outside a functional setup unless separately delivered by qualified professionals.
Acceptance evidence: document, journal items, tax behavior, settlement, balances, aging, and reports can be explained from the test.
Service nicheINInventory
Possible service outcome
Configure a controlled replenishment and stock-movement workflow
Scope may cover products, warehouses, locations, routes, receipts, deliveries, transfers, returns, reservations, reordering, traceability, counts, and validation.
Delivery sequence- Map physical flow before configuring digital locations and routes.
- Review units, tracking, lead times, supply method, and permissions.
- Test demand, replenishment, receipt, reservation, delivery, and exception.
Dependency and boundary
Sales and POS create demand, Purchase and Manufacturing create supply, while Accounting may receive valuation effects. Warehouse redesign, devices, migration, or third-party logistics integration needs separate scope.
Acceptance evidence: physical flow, stock documents, quantities, reservations, traceability, replenishment, and reports agree.
Service nicheMRPManufacturing
Possible service outcome
Configure and test one product’s end-to-end production flow
Scope may cover product structure, bills of materials, components, operations, work centers, planning, work orders, quality, by-products, scrap, and cost review.
Delivery sequence- Confirm product, quantities, operation sequence, resources, and quality points.
- Check component availability, replenishment, capacity, and access roles.
- Complete one production order including exception and cost evidence.
Dependency and boundary
Sales demand, Purchase supply, Inventory movement, and Accounting valuation affect the outcome. Engineering design, machine integration, IoT, advanced planning, or custom costing require separate expertise and scope.
Acceptance evidence: correct consumption, output, operations, traceability, quality status, scrap, stock, and understandable cost.
Service nichePOPurchase
Possible service outcome
Configure a controlled multi-vendor procure-to-bill cycle
Scope may cover vendors, supplier prices, products, units, currencies, lead times, RFQs, comparison, approvals, receipts, returns, bill control, taxes, and payment terms.
Delivery sequence- Define the procurement requirement and decision criteria.
- Configure vendor conditions, approvals, products, and receipt logic.
- Test RFQ, order, receipt, exception, bill matching, and payable handoff.
Dependency and boundary
Inventory, Manufacturing, Sales, or POS may generate the need; Accounting receives the liability. Supplier negotiation, legal contracting, customs, and external procurement integrations remain separate work.
Acceptance evidence: vendor decision, authorization, order, receipt, exception, bill, tax, and payment terms remain consistent.
Service nicheSOSales
Possible service outcome
Configure and validate a controlled quotation-to-invoice workflow
Scope may cover teams, customers, products, pricelists, discounts, quotation templates, approvals, orders, delivery, returns, invoicing, payments, and analysis.
Delivery sequence- Define commercial rules, responsibility, products, pricing, and approvals.
- Confirm supply, delivery, invoicing, tax, and payment dependencies.
- Test the normal sale and one discount, return, or partial-delivery exception.
Dependency and boundary
Inventory, Purchase, Manufacturing, and Accounting continue the sales promise. CRM strategy, custom eCommerce, integrations, code, data migration, or legal terms require separate scope.
Acceptance evidence: quotation, approval, order, supply, delivery, invoice basis, payment, and analysis match the agreed behavior.
Service nichePOSPOS & Kitchen
Possible service outcome
Configure a restaurant order-to-kitchen-to-close workflow
Scope may cover POS configuration, products, taxes, floors, tables, preparation areas, kitchen routing, payments, refunds, cash control, sessions, stock, and reporting.
Delivery sequence- Map customer service, preparation, payment, and closing roles.
- Configure products, routing, payment methods, permissions, and sessions.
- Test order, preparation, settlement, refund, stock, and close.
Dependency and boundary
POS shares products, reduces Inventory, may drive Purchase or Manufacturing, and hands financial results to Accounting. Hardware, payment acquiring, network, kitchen devices, or custom integration need separate technical scope.
Acceptance evidence: order, preparation status, receipt, payment, refund, stock effect, totals, difference, and session close reconcile.
Service nicheEXExpenses
Possible service outcome
Configure an evidence-to-approval-to-reimbursement workflow
Scope may cover policy, categories, receipts, currencies, descriptions, users, managers, permissions, approvals, payer responsibility, reimbursement, analytics, accounting, and reporting.
Delivery sequence- Define permitted costs, required evidence, roles, and approval path.
- Configure category, payer, currency, account, and analytic behavior.
- Test submission, correction or refusal, approval, reimbursement, and reports.
Dependency and boundary
Expenses connects employees and Accounting while remaining distinct from procurement, stock, production, and POS spending. HR policy, tax deductibility, payroll, and statutory advice require separate professional review.
Acceptance evidence: receipt, business purpose, decision history, payer, reimbursement, employee balance, accounts, and cost analysis remain traceable.
Inside the guided workspace
Ten examples of delivery thinking across connected applications
Read each preview like a client-delivery record: outcome, confirmed path, controlling fields, dependencies, test transaction, evidence, and next decision.
Build one responsible offer first
A practical 30-day service-building roadmap
Choose one outcome narrow enough to understand, execute, test, document, and support. A defined service can then be improved through evidence rather than expanded through promises.
Select the niche
- Choose one application and business result.
- Define the ideal client and required environment.
- List capability limits and specialist boundaries.
Design the offer
- Write result, scope, exclusions, and prerequisites.
- Define deliverables and acceptance transaction.
- Create discovery and change-control questions.
Prove delivery
- Configure the workflow in a safe environment.
- Test normal and exception cases.
- Capture evidence, limits, and lessons.
Prepare handover
- Create the operating procedure and evidence pack.
- Define correction and support boundaries.
- Review the offer before presenting it to a client.
Professional guardrails
A clear boundary protects the client, the database, and your reputation
Accept understood work
Accept only outcomes you can scope, configure, test, explain, document, and support responsibly. A larger promise is not a stronger service.
Separate specialist work
Code, integrations, infrastructure, migration, advanced security, legal, tax, audit, and statutory requirements need their own qualified expertise and scope.
Protect data and permission
Use authorized access, appropriate test methods, safe data, change records, and client-approved evidence. Never expose credentials or confidential information.
Do not imply affiliation
Do not claim official Odoo certification, partnership, endorsement, or authority unless you are entitled to make that exact claim.
Use portfolio evidence responsibly
Reuse only authorized, anonymized material. Client names, screenshots, results, or business processes require appropriate permission.
Avoid commercial guarantees
A disciplined offer may improve clarity and delivery, but it does not guarantee clients, marketplace approval, reviews, revenue, or profit.
Continue the learning path
Define the first service before the first client request arrives.
Choose one outcome, document the scope and exclusions, build a safe delivery workflow, create the acceptance test, and prepare the handover. Expand only as verified capability grows.