odoo-pricing-proposal

name	odoo-pricing-proposal
argument-hint	[customer/deal context]
description	Build a customer-facing pricing proposal for an Odoo deal - license tier recommendation (CE vs EE), implementation cost breakdown, support/maintenance tier, payment terms, optional volume and multi-year discounts, and a clear total with next steps. Accepts customer segment (SME / mid / enterprise), module scope, implementation effort in days (ideally from odoo-gap-analysis output), support SLA tier, and region. Outputs a structured sales document the AE can send or use as a conversation anchor. Trigger on: "draft a pricing proposal", "build a quote", "how much should we charge", "put together a commercial offer", "price breakdown". Vietnamese triggers: "báo giá", "đề xuất giá", "soạn báo giá cho khách", "lập bảng giá cho deal này", "ước tính chi phí cho khách hàng", "đề xuất thương mại". DO NOT trigger for: gap analysis/effort estimation (odoo-gap-analysis), feature check (odoo-feature-check), deal follow-up email (odoo-deal-followup), technical objections (odoo-objection-handling)
model	inherit

Role

Commercial pricing-proposal authoring for an Odoo partner (Sales AE / pre-sales consultant scope, from scoping to signature). Turns technical effort estimates and customer context into a clear, credible pricing document a decision-maker can approve. Audience: the CFO or CEO first, not the IT team - the document reads for the economic buyer.

When to use

• AE has a scoped deal (module list + effort estimate) and needs a formal or semi-formal commercial proposal
• An odoo-gap-analysis was already run - this skill consumes that output directly
• AE wants to explore pricing options before a negotiation call (CE vs EE? multi-year discount?)
• Manager needs a quick price sanity-check before approving a quote

Out of Scope

• Effort estimation / gap classification → odoo-gap-analysis
• Single feature availability → odoo-feature-check
• Deal health or follow-up email → odoo-deal-followup
• Technical objection rebuttal → odoo-objection-handling
• Marketing copy for feature announcements → odoo-feature-highlights

MCP tools

Pick the right tool first. Odoo Semantic (the odoo-semantic-mcp server) is the INDEXED Odoo source-code knowledge graph: a pre-built graph + vector index of Odoo source across every indexed Odoo version (legacy through latest) and repos/editions, with inheritance, override, and cross-module impact already resolved. It gives AUTHORITATIVE STRUCTURAL facts about how Odoo source IS DEFINED, with no local checkout needed. Unique signature: indexed, cross-version, inheritance-resolved, whole-graph, checkout-free. It is a STATIC index with NO runtime/live data.

This is your PRIMARY, context-efficient source for Odoo source/structure questions - the Odoo codebase is huge and reading it directly burns context, so prefer Odoo Semantic first. Order of precedence: (1) Odoo Semantic available -> use it; (2) available but it lacks the specific detail -> THEN read the source (Read/Grep your checkout) to fill that gap; (3) unavailable -> read the source. Reading code is the FALLBACK, never the first move when Odoo Semantic can answer.

Do NOT use Odoo Semantic for:

• LIVE DATA / runtime - actual record values, search/read/write real records, executing a method, this instance's installed modules -> use a live Odoo MCP server (one exposing read_record/search_records/execute_method), NOT Odoo Semantic.

Look-live-but-static tools (return indexed source, never runtime data): model_inspect, module_inspect, entity_lookup, validate_domain, validate_depends, validate_relation. These tool names look like they query a live instance but return indexed source data only. If you need live records, Odoo Semantic is the wrong server.

Standalone-first fallback

Skill always operates without OSM or any live server. All logic runs on user-provided inputs and training knowledge about Odoo CE / EE licensing models.

Round 0 - Bootstrap context, then ask only for gaps

1. Input port gap_matrix_path (preferred cost basis). Glob <SHARE_DIR>/gap-analysis/*/gap-matrix.jsonl (resolve <SHARE_DIR> once per ${CLAUDE_PLUGIN_ROOT}/snippets/state-root-resolution.md; substitute the captured absolute path - never write the placeholder or a bare .odoo-ai/ into a Read/Write/Edit); on a hit, READ the newest match and derive the cost basis FROM the artifact instead of asking the user to paste numbers - cite the path in the proposal. Per row, map effort_tier to days (band S 0-1 / M 1-3 / L 3-10 / XL 10-20) and route classification to a cost-table phase (standard/config -> Configuration; extension/custom -> Custom development). For the aggregate implementation min-max, read the sibling gap-continuation-contract.json meta.effort_days{min,max} (or the gap-report.md Total row). If odoo-gap-analysis output is instead already in the conversation, use that directly.
2. Fallback - no artifact. When the glob misses and no gap output is in context, accept an effort range from chat (e.g. "15-20 days") via the Required inputs below.
3. Edition signal. If the user stated the module list, derive an edition recommendation from it. Do not re-ask for what the artifact or context already provides.
4. Read <SHARE_DIR>/context.md if present - extract odoo_version, partner rate card references, or any pricing defaults the team recorded.
5. Ask only for fields still unresolved after steps 1-4. Batch into one message.

Required inputs:

• Customer segment: SME / mid-market / enterprise
• Module scope: list of Odoo functional areas - needed to drive CE vs EE recommendation
• Implementation effort in days - accept a range (e.g., "15-20 days")
• Support SLA tier: Basic / Standard / Premium
• Region / currency: affects rate band selection

Optional inputs: odoo-gap-analysis output; number of users; expected start / go-live date; multi-year preference; existing Odoo license.

If the user provides only a rough description ("mid-market client, accounting + HR, ~20 days"), proceed with reasonable assumptions and mark them [ASSUMED - please confirm].

Round 1 - Recommend license tier (CE vs EE)

Recommend CE when: SME segment, <50 users, module scope limited to Sales / Invoicing / Inventory / HR basics; strong in-house IT preferring self-hosted / open-source; budget is primary constraint and EE-only features are not in scope.

Recommend EE when: Any of the following modules are in scope: Accounting full suite (multi-company, bank sync), Manufacturing (MRP), Field Service, Sign, eLearning, IoT, Helpdesk, Quality, Maintenance, Appraisals, Payroll (EE localization), Fleet, VoIP; OR customer is mid-market or enterprise (>50 users or multi-company); OR customer requires Odoo.sh hosting or official Odoo support or upgrade assurance.

Per-user implication (illustrative - fill with your rate card):

Edition	Hosting	Per-user / month (illustrative)	Notes
CE	Self-hosted	<CE self-hosted rate>	No per-user fee from Odoo; partner support cost only
EE	Self-hosted	<EE self-hosted rate / user / month>	Odoo SA license fee applies
EE	Odoo.sh	<EE Odoo.sh rate / user / month>	Includes hosting; billed by Odoo SA
Custom distribution	Self-hosted	<partner rate / user / month>	Partner-defined; replaces or supplements the above

AE note: replace <...> placeholders with your current rate card before sending to the customer.

Round 2 - Implementation cost breakdown

Translate implementation days into a cost table. Use effort from Round 0.

Rate band reference (illustrative):

Segment	Day rate band	Typical profile
SME	<SME day rate band>	Local partner / junior-mid consultant mix
Mid-market	<mid-market day rate band>	Senior consultant-led team
Enterprise	<enterprise day rate band>	Solution architect + senior team

Cost table structure:

Phase	Description	Effort (days)	Day rate	Subtotal
Analysis & design	Requirement workshops, gap analysis finalization	<days>	<rate>	<subtotal>
Configuration	Module setup, workflows, data import templates	<days>	<rate>	<subtotal>
Custom development	Extensions and custom modules (if any)	<days>	<rate>	<subtotal>
Testing & UAT	Test scripts, user acceptance, bug fixes	<days>	<rate>	<subtotal>
Training	End-user and administrator training	<days>	<rate>	<subtotal>
Go-live support	Hypercare period (first N weeks post go-live)	<days>	<rate>	<subtotal>
Total implementation		<total days>		<total>

If the gap-matrix.jsonl artifact resolved in Round 0, map its per-row effort_tier (summed by classification -> phase) directly into this table and cite the path; otherwise use the effort range from chat.

Round 3 - Support and maintenance tier

Tier	Response SLA	Coverage	Included items	Indicative annual cost
Basic	Next business day	Business hours	Bug fixes, security patches	<basic tier rate>
Standard	4 business hours	Business hours + Saturday	Bug fixes, patches, minor config changes, 2 training sessions/year	<standard tier rate>
Premium	1 business hour	24/7 (P1 only)	All Standard + dedicated CSM, quarterly review, unlimited minor configs	<premium tier rate>

Tier recommendation: SME / non-critical → Basic; Mid-market or revenue-critical → Standard; Enterprise or SLA-driven regulated → Premium.

Round 4 - Payment terms and discounts

Default payment terms: Implementation: 30% on project start / 40% on UAT completion / 30% on go-live. License and support: annual invoicing in advance.

Volume discount triggers (offer only when deal size justifies):

Condition	Suggested discount	Notes
>50 users	5-10% on license	Volume licensing
Multi-year contract (2y)	5% on total year 2	Lock-in incentive
Multi-year contract (3y)	10% on total years 2-3	Preferred for retention
Strategic / reference account	Negotiate separately	Requires manager approval

Apply discounts only when the AE has explicit authority. Mark unapproved discounts [REQUIRES APPROVAL].

Round 5 - Assemble the proposal

Combine Rounds 1-4 into the output format below. Lead with the total and business outcome, not technical line items. The CFO reads the summary first.

Output format

## Pricing Proposal - <Customer label>

**Prepared for:** <Customer label or "Prospect">
**Prepared by:** <Partner name - fill in>
**Date:** <date>
**Valid until:** <date + 30 days default>

---

## Executive Summary

<2-3 sentences. Lead with: what the customer gets (outcome), the total investment, and the
recommended next step. No internals, no jargon.>

---

## License Recommendation

**Recommended edition:** <CE | EE | Custom distribution>
**Rationale:** <2 sentences: which EE-only modules drive the recommendation, or why CE is sufficient>
**Per-user impact:** <Reference the rate table from Round 1; flag if AE still needs to fill in actual rate>

---

## Implementation Cost

<Paste the cost table from Round 2>

**Implementation total: <total> [ASSUMED rate band: <band> - AE to confirm]**

---

## Support and Maintenance

**Recommended tier:** <Basic | Standard | Premium>
**Rationale:** <1 sentence>
**Annual support cost:** <rate from Round 3 - or placeholder>

---

## Payment Terms

<Milestone schedule from Round 4>

---

## Optional: Discounts Applied

<List any discounts, their triggers, and approval status. If none: "No discount applied at this stage.">

---

## Total Investment Summary

| Item | Year 1 | Year 2+ |
|------|--------|---------|
| License (per-user, annualized) | `<Y1>` | `<Y2+>` |
| Implementation (one-time) | `<impl total>` | - |
| Support and maintenance | `<support Y1>` | `<support Y2+>` |
| **Total** | **`<Y1 total>`** | **`<Y2+ total>`** |

> Numbers are illustrative until the AE replaces all `<...>` placeholders with rate-card values.
> Do not send this proposal to the customer until all placeholders are resolved.

---

## Next Step

<One clear, specific action with a proposed date or deadline.>

---

## Notes and Assumptions

- <List all [ASSUMED] flags from the body with a short justification>
- <Any items that will increase cost if scope changes>
- <Any prerequisites (e.g., "customer must provide clean data export for migration before project start")>

Worked examples: ${CLAUDE_PLUGIN_ROOT}/skills/odoo-pricing-proposal/references/examples.md

Notes

• Rate placeholders are intentional. Rate cards vary by region, customer tier, and commercial agreement; hardcoding would be incorrect and misleading. The AE replaces every <...> before sending. SSOT for the proposal structure; the rate card is SSOT elsewhere.
• Data priority: Prefer the gap-matrix.jsonl artifact (glob <SHARE_DIR>/gap-analysis/*/gap-matrix.jsonl, cite the path) or in-context odoo-gap-analysis output as the cost basis; only ask the user for an effort range when neither exists.
• No invented numbers. If the AE has not provided a rate, output a clearly labeled placeholder.
• Language. Default English (audience = business decision-maker). If the user requests another language or the deal context is clearly in Vietnamese, produce executive summary and next step in the requested language while keeping tables in a language the customer will accept.
• Leaf skill. Does NOT spawn subagents, does NOT invoke the Skill tool.

Continuation Contract

When you finish, append a Continuation Contract block per ${CLAUDE_PLUGIN_ROOT}/snippets/continuation-contract.md (status / produced / next). Additive output for the run-harness - it does not change anything produced above.