Aronlight — Open Questions for Ricardo

The agent pre-filters catalog search by Odoo category. Products with no category assigned (UNCATEGORIZED) are completely invisible to semantic search — they can only be found when a customer writes the exact Aronlight SKU. Evidence from eval corpus run 2026-07-01 (13 real RFQ cases).

Tier 1 — HIT on direct SKU in multiple real RFQs, but MISS when customer describes by spec:

Tier 2 — quoted by rep as correct match, never surfaced by the system (case #44):

Action required: assign an Odoo product category to each SKU above. The category name determines which search bucket the agent uses (e.g. "Painéis LED" → PANELS, "Projetores" → SPOTLIGHTS, "Armaduras Emergência" → EMERGENCY, "Perfis Alumínio" → PROFILES). Without a category, the agent will miss these products on every spec-based RFQ regardless of how well the rest of the system works.

Priority: HIGH — 15 products actively quoted by reps but invisible to the agent. Each one is a guaranteed MISS on any spec-based search.

ARONLIGHT ESPAÑA SL is the single largest source of proposals in staging: 796 proposals in April-June 2026 (265/month), 90% conversion, €511K. These are internal Portugal→Spain requests, not external clients — they show up as a client because each request creates a sale.order in Odoo PT.

People we know: jordi.marco@aronlight.es, samuel.delvalls@aronlight.es, jose.moreno@aronlight.es. Full workflow is not mapped.

Top external clients by proposal volume (Apr-Jun 2026):

The goal of the RFQ agent is to centralise requests into a structured consultation flow. We need to understand the current state before designing the new one.

The matching engine needs hard cutoffs. Proposed values below based on Jun 2 call + industry practice. Please confirm or adjust each row.

Rule 1 logic: sum(length_m × W/m per SKU) × 1.20 → pick smallest PSU that covers it. W/m values calculated from Odoo catalog (2026-06-20) — please confirm or correct:

230V strips (SlimStrip AC, Project Strip 230V AC): Rule 1 does NOT fire. These products say "230V AC" in the product name and run direct from mains — no PSU needed. Confirmed from Odoo catalog.

Still needed: any strip SKUs missing from this table (e.g. ILAR-01404 COB PRO — no clear length in name), and confirmation these W/m values are correct.

In the Alfilux proposal (ORCLB2600497), bundles are priced with a single "DVDI" placeholder line at full price, and all sub-components listed at €0.00001. Examples: IT05 (CONJUNTO PERFIL MICRO 38 + FITA LED 14.4W) and IT16 (CONJUNTO PERFIL DELTA SPM20).

"DVDI" is not a product reference — it is an Alfilux-internal pricing code meaning "no direct equivalent / bundle." The agent currently cannot parse this structure.

• (a) When we see a DVDI-priced bundle, should the agent match the sub-components individually and build the Aronlight equivalent? Or treat the whole block as a single custom line?
• (b) Is "DVDI" specific to Alfilux, or do other distributors use the same convention?
• (c) For IT05 (LED strip profile bundle), the correct response required summing individual run lengths from a note field and sizing PSUs from that total. Is this the standard approach for all LED strip bundles from distributors?

Before we can build routing logic, we need to map who in the Aronlight team handles each step.

Full workflow still unknown — questions below:

Blocks routing design and @aronlight.es sender detection (case 17). Needed before we decide where the agent sits in the workflow.

When an email arrives with an empty body ("ver anexos") and the attachment is unreadable (corrupted, expired link, wrong format):

Or should the team always be notified so they can follow up personally?

Some RFQs (e.g. case #44, Alfilux with Delta/Onlight/Drees products) contain only competitor brand codes where Aronlight carries the category but not the brand. The agent always returns a suggestion for every line — all flagged needs_review — but the rep must dismiss each one individually. For a 50-item cross-brand RFQ this creates significant friction.

Two options:

• Option A — Suppress: when no confident equivalent is found, return "no equivalent found" and leave the line blank. Rep fills manually.
• Option B — Flag: always show the best candidate found, clearly marked "requires verification — competitor brand not in catalog." Rep uses it as a starting point.

• (a) For a cross-brand RFQ like the Alfilux example, does Flávio prefer to start from a blank line (Option A) or a flagged suggestion he can reject (Option B)?
• (b) Is there a confidence threshold? E.g. show when ≥70% confident, suppress below?
• (c) When Aronlight carries zero equivalent in a product category (e.g. a specific driver brand not stocked), should the agent flag as "catalog gap" or leave blank?

Priority: HIGH — determines whether we build batch-dismiss UX or suppression logic. Case #44 (50 items, all cross-brand) is the representative example.

A proportion of RFQs from distributors (e.g. Alfilux, Victor Silva) arrive as: "Em anexo, enviamos uma proposta da [Brand] — é possível dar-nos o equivalente?" The email body contains no project description, no room types, no installation context. All product information is in the PDF attachment.

This pattern makes every context-based matching improvement irrelevant — installation_context is always "unknown" for this RFQ type.

• (a) What percentage of Aronlight's inbound RFQs are distributor "equivalent" requests with no project context?
• (b) For these RFQs, what is the correct agent behaviour: pure spec-for-spec substitution (match on wattage, IP, CCT only), or flag missing context and ask the distributor to provide it?
• (c) Do distributors ever provide context on request, or is it typical to expect a straight equivalent without discussion?
• (d) For distributor RFQs, does Flávio still apply application-based overrides (IP uprating, CCT change) — or is it always a strict spec-for-spec match?

Case 20 (Voltel, 2026-06-15) showed that real quotes include stock alerts inline: "Artigo indisponível — previsão de entrega: 13/7/26." The agent must replicate this — silently quoting an out-of-stock product is worse than not quoting it.

Without these answers, v1 will either skip the alert entirely (silently quoting unavailable stock) or block too aggressively.

Affects every quote, not just out-of-stock cases — the agent needs to know what the in-stock case looks like too.

Every Aronlight orçamento today carries 3 PT-tax-law-required elements that v1 must preserve when the agent writes back to Odoo (or generates a proposal directly). Example from Voltel OR 2026/13707:

Affects every quote — wrong handling = legal exposure.

Cross-referencing 14 real proposals (190 SKU lines, June 2026) against Odoo catalog.json reveals a consistent pattern: the unit price shown on many proposals is significantly different from the Odoo list_price for the same SKU — even before any discount column is applied.

Priority: HIGH — the agent cannot generate correct quotes without knowing which pricelist to pull per client. This affects every line of every quote.