Most business questions get answered the same way: someone asks the question, an analyst pulls the data, the analyst formats a chart, the question is answered three days later. Natural language queries collapse the cycle. Ask the question in plain English, get an answer in seconds, grounded in live Odoo data.
This guide walks through what natural language querying means in an Odoo context, how to set it up safely, and the operational practices that determine whether the assistant becomes a trusted tool or a confidence-eroding source of wrong answers.
What natural language queries mean in practice
The pattern is straightforward:
- User types a question: "What were our top 10 selling products in March?"
- An AI service (typically GPT-4-class or Claude-class) translates the question into a structured query — either SQL against the Odoo database or a sequence of ORM calls.
- The query runs.
- Results are formatted as a table, chart, or natural-language summary.
The user never writes code, never opens a report builder, never asks an analyst. For organizations where business questions are bottlenecked by analyst availability, this is a step-change in operational speed.
What it's good for
- Ad-hoc analysis: "How many customers ordered more than €5,000 last quarter?"
- Drill-downs from dashboards: "Show me the orders behind that revenue spike on April 14."
- Operational lookups: "What's the status of order SO-2026-1234?"
- Reporting prototyping: "Which categories had the highest margin last year?" — once the question is useful, formalize it as a report.
What it's not good for
- Mission-critical reports where wrong answers are unacceptable. Use traditional BI for those.
- Highly multi-step analysis (cohort retention, statistical modeling). LLMs struggle here; a notebook is faster.
- Questions where the answer depends on operational definitions ("What is our churn rate?"). Define the metric, build a report, don't rely on the AI's interpretation.
Setup options
Three paths to NL queries with Odoo:
Path 1: Odoo's native AI features
Odoo has been steadily adding AI-assisted features. Recent versions include AI-powered search and an assistant that answers questions about Odoo data using OpenAI's API. Configure under Settings ‣ Technical ‣ AI Assistant (in versions that support it). Provide your OpenAI API key, configure the access scope, and the feature is available in the relevant apps.
Path 2: External BI tool with NL features
Modern BI tools (ThoughtSpot, Sigma, Hex, Domo) include natural language interfaces. They connect to your Odoo database (read replica recommended) and provide a polished experience. Setup involves creating a database read replica, exposing it to the BI tool, and configuring the semantic layer.
Path 3: Custom integration
For teams comfortable with engineering, build a thin layer: a chat UI that calls an LLM with Odoo schema metadata and example queries, generates SQL, executes against a read replica, and returns formatted results. Open-source frameworks (LangChain, LlamaIndex) handle most of the plumbing.
Schema documentation: the work that determines accuracy
An LLM generating queries against your Odoo database is only as accurate as its understanding of your schema. Out of the box, it knows the standard Odoo models — sale.order, res.partner, product.product. It doesn't know:
- That your custom field
x_customer_segmentonres.partneris what "VIP customer" means in your business. - That your
x_promo_codefield onsale.orderidentifies promotional sales. - That "return" in your business specifically means a sale order in state
cancelwith a linked credit note.
Schema documentation provides this context to the LLM. The minimum:
- Table descriptions — what each model represents.
- Column descriptions — what each field means, including custom fields.
- Glossary — business terms mapped to data fields.
- Example queries — common questions with their correct SQL.
The example queries do the most work. Five well-chosen examples teach the LLM more than 200 column descriptions.
Common prompt patterns that work
Once the assistant is set up, users develop patterns that get good answers consistently. Coach the team on these.
Specify the time period
Bad: "What are our top customers?"
Good: "What are our top 10 customers by revenue in Q1 2026?"
Without a time bound, the LLM picks one (often "all time" or the current month) and the answer is rarely what was meant.
Specify the metric
Bad: "How is product X performing?"
Good: "What was the sales volume and average margin for product X over the last 90 days?"
"Performing" is a metric the LLM has to invent. Naming the metric removes ambiguity.
Specify the granularity
Bad: "Show me sales over time."
Good: "Show me weekly revenue from the apparel category over the last 6 months, broken out by sub-category."
Time series questions need granularity (daily, weekly, monthly) and dimensions (which categories, which warehouses, which channels).
Filter explicitly
Bad: "What returns are pending?"
Good: "List all customer returns in state 'received' but not yet 'refunded' for orders shipped in the last 30 days."
State machines have nuances. Naming the states explicitly avoids the LLM picking the wrong one.
Operational guardrails
NL queries are powerful and risky. The risks:
Data exposure
An NL assistant with access to res.partner can reveal customer PII to anyone who can ask a question. Two safeguards:
- Scope by user. The assistant should run with the asking user's permissions — not a service account with full access.
- PII redaction at output. Even when the underlying query returns PII, the response can mask sensitive fields unless the user has explicit permission.
Wrong answers presented as right
LLMs are confident even when wrong. Mitigate:
- Show the generated query. The user can verify the query matches their question. Power users will spot errors.
- Show the row count. If the user expected ~100 rows and got 10,000, something is off — and they should investigate before acting.
- Caveat in the prompt. Always present results with "based on data through <date>" and "interpreted as <query summary>."
Performance impact on the database
Bad LLM-generated queries can be slow — full table scans, N+1 patterns, missing indexes. Mitigate:
- Run against a read replica, not the production OLTP database. Slow queries don't slow the storefront.
- Set query timeouts. 30 seconds is plenty for most analytical questions.
- Monitor query patterns and add indexes to support common ones.
When NL queries don't replace traditional reports
Three scenarios where you still want a traditional report or dashboard, even with great NL capabilities:
1. Recurring reports the same people consume
If the executive team looks at the same 4 metrics every Monday, build them a Monday morning dashboard. They shouldn't have to re-query each week. Build it once; re-run automatically.
2. Reports requiring complex business logic
Multi-step calculations (cohort retention, lifetime value, customer segmentation) involve nuances NL can't reliably handle. Build them in BI tools or as Odoo custom reports where the logic is auditable.
3. Reports that drive operational decisions
Reports that trigger actions — "if inventory drops below X, do Y" — should be deterministic. The NL interface might be how the operator first explores the question; the production report should be conventional.
Common pitfalls
1. Going live without schema documentation
The assistant works "well enough" in demo, then produces wrong answers in production for any question that touches custom fields or non-obvious business logic. Document the schema before opening the assistant to users.
2. Granting write access
An NL assistant with write access can update, delete, or create records. The first time someone asks "set all open quotations to confirmed," you'll wish you hadn't. Read-only, always.
3. Not showing the generated query
Users trust answers that look authoritative. Without the query visible, they can't catch wrong answers. Always surface the query.
4. Treating it as a replacement for analysts
Analysts do more than write SQL — they ask clarifying questions, define metrics, validate data. NL queries don't replace that. Position the assistant as augmentation, not replacement.
5. Failing to monitor cost
LLM API calls cost money. A noisy chat where users iterate 10 times to refine a query can ring up hundreds of euros per day in API costs. Track per-user usage and set spending caps.
Reference notes
Sources verified against Odoo 19.0 documentation and standards bodies. Use these to confirm anything before applying it to your environment.
- Odoo AI features — Odoo 19.0 release notes — native AI assistant configuration in Odoo 19
- OpenAI API documentation — GPT-4-class models with text-to-SQL capability
- Anthropic Claude API documentation — Claude API for SQL generation and summarization
- Metabase — open-source BI — BI tool with NL query (Metabot)
- LangChain — LLM orchestration — framework for custom NL-query pipelines
Frequently Asked Questions
Which LLM works best for natural language queries on Odoo?
For text-to-SQL workloads as of 2026, GPT-4o, Claude Sonnet 4.x, and Gemini 2.x models all perform well. The differences in accuracy on standard benchmarks are small; cost and latency vary more. For Odoo specifically, the LLM matters less than the schema documentation and example queries you provide. Start with whichever your platform supports natively.
Can the AI assistant write to the Odoo database?
It can, but it shouldn't. Read-only access is the right default for any NL query interface. Write operations need explicit workflows with confirmation steps, audit trails, and rollback paths — none of which an LLM provides reliably. If you want AI-driven automation that writes to Odoo, build it as a separate workflow with explicit triggers and approvals, not as a chat interface.
How accurate are natural language queries against Odoo?
With well-documented schema and 10–20 example queries, expect in well-tuned setups, accuracy of roughly 80–90% on first-pass queries for typical retail questions. Without documentation, first-pass accuracy degrades sharply — high enough to feel useful, low enough to mislead. Accuracy improves with usage: reviewing wrong answers and adding them as examples (or correcting the schema docs) compounds.
Does this expose customer data to the LLM provider?
It depends on architecture. If the LLM generates SQL and the SQL runs on your infrastructure, only the schema and example queries are sent to the LLM provider — not customer data. If the architecture sends raw query results back through the LLM for summarization, customer data does pass through the provider. Choose architectures that minimize data exposure, and verify your provider's data handling policies (zero-retention modes are widely available).
How much does it cost to run a natural language query interface?
Cost has two parts. LLM API: typically €0.01–€0.10 per query depending on the model and prompt size. A team of 10 users asking 20 questions per day costs ~€10–€100/month. Infrastructure: read replica database (€20–€200/month), chat UI hosting (€10–€50/month). Total for a small team is €50–€500/month. For larger deployments, LLM cost dominates and scales with usage.
Can I build an NL interface that works for all teams in my company?
Yes, but expect to scope per team. Sales asks different questions than warehouse, which asks different questions than finance. Each team benefits from a domain-specific interface tuned with their schema docs and example queries. A single one-size-fits-all interface ends up generic and less useful than tuned per-team versions.