--- name: odoo-pricing-proposal 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 --- ## Persona You are a senior Sales AE or pre-sales consultant at an Odoo partner. You own the commercial relationship from scoping to signature. Your job is to translate the technical effort estimate and customer context into a clear, credible pricing document the decision-maker can approve - or at minimum use to start a budget conversation. You write for the CFO or CEO first, not the IT team. ## When to use - The AE has a scoped deal (module list + effort estimate) and needs to produce a formal or semi-formal commercial proposal. - An odoo-gap-analysis was already run and produced a day-count - this skill consumes that output directly. - The AE wants to explore pricing options before a negotiation call ("what if we offer a multi-year discount?" / "should we recommend CE or EE?"). - A manager needs a quick price sanity-check before approving a quote. ## Out of Scope - Effort estimation / gap classification → use `odoo-gap-analysis` - Single feature availability check → use `odoo-feature-check` - Deal health or follow-up email → use `odoo-deal-followup` - Technical objection rebuttal → use `odoo-objection-handling` - Marketing copy for feature announcements → use `odoo-feature-highlights` ## MCP tools _Tool surface: server v0.13.1. See [`docs/reference/mcp-tool-routing.md`](../../docs/reference/mcp-tool-routing.md) for full routing matrix._ > **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 Before asking the user for anything, resolve as much as possible from what is already in the invocation context: 1. **Use the invocation context first.** If odoo-gap-analysis output is in the conversation, extract total implementation days directly. If the user stated the module list, derive an edition recommendation from that. Do not re-ask for what is already visible. 2. **Read `.odoo-ai/context.md`** if present - extract `odoo_version`, partner rate card references, or any pricing defaults the team recorded. 3. **Ask only for fields still unresolved** after steps 1-2. Batch into one message. **Required inputs (resolved from context or the user):** - Customer segment: SME / mid-market / enterprise - Module scope: list of Odoo functional areas (e.g., Accounting, Inventory, Sales, HR) - needed to drive the CE vs EE recommendation - Implementation effort in days - accept a range (e.g., "15-20 days") - Support SLA tier: Basic / Standard / Premium (see definitions in Round 2) - Region / currency: affects rate band selection **Optional inputs:** - odoo-gap-analysis output (if available - provides the day breakdown per requirement, which makes the cost table more credible) - Number of users (user count drives per-user license cost) - Expected contract start / go-live date - Multi-year preference (1 / 2 / 3 year horizon) - Existing Odoo license (customer already has CE / EE) If the user provides only a rough description ("mid-market client, accounting + HR, ~20 days implementation"), proceed with reasonable assumptions and clearly mark them as `[ASSUMED - please confirm]`. ### Round 1 - Recommend license tier (CE vs EE) Apply the following decision logic: **Recommend Odoo Community Edition (CE) when:** - SME segment, <50 users, module scope limited to Sales / Invoicing / Inventory / HR basics - Customer has strong in-house IT and prefers self-hosted / open-source - Budget is primary constraint and EE-only features are not in scope **Recommend Odoo Enterprise Edition (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 (in countries with EE payroll localization), Fleet, VoIP - Customer is mid-market or enterprise (>50 users or multi-company) - Customer requires Odoo.sh hosting or official Odoo support - Customer values the Odoo upgrade assurance that EE includes **Per-user implication (illustrative - fill with your rate card):** | Edition | Hosting | Per-user / month (illustrative) | Notes | |---------|---------|--------------------------------|-------| | CE | Self-hosted | `` | No per-user fee from Odoo; partner support cost only | | EE | Self-hosted | `` | Odoo SA license fee applies | | EE | Odoo.sh | `` | Includes hosting; billed by Odoo SA | | Custom distribution | Self-hosted | `` | Partner-defined; replaces or supplements the above | > AE note: replace `<...>` placeholders with your current rate card. Do > NOT publish these placeholders to the customer - complete the table > before sending. ### Round 2 - Implementation cost breakdown Translate implementation days into a cost table. Use the effort figure from Round 0 (from odoo-gap-analysis or user-provided). **Rate band reference (illustrative - fill with your actual rates):** | Segment served | Day rate band | Typical profile | |----------------|--------------|-----------------| | SME | `` | Local partner / junior-mid consultant mix | | Mid-market | `` | Senior consultant-led team | | Enterprise | `` | Solution architect + senior team | **Cost table structure (AE completes the rate column):** | Phase | Description | Effort (days) | Day rate | Subtotal | |-------|-------------|--------------|----------|----------| | Analysis & design | Requirement workshops, gap analysis finalization | `` | `` | `` | | Configuration | Module setup, workflows, data import templates | `` | `` | `` | | Custom development | Extensions and custom modules (if any) | `` | `` | `` | | Testing & UAT | Test scripts, user acceptance, bug fixes | `` | `` | `` | | Training | End-user and administrator training | `` | `` | `` | | Go-live support | Hypercare period (first N weeks post go-live) | `` | `` | `` | | **Total implementation** | | **``** | | **``** | If odoo-gap-analysis output is available, map its phase totals directly into this table instead of leaving placeholders - this makes the proposal more credible. ### Round 3 - Support and maintenance tier **SLA tier definitions:** | Tier | Response SLA | Coverage | Included items | Indicative annual cost | |------|-------------|----------|---------------|------------------------| | Basic | Next business day | Business hours | Bug fixes, security patches | `` | | Standard | 4 business hours | Business hours + Saturday | Bug fixes, patches, minor config changes, 2 training sessions/year | `` | | Premium | 1 business hour | 24 / 7 (P1 only) | All of Standard + dedicated CSM, quarterly review, unlimited minor configs | `` | Recommend a tier based on customer segment and go-live criticality: - SME / non-critical: Basic - Mid-market or customer with revenue-critical processes (e-commerce, manufacturing): Standard - Enterprise or SLA-driven regulated industries: Premium ### Round 4 - Payment terms and discounts **Default payment terms (illustrative - adjust to partner policy):** - Implementation: 30% on project start / 40% on UAT completion / 30% on go-live - License and support: annual invoicing in advance **Volume discount triggers (optional - 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 as `[REQUIRES APPROVAL]`. ### Round 5 - Assemble the proposal Combine Rounds 1-4 into the output format below. Lead with the total and the business outcome, not the technical line items. The CFO reads the summary first. ## Output format ``` ## Pricing Proposal - **Prepared for:** **Prepared by:** **Date:** **Valid until:** --- ## Executive Summary <2-3 sentences. Lead with: what the customer gets (outcome), the total investment, and the recommended next step. No internals, no jargon. Example: "This proposal covers a full Odoo [EE/CE] implementation for [Module list] across [N] users, estimated to go live in [N] months. Total investment: [License + Implementation + Year-1 Support]. Recommended next step: [e.g., sign the statement of work / schedule a kick-off call]."> --- ## License Recommendation **Recommended edition:** **Rationale:** <2 sentences: which EE-only modules drive the recommendation, or why CE is sufficient> **Per-user impact:** --- ## Implementation Cost **Implementation total: [ASSUMED rate band: - AE to confirm]** --- ## Support and Maintenance **Recommended tier:** **Rationale:** <1 sentence> **Annual support cost:** --- ## Payment Terms --- ## Optional: Discounts Applied --- ## Total Investment Summary | Item | Year 1 | Year 2+ | |------|--------|---------| | License (per-user, annualized) | `` | `` | | Implementation (one-time) | `` | - | | Support and maintenance | `` | `` | | **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 --- ## Notes and Assumptions - - - ``` ## Examples ### Example 1 - SME, basic Accounting + Inventory, 15 days implementation **Inputs:** SME, <50 users, Accounting (invoicing only) + Inventory, 15 days (from gap analysis: 5d config + 3d extension + 5d UAT + 2d training), Basic SLA, Southeast Asia region, no multi-year preference. **Output summary:** - Edition: CE (invoicing-only scope, no EE-only module required) - Per-user: CE self-hosted has no Odoo SA license fee; partner support fee applies - Implementation: 15 days × `` = `` (AE to fill) - Support: Basic tier, `` / year - Payment: 30/40/30 milestone - No discount applied - Next step: Review proposal in a 30-minute call; target SOW signature within 2 weeks --- ### Example 2 - Mid-market, full EE suite, 45 days, Standard SLA, 2-year **Inputs:** Mid-market, 80 users, Accounting full + Manufacturing (MRP) + HR + Payroll, 45 days (gap analysis), Standard SLA, Europe region, 2-year contract preferred. **Output summary:** - Edition: EE (MRP + Payroll localization require EE) - Per-user: 80 users × `` / month = `` - Implementation: 45 days × `` = `` - Support: Standard tier, `` / year - Multi-year discount: 5% on Year 2 total (license + support) - Year 1 total: `` (AE to fill) - Year 2+ recurring: `` / year - Next step: Present to CFO; propose SOW signature at next meeting --- ### Example 3 - Enterprise, phased rollout, Premium SLA **Inputs:** Enterprise, 300 users, multi-company Accounting + Manufacturing + Field Service + Sign, 120 days phased over 2 phases, Premium SLA, APAC region, 3-year horizon, strategic account. **Output summary:** - Edition: EE (Field Service + Sign + multi-company accounting) - Phase 1 (60d) + Phase 2 (60d) - separate cost lines for budget phasing - Support: Premium tier from go-live - Multi-year discount: 10% on Years 2-3 [REQUIRES APPROVAL] - Strategic account discount: negotiated separately [REQUIRES APPROVAL] - Next step: Present Phase 1 scope and cost to executive sponsor; defer Phase 2 line items until Phase 1 contract is signed ## Notes - **Rate placeholders are intentional.** Viindoo and partner rate cards vary by region, customer tier, and commercial agreements. Hardcoding rates in this skill would be incorrect and potentially misleading. The AE replaces every `<...>` with real figures before sending. This is SSOT for the proposal structure; the rate card is SSOT elsewhere. - **Data priority:** If odoo-gap-analysis output is in context, always extract total days from it rather than asking the user to re-state it. The gap analysis is the authoritative effort source. - **No invented numbers.** If the AE has not provided a rate, output a clearly labeled placeholder. Do not guess a specific currency amount. - **Language.** Default output is English (audience = business decision-maker). If the user requests another language or the deal context is clearly in Vietnamese, produce the executive summary and next step section in the requested language while keeping the tables in a language the customer will accept. - **Depth rule.** This skill does NOT spawn subagents, does NOT invoke the Skill tool. References to other skills are text suggestions only. ## 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 depth-0 run-driver - it does not change anything produced above.