We explored your full Odoo staging environment and parsed four real emails from your inbox. This is what we recommend and why.
The problem today: Customer emails a quote request (90% email, 10% WhatsApp). Back-office opens the email, opens Odoo, searches products one by one, checks which pricelist applies to that customer, manually assembles the proposal, sends it back. For a 20-item proposal in the EUR 4K-19K range, this takes significant time. Multiply by the daily volume across Portugal, Spain, France, and Italy.
| Phase | What | Odoo needed? | Timeline |
|---|---|---|---|
| MVP | Email parser + proposal draft from Excel catalog. All proposals reviewed by back-office. | No | 4 weeks |
| v2 | Live Odoo API: customer identification, correct pricelist per customer, stock availability. Auto-routing (clean requests = one-click confirm). | Yes (read) | 4-6 weeks after MVP |
| v3 | Odoo write-back (create sale.order). Learning from back-office corrections. | Yes (read+write) | 4 weeks after v2 |
Requested by Manuel Vidigal on the Apr 21 call. Not every request needs email parsing. For catalogue items with known product codes and prices, back-office or distributors can send the order directly (via Teams or WhatsApp) and get a proposal back in seconds -- skipping the email loop entirely.
Included in MVP scope. No separate fee. Ships with Module 1.
Internal note: +8-12 partner hours for scope + prompts + structured-format detector design. +10-15 dev hours for Teams/WhatsApp channel wiring and quote-recycle Odoo reads. No incremental infra cost. Keeps the MVP scope within the €3,750 go-live fee because it reuses everything.
Future modules (Carrier Claims, Customer Reactivation) are scoped in the Appendix.
Internal note: Module 2 (Carrier Claims) and Module 3 (Customer Reactivation) moved to Appendix -- Future Modules on Apr 22. Scope for the signed engagement is Module 1 + Module 1b only. "What We're NOT Building" (RMA A5, credit-note consolidation) was removed from the external doc to keep the proposal focused on what Aronlight is buying. Those decisions still stand; they're recorded in `call-notes.md` and the Deal Strategy appendix below.
Out of 13 steps, the AI handles 3. Every step marked System is work that AdapttoAI builds, configures, tests, and maintains. This is the product.
| # | Step | Today (manual) | With our system | Who handles this? |
|---|---|---|---|---|
| 1 | Customer sends email | Arrives in inbox | Arrives in inbox | - |
| 2 | Detect email and start processing | Someone checks inbox | Email monitor triggers pipeline | System Building the trigger, configuring Outlook access, filtering spam/duplicates/out-of-office replies, and keeping it running reliably. |
| 3 | Parse the email (any format) | Person reads it | AI extracts products, quantities, notes | AI Tested on all 4 types: text chains, embedded images, Excel BOMs, conversational requests. Handles all formats. |
| 4 | Identify customer in Odoo | Person recognizes sender | Match sender email to res.partner | System Real test: Metro de Madrid had 4 contacts across 3 companies. Residencia San Juan had a 3-party chain (construction → distributor → Aronlight). The system needs matching + fallback logic. |
| 5 | Pull customer's pricelist | Person looks up in Odoo | API reads assigned pricelist | System 80+ pricelists with different structures. The system interprets which rules apply. |
| 6 | Match products to catalog | Person searches one by one | AI + system match via 4 strategies | AI + System This is not one step. It's four different problems: Type A: SKU lookup (Metro de Madrid -- direct match). Type B: Attribute matching (APPACDM -- wattage + color temp + form factor, no codes). Type C: Cross-catalog (Residencia San Juan -- 18 iGuzzini products matched by specs to Aronlight equivalents). Type D: Intent parsing (Carolina -- product line names, typos, conditionals, accessory bundling). AI handles the matching. The system provides the cross-reference database, confidence scoring, and back-office confirmation loop. |
| 7 | Calculate the correct price | Person applies discount rules | System creates draft sale.order with customer's pricelist_id. Odoo computes price. System validates before sending. | System (code, not AI) Real test: Metro de Madrid totaled EUR 21,288.29 across 15 line items. Carolina's request needs both trade AND retail pricing. Odoo computes the base price via its own 80+ pricelist rules. Our system then validates: discount in expected range? No zero/negative lines? Total consistent with customer history? Odoo is the default, our code is the guardrail. |
| 8 | Check stock | Person checks Odoo | API reads product.product stock | System Straightforward if wired correctly. |
| 9 | Generate the proposal | Person assembles manually | AI formats from branded template | AI Formatting, language, layout. Works well. |
| 10 | Back-office reviews | Manual = final | Review queue: approve, edit, reject | System Your team needs an interface to review 140 proposals/day. With confidence scoring: high-confidence matches get one-click confirm, low-confidence get flagged for manual review. That's a web application. |
| 11 | Send proposal to customer | Person sends email | Auto-send on approval | System Branded templates, attachments, delivery tracking, bounce handling. |
| 12 | Create sale.order in Odoo | Person enters manually | API write-back | System Mapping products, quantities, pricelist, and customer correctly into Odoo's sale.order schema. Must be exact every time. |
| 13 | Run reliably at 700/week | N/A | Error handling, retries, logging, monitoring | System Error handling, retry logic, monitoring, alerts. At 700/week, things will break. The system catches and recovers automatically. |
Small implementation fee to cover the build (with a 100% guarantee -- you only pay it once there is a minimum viable product). The rest is pay per proposal generated. The more volume you push through the system, the lower the cost per proposal. Progressive tiers reward scale.
Every proposal the system generates and queues for your back-office review counts as one unit. Your monthly volume determines your tier, and that rate applies to all proposals that month.
AI model = 2-6 calls per proposal depending on type (parse email/image/Excel, match products, cross-reference, generate proposal). Cost varies significantly by email type: Type A (SKU lookup) ~EUR 0.10-0.15, Type B (image parsing) ~EUR 0.20-0.40, Type C (competitor cross-reference) ~EUR 0.30-0.80, Type D (conversational + dual output) ~EUR 0.25-0.60. EUR 0.25 is the blended average assuming a typical mix. The system is model-agnostic: we use the best available model for each task, and can switch providers as the market evolves. Infra = server, email service, monitoring, cross-reference database. EUR 100/month fixed, amortized at midpoint volume per tier.
| Tier | Monthly proposals | Rate | AI model | Infra | Total cost | Margin |
|---|---|---|---|---|---|---|
| Tier 1 | ~125 | EUR 4.00 | EUR 0.25 | EUR 0.80 | EUR 1.05 | EUR 2.95 (74%) |
| Tier 2 | ~375 | EUR 2.50 | EUR 0.25 | EUR 0.27 | EUR 0.52 | EUR 1.98 (79%) |
| Tier 3 | ~750 | EUR 1.50 | EUR 0.25 | EUR 0.13 | EUR 0.38 | EUR 1.12 (75%) |
| Tier 4 | ~1,500 | EUR 1.20 | EUR 0.25 | EUR 0.07 | EUR 0.32 | EUR 0.88 (73%) |
| Tier 5 | ~3,000 | EUR 0.80 | EUR 0.25 | EUR 0.03 | EUR 0.28 | EUR 0.52 (65%) |
| Proposals/mo | Monthly bill | Effective rate | Tier |
|---|---|---|---|
| 250 | EUR 813 | EUR 3.25 | Tier 1-2 |
| 500 | EUR 1,000 | EUR 2.00 | Tier 2-3 |
| 1,000 | EUR 1,350 | EUR 1.35 | Tier 3-4 |
| 2,000 | EUR 2,000 | EUR 1.00 | Tier 4-5 |
| 3,000 | EUR 2,400 | EUR 0.80 | Tier 5 |
At your current volume (~3,000 proposals/month): EUR 2,400/month at EUR 0.80/proposal (Tier 5). The more volume you push through, the lower the per-unit cost, and the smarter the cross-reference database becomes.
Between tiers: if your monthly volume sits between the ranges above, we calculate an average effective rate between the two adjacent tiers. Example: at 2,500 proposals the effective rate is EUR 0.90 per proposal.
Note: VAT is not included and will be added if applicable.
Prepay EUR 10,000 and every proposal costs EUR 0.65 instead of EUR 0.80.
| Standard (Tier 5) | Prepay | Saving | |
|---|---|---|---|
| Rate per proposal | EUR 0.80 | EUR 0.65 | 19% off |
| Monthly at 3,000 | EUR 2,400 | EUR 1,950 | EUR 450/month |
| Annual at 3,000 | EUR 28,800 | EUR 23,400 | EUR 5,400/year |
The EUR 10,000 is a credit balance. It gets consumed at EUR 0.65/proposal. At 3,000 proposals/month, it covers ~5 months. After the credit is used, you can top up again at the same rate or revert to standard pricing.
Our margin on prepay: EUR 0.65 - EUR 0.28 cost = EUR 0.37/proposal (57%). Lower than standard Tier 5 (65%), but the upfront cash covers build costs and locks in the client.
The tools to build this exist. Here's what they cost, with and without the people to make them work.
Assumes someone on your team already knows how to wire Claude API + Odoo XML-RPC + email infrastructure. No external developer.
| Item | Monthly cost | Notes |
|---|---|---|
| AI API credits | EUR 500-750 | ~3,000 proposals/month. Type A ~EUR 0.10, Type C/D ~EUR 0.30-0.80. Depends on model choice and email mix. |
| Server / VPS | EUR 50-100 | Runs the pipeline, email monitor, review queue |
| Email service (SMTP) | EUR 20-50 | Sending proposals at volume (SendGrid, Postmark, etc.) |
| Bare minimum monthly | EUR 570-900 | Tools only. No build cost. No maintenance. |
Realistic scenario: hire a developer or contractor to build the system, then maintain it.
| Item | Cost | Notes |
|---|---|---|
| UPFRONT (build the system) | ||
| Developer: Odoo + AI integration | EUR 10,000-25,000 | Freelance or agency. 2-4 months. Email parsing, Odoo connector, pricelist logic, review UI, proposal templates. |
| MONTHLY (keep it running) | ||
| API credits + infrastructure | EUR 570-900 | Same as bare minimum above |
| Developer maintenance | EUR 500-1,500 | 10-20 hours/month: bug fixes, Odoo updates, new edge cases, new product categories, pricelist changes |
| Probable monthly | EUR 1,070-2,400 | After the system is built |
| TOTALS | ||
| Year 1 | EUR 22,840-53,800 | Build + 12 months running |
| Year 2+ | EUR 12,840-28,800/year | Monthly costs only |
| With us | DIY (bare minimum) | DIY (probable) | |
|---|---|---|---|
| Upfront | EUR 3,750 (small implementation fee -- reimbursed if MVP doesn't ship) | EUR 0 * | EUR 10,000-25,000 |
| Monthly | EUR 2,400 (or EUR 1,950 prepay) | EUR 570-900 | EUR 1,070-2,400 |
| Year 1 | EUR 32,550 (or EUR 27,150 prepay) | EUR 6,840-10,800 * | EUR 22,840-53,800 |
| Year 2 | EUR 28,800 (or EUR 23,400 prepay) | EUR 6,840-10,800 * | EUR 12,840-28,800 |
| Who's responsible | Us | You | Your developer |
| Risk if it breaks | Our problem | Your problem | Depends on contract |
* Bare minimum assumes someone on the team can build and maintain the full pipeline: email monitor, multi-format parsing (text, images, Excel), AI API integration, four product matching strategies, cross-reference database, Odoo XML-RPC connector, 80+ pricelist logic, review queue UI, proposal templating, error handling, and monitoring. At 700/week across four different email types, this is not a weekend project. API costs updated to reflect actual per-type inference: image parsing and competitor cross-referencing cost 3-8x more than simple text parsing.
Small implementation fee: EUR 3,750 -- reimbursed in full if the MVP doesn't ship.
Covers the full system build: email integration, Odoo connector, Module 1b simple-order path, review interface, and proposal templates.
Internal pricing rationale: EUR 3,750 = 15.6% of EUR 24,000 annual subscription (Tier 5 @ 3,000 proposals/mo). Sits inside the Simple complexity band (10-20%) per the AdapttoAI pricing philosophy. Dropped from EUR 5,000 on the Apr 21 call because (1) Aronlight is first design partner, (2) Manuel asked for go-live trigger which shifts build-risk to us, (3) cancel-anytime removes the 12-month revenue floor -- compensated by a smaller upfront. Floor: do not go below EUR 3,500 without partner review. Apr 22 update: framing shifted from "paid only on go-live" to "small implementation fee, reimbursed if MVP doesn't ship" per Giuseppe. Net economics identical; reimburse language is psychologically stronger (money moves) and cleaner for Aronlight's AP.
Before we flip the MVP live (i.e., before the first invoice), we validate the system against your historical proposals. This is what makes the go-live trigger safe for both sides: you don't pay until the system reliably replicates the quotes your team has already been sending.
| What we need | Volume | Purpose |
|---|---|---|
| Past email requests | 50-100 | Cover all 4 types (A/B/C/D). Real inbound traffic from Aronlight + Contera. |
| Matched sent proposals | 1 per request | The proposal your team actually sent back. This is ground truth. |
| Customer + pricelist pairs | All customers in the corpus | Confirms which pricelist was applied on each proposal. |
| Metric | Threshold | What it measures |
|---|---|---|
| SKU match accuracy | ≥ 95% | Of the products in the historical proposal, how many does the system pick correctly? |
| Price accuracy | ≥ 98% | Line-level price match against the sent proposal (Odoo-delegated pricing, so this should be near-perfect). |
| Format parity | ≥ 90% | Does the output match Aronlight's proposal layout, language, and structure? |
| Escalation rate | 15-30% | How often the system flags for human review. Too low = over-confident. Too high = not useful yet. |
| Avg handling per proposal | ≤ 90 seconds | End-to-end: email parsed → proposal queued for review. |
Go-live gate: no first invoice issues until all five metrics pass on the backtest corpus.
Risk reversal: if we can't hit the gate, Aronlight pays EUR 0. You get to see the build work first, then decide.
Internal note: Raffaello offered the backtesting framework on the Apr 21 call. It converts "will this actually work?" from a theoretical discussion to a data-driven checkpoint. Corpus collection is Manuel's responsibility -- we need it before build kick-off. If Aronlight can't produce 50+ matched pairs, the backtest methodology degrades and we should flag it as risk before go-live.
| # | Item | Priority | Why |
|---|---|---|---|
| 1 | Sample historical requests + proposals: 50-100 matched pairs (inbound email + what your team sent back) | High | Used during the build to tune product matching and proposal format against what your team would have sent. The more pairs, the more accurate the system on day one. |
| 2 | Confirm email type distribution | High | What % of daily volume falls into each of the 4 types (SKU-based, description-only, competitor cross-reference, conversational). Drives system priorities. |
| 3 | Teams/WhatsApp channel access (for Module 1b) | Medium | Needed to wire the simple-order input path. Confirm which channel Aronlight prefers for the direct-entry workflow. |
Everything else has been resolved: Odoo version (18.0 Enterprise, confirmed), staging access (XML-RPC authenticated), catalog (4,325 products in Odoo), pricing structure (80+ pricelists explored via API), RMA assessment (module installed, decision: don't build). We have 4 real email samples covering all major types -- additional emails help but are no longer blocking.
We tested four real emails from your inbox against current AI models. AI can parse emails, match products, and generate text. That part works. But going from "AI parsed an email" to "correct proposal sent to the right customer at the right price" requires 13 steps, and AI alone handles 3 of them.
AI models are probabilistic. They give you the most likely answer, not the guaranteed correct one. For reading emails and generating text, that's fine. For 3,000 proposals a month with compound pricing rules, "most likely" is not acceptable.
Without a system enforcing guardrails, the AI could:
The system prevents all of this:
And because the system is independent from the AI model, you can swap models at any time without rebuilding anything. The system is the permanent asset. The AI model is replaceable.
| Task | Works? | How? |
|---|---|---|
| Parse a text email, extract product codes + quantities | Yes | Tested: Metro de Madrid. Works today. |
| Read an image and extract a table | Yes | Tested: APPACDM Sabrosa image. Vision models handle this. |
| Parse an Excel BOM with competitor products | Yes | Tested: iGuzzini spreadsheet. Extracted 18 products with full specs. |
| Interpret conversational requests with typos and conditionals | Partial | Tested: Carolina Portugal. Catches typos (V/W), but conditional logic ("if Berg works for bathroom, otherwise LUKE") needs system rules. |
| Match SKUs against a catalog | Yes | Direct lookup. 4,325 products fits in context. |
| Cross-reference competitor products by specs | Partial | Can compare specs. But needs the cross-reference database + back-office confirmation loop to be reliable. |
| Query/write Odoo data | Partial | Connectors exist. But field mapping, pricelist logic, and validation need engineering. |
| Generate a formatted proposal | Yes | Formatting, language, layout. Works well. |
Even if you connected an AI model directly to Odoo, you'd still need the system. Here's why:
AI models are built on statistical prediction. They give you the most likely answer, not the guaranteed correct one. For reading emails and generating text, "most likely correct" is fine. For pricing, it's dangerous.
Your 80+ pricelists have compound discount rules. "Lista PT 48% + Liquidos" means one thing. "Lista ES 60% + Netos - 6%" means another. A proposal for EUR 15,000 calculated wrong by 2% is EUR 300 off. Multiply that by 3,000 proposals/month. An AI model might get it right 95% of the time. That's 150 wrong proposals a month.
The system delegates pricing to Odoo itself. We create a draft sale.order with the customer's assigned pricelist, and Odoo applies its own 80+ discount rules deterministically. We never reimplement pricelist logic outside of Odoo. The AI reads the email and matches products. Odoo calculates the price.
But Odoo is the default, not the final word. Our code is the guardrail. Before any proposal leaves the system, deterministic validation code checks the result: is the discount within the expected range for this pricelist? Did any line come back at zero or negative? Does the total make sense for this customer's history? If Odoo has edge cases with specific pricelists (and with 80+ rules, it will), we add targeted checks for those. Month 1 we trust Odoo mostly. By month 3 we know exactly which pricelists have quirks and we've added specific overrides. The validation layer grows smarter with every quote.
Without a system, an AI model connected directly to your email and Odoo could:
The system enforces rules in code that the AI cannot bypass: no proposal leaves without human approval, no price is ever calculated by AI, no Odoo write happens without validation, every match below a confidence threshold gets flagged for review. These aren't suggestions to the AI -- they're hard constraints in the system architecture. The AI operates within boundaries the system defines.
AI models are evolving fast. Today Claude is the best for this kind of work. In 6 months, maybe Gemini is better at cross-referencing. In a year, maybe a new model processes images faster and cheaper. If your pipeline is built on top of a specific AI model, you'd have to rebuild when you switch.
Because the system sits between the AI model and Odoo, the AI model is a plug-in component. We swap models, you see no change. Your proposals keep flowing. Your cross-reference database stays. Your business rules stay. The only thing that changes is which engine processes the text.
You're investing in the system, not in any AI provider. The system is the asset that compounds -- it gets smarter with every quote, stores your cross-reference mappings, and encodes your business rules. The AI model is replaceable. The system is permanent.
In summary: There are three layers: the AI model (interchangeable, gets cheaper over time), the system (the orchestration layer we build and maintain -- the product), and Odoo (your data). The AI provides intelligence. The system makes it run accurately and reliably at scale: multi-format parsing, four matching strategies, the cross-reference database, deterministic pricing, Odoo integration, and ongoing accountability. You pay per output -- if it works, we both win. If it doesn't, you stop. And you're never locked into any AI provider.
At ~700 proposals/week (~140/day), with 30 minutes per proposal today:
We parsed four real emails from Aronlight's inbox. Not lab scenarios. Real requests with real complexity. They reveal four distinct types of quote request, each requiring different capabilities from the system.
Metro de Madrid (Oct 2025) -- 4-party email chain (Elecnor → N. Oses → LDV Lighting → Aronlight). PDF attachment with formal quote V25-2897. ~979 waterproof LED panels, EUR 25,758.
What Claude extracted in seconds: 5 product codes (LDV6812040NW, LDV6806020NW, LDV6815050NW + clip variants), exact quantities, unit prices (EUR 8.63-16.44), total with IVA, customer NIF, payment terms (pagare), quote validity (15 days), end project (Metro de Madrid Phase 1), custom modification (80cm cable + Schuko plug).
What needs engineering: 4 contacts across 3 companies -- which is the Odoo customer? Same SKU appears 3 times with different accessory bundles. "Cantidades exactas pendientes" means this is preliminary, not a firm order. Custom cable installation: is it a product in Odoo or a manual service line?
Matching: SKU lookup Value: Speed. The data is structured. Any system adds value here. Our margin on this type is lowest because it's the easiest to replicate.
APPACDM Sabrosa (Apr 2026) -- Tiago Alexandre Silva, commercial dept AVAC. Energy efficiency upgrade for a disability support association building. Quantity table embedded as an image in the email. Quote deadline: Apr 13. Portuguese.
What Claude extracted from the image:
| Item | Description (no product codes) | Qty |
|---|---|---|
| Ilum 1 | Aron 15W KAYA 4000K | 22 |
| Ilum 2 | Painel Quadrado Superficie Aron 12W 6000K | 200 |
| Ilum 3 | Painel Aron Light 40W 6500K | 172 |
| Ilum 4 | Downlight LED 20w | 15 |
What needs engineering: No product codes at all. "Aron 15W KAYA 4000K" must be fuzzy-matched against 4,325 products by product line + wattage + color temp. "Downlight LED 20w" has no brand -- could match dozens of products. The quantity map is an image, not searchable text.
Matching: attribute search Value: Product knowledge. The system replaces the person who knows that "KAYA 4000K 15W" maps to ILAR-KAYA-15W-40K. When that person is sick or leaves, the knowledge stays.
Residencia San Juan del Puerto (Apr 2026) -- 3-party chain: ACSA/Sorigué (construction) → Macinfor Andalucía (lighting distributor) → Patricia Gutierrez at Aronlight. Senior residence in Huelva. Excel BOM attached. 90% DALI protocol. Original spec: iGuzzini "o equivalente."
What Claude extracted from the Excel: 18 iGuzzini products + 3 emergency items. 527 luminaires + 160 emergency = 687 total units. Each item has: iGuzzini reference code, wattage, lumens, color temp (3000K), CRI, DALI version, IP rating, dimensions, optics type, and iGuzzini product page URL. Key items: 223x Easy ø105 (QF52.01), 89x Easy Space Square (RI44.D8), 54x Laser Circular (Q810.47). Multi-component items with compound codes (P336.47+MY13.024).
What needs engineering: The customer doesn't want Aronlight products. They want iGuzzini equivalents. Every line item needs cross-referencing: match iGuzzini specs (wattage, lumens, CRI, DALI, IP, dimensions, optics) against Aronlight's catalog. Multi-component items need both luminaire + driver/accessory matched. DALI-2 compatibility is a hard filter. Items with no Aronlight equivalent must be flagged.
Matching: cross-catalog Value: Competitive intelligence. Every confirmed cross-reference builds a mapping database. After 6 months, Aronlight has a complete iGuzzini-to-Aronlight mapping that exists nowhere else in structured form. The system gets faster and more accurate with every quote.
Carolina Portugal, Architect (Mar 2026) -- Follow-up to a phone call with Margarida Silva. Residential project. Carolina references product lines by name after seeing samples. Requests trade AND retail pricing as separate proposals. Portuguese.
What Claude extracted:
| Item | What she wrote | Qty | Challenge |
|---|---|---|---|
| Recessed tracks | calhas de embutir 2m brancas | 17 | Product line clear |
| Spots | focos 12v 2700K brancos | 22 | "12V" -- likely 12W (typo) |
| Prada spots | focos prada 20v 3000K brancos | 12 | "20V" -- likely 20W (typo) |
| Berg Trimless | focos berg trimless 9v 2700K | 50 | "9V" -- likely 9W (typo) |
| CB VIG spots | focos CB VIG 2700K brancos | 15 | Product line reference |
| Bathroom spots | iguais aos berg para casa de banho, se não os LUKE | 18 | Conditional: if Berg is bathroom-rated, use it. If not, use LUKE. |
| Floor spots | OTTO focos de pavimento | 5 | Product line clear |
| Wall sconces | cube branco + lupo wall + cube preto | 12 | "Cube preto -- caso dê para exterior?" = embedded question, not an order |
What needs engineering: Three probable typos (V instead of W). Conditional logic ("if Berg works for bathroom, use it; otherwise LUKE"). An embedded question ("does black Cube work outdoors?") that isn't an order line. "Tudo com as respectivas lâmpadas e aros" means every fixture needs matching lamp + trim ring auto-bundled. Two separate outputs required: trade price (profissional) and retail (PVP). Context from a prior phone call that the system has no record of.
Matching: intent parsing Value: Expertise replacement. Only the most experienced staff can handle this email today. The system catches typos, resolves conditionals, auto-bundles accessories, flags questions, and generates both price tiers. This is the quote type that currently takes 45-60 minutes or gets delayed.
| Type | Input format | Matching strategy | Judgment calls | Value delivered |
|---|---|---|---|---|
| A | Text + PDF with SKUs | Direct lookup | Customer identification, pricelist selection | Speed |
| B | Image with descriptions | Attribute matching (wattage, color temp, form factor) | Fuzzy matching, confidence scoring, generic items | Product knowledge |
| C | Excel BOM with competitor codes | Cross-catalog (specs to specs) | Multi-component items, DALI compatibility, no-match flagging | Competitive intelligence |
| D | Conversational text | Intent parsing + conditionals | Typo correction, conditional logic, embedded questions, accessory bundling, dual pricing | Expertise replacement |
The system gets better with every quote. Every confirmed product match, every cross-reference correction, every typo pattern the back-office fixes trains the system. After 6 months of processing quotes:
Month 1, the back-office corrects the system often. Month 6, the system corrects itself. The knowledge that today lives in three people's heads becomes a permanent, growing asset that belongs to Aronlight.
The key insight: if every email looked like Type A (clean SKUs), a smart spreadsheet macro could do half the job. The reason you need 9 people doing quotes is precisely because most emails look like Type B, C, and D. The harder the email, the more value the system adds.
We authenticated via XML-RPC and explored the full staging database.
| What | Count | Key Insight |
|---|---|---|
| Products | 4,325 | 1,605 with zero stock. Clean SKU codes (ILAR-XXXXX). |
| Pricelists | 80+ | Discount-based: "PT 48%", "PT 52% + Liquidos", "ES 60% + Netos". Each customer assigned one. |
| Customers | 1,394 | 503 active last 90 days. 891 dormant. |
| Sale orders | 9,594 | ~2,700/month in 2026. Active system. |
| Invoices | 77,168 | 6,633 credit notes. |
| Incidents (Excel) | 1,380 | 98% logistics. Carrier responsible in 562 cases. |
| RMA module | Installed | 3 operations configured. 0 real records used. |
| Incoming email | NOT configured | No fetchmail server. Emails don't flow into Odoo. |
The pricing structure is more sophisticated than we assumed. It's not "90% Odoo + 10% manual." It's 80+ pricelists with discount tiers, and every customer is assigned to one. "Lista PT 48% + Liquidos" means 48% discount on the base price, plus liquid/special product rules. The logic is already in Odoo. We just need to pull the right pricelist per customer via API.
Three independent layers. Each can evolve without breaking the others.
Why this matters: The AI model is a commodity that gets cheaper and better over time. Odoo is your existing system. The value -- and what you're paying for -- is Layer 2: the system in the middle that coordinates everything. If a better AI model emerges, we switch. If you change ERP systems, we adapt the connector. You're not locked into any AI provider or into us building on a specific technology.
Odoo 18.0 Enterprise on Odoo.sh. We connect via XML-RPC (standard, stable since Odoo v8). Note: XML-RPC is deprecated for removal in Odoo 22 (fall 2028). The replacement JSON-2 API ships with Odoo 19. Our connector uses an abstraction layer so swapping protocols is a single-module change -- no rebuild required.
| Direction | Odoo Model | Purpose |
|---|---|---|
| Read | product.product | Catalog, prices, stock levels |
| Read | res.partner | Customer identification, assigned pricelist |
| Read | product.pricelist | 80+ discount tiers |
| Read | sale.order | Order history (for reactivation) |
| Read | stock.picking | Delivery data (for carrier claims) |
| Read | account.move | Invoices and credit notes (for carrier claims) |
| Write (MVP) | sale.order | Create draft quotation with pricelist_id. Odoo computes line prices. Back-office reviews before confirming. |
| Write (v3) | sale.order | Auto-confirm clean proposals. Create sale.order from approved drafts. |
Integration tested. We successfully authenticated to staging via XML-RPC, queried all key models, and confirmed the data structure. The API works. The data is there.
These modules are not in the signed scope. They reuse the Odoo connector, pricelist logic, and review interface we build for quote generation, so the incremental build cost is low. Pricing when activated: same transaction-based principle as Module 1 -- per claim drafted, per outreach message generated.
The problem today: 1,380 incidents tracked in Excel since 2021. Carrier is responsible in 562 cases. But claims were only filed in 349 of them. 230 carrier-responsible incidents with no claim filed. That's money left on the table. Skynet alone: 1,001 incidents, EUR 6,218 in tracked costs.
Filing a claim means: looking up the delivery data, writing the claim in the carrier's specific format, submitting it, tracking the response. It's tedious. So the team skips it 40% of the time.
The problem today: 891 of 1,394 customers haven't ordered in 90+ days. Nobody runs a systematic report. Nobody sends personalized outreach. Customers drift away silently.
| Deal state | Verbal yes from Manuel Vidigal (CEO). Asked for the document to review with his team. |
| Call date | Apr 21, 2026. Attendees: Giuseppe Belpiede, Raffaello Starace, Manuel Vidigal. |
| Team review | Friday, Apr 24, 2026 |
| Proposal expiry | Saturday, Apr 25, 2026 |
| Item | V5 | V6 | Trigger |
|---|---|---|---|
| Implementation fee | EUR 5,000 at signing | EUR 3,750 paid on go-live | Manuel -- "pay only when system is live" |
| Monthly billing | Transaction-based (already) | Transaction-based (no change) | N/A |
| Contract term | 12-month minimum implied | Cancel anytime, no minimum | Manuel -- "zero risk, no lock-in" |
| Module scope | Module 1 (Quote Gen) only | Module 1 + Module 1b (Simple-Order path + Quote Recycling) | Manuel -- "simple proposals should be automatic" + "recycle proposal #12345" |
| Quality gate | Implicit | Backtesting methodology formalized with 5 metrics | Raffaello offered on call |