After implementing Odoo for 50+ companies, we noticed a pattern that bothered us. We would spend months setting up a system, migrating data, training users, and deploying everything. Six months later, the CEO - the person who signed off on the project - would still ask their assistant to pull numbers from Odoo. They never logged in themselves. Not because the system was bad, but because opening a browser, navigating to the right menu, setting filters, and reading a dashboard is too much friction when you just want to know last month's revenue.
This isn'tan Odoo-specific problem. It happens with SAP, with Microsoft Dynamics, with every ERP. The people who need data the most - executives, founders, managers on the go - are the ones least likely to sit in front of a desktop application and click through menus. They want answers, not interfaces.
We started with a simple prototype in late 2025. A Telegram bot that could connect to an Odoo instance and answer questions in natural language. The first version used basic keyword matching - if you typed 'revenue', it would pull the total from account.move. It was crude but the reaction from our clients was immediate. The CEO of a manufacturing company told us he checked his numbers more in the first week with the bot than he had in the previous quarter using the Odoo dashboard.
The real breakthrough came when we integrated Claude as the AI backbone. Instead of rigid keyword matching, users could ask questions naturally: 'How many units of SKU-4521 did we ship last week?' or 'Which sales rep had the highest margin in Q1?' The AI parses the intent, maps it to Odoo model queries, fetches the data via XML-RPC, and formats a human-readable response. It handles follow-up questions with context, so you can ask 'What about Q2?' and it knows you'restill talking about sales rep margins.
Choosing Telegram as the interface was deliberate. We considered building a custom mobile app, a web dashboard, a Slack integration. But our clients are predominantly in the Middle East and CIS region, where Telegram is the default business communication tool. People already have it open all day. There is zero app installation, zero onboarding friction. You add the bot, authenticate once, and start asking questions.
The technical architecture went through three iterations. Version one was a monolith - bot, AI, and Odoo integration all in one Node.js process. It worked for demos but was impossible to scale. Version two split into microservices but introduced too much complexity for our small team. Version three - what we run in production - is a pragmatic monorepo with Grammy.js for the Telegram bot, Fastify for the API layer, and Prisma for our own database. Not microservices, not a monolith, just sensible separation within one deployable unit.
One thing that surprised us was how much work goes into schema detection. Every Odoo instance is different. Clients add custom fields, install different modules, use different naming conventions. Our bot needs to understand that client A calls their product field 'x_brand' while client B calls it 'product_brand_id'. We built an automatic schema profiling system that reads the client's Odoo metadata on first connection and maps their specific field names to our standard query templates.
Pricing was another lesson. We initially planned a simple per-user model, but enterprise clients wanted predictable costs while small businesses wanted low entry points. We ended up with four tiers: a 14-day Free trial for testing (1 user, 20 queries, all core reports), Starter at $39/month for small teams (3 users, 150 queries per month, all 43 reports, 4 scheduled reports), Pro at $149/month for growing companies (10 users, 500 queries per month, all reports plus MRP, 15 scheduled reports, conversation memory, priority support), and Enterprise with custom pricing for larger organizations (unlimited users, enterprise tools, on-premise or VPN deployment, custom tools defined in YAML, 99.9% SLA, dedicated account manager). The key insight was that query volume, not user count, is the right pricing axis for an AI product where each query has a real compute cost.
The hardest engineering problem was not the AI or the Odoo integration - it was handling Odoo's access rights correctly. When a user asks 'Show me all employee salaries', the bot needs to respect the same access rights that Odoo would enforce if that user logged in directly. We solve this by running queries through a service account with carefully scoped permissions, but it means some queries return 'You don't have access to this data' - which is correct behavior, not a bug.
We also learned that AI hallucination is a real risk when dealing with business data. If the bot confidently states that Q1 revenue was $2.3M when it was actually $2.1M, that'sworse than no answer at all. We mitigate this by never letting the AI generate numbers - it only formats and explains data that comes directly from Odoo queries. The AI writes the narrative, but every number in the response traces back to an actual database record.
Six months after launch, we'veclients in manufacturing, education, retail, and professional services using the bot daily. The average client sends 15-20 queries per day, mostly from mobile during non-office hours - exactly the use case we designed for. The most popular queries are financial summaries, inventory levels, and sales pipeline status.
What is next: we are building a proactive alerts system. Instead of waiting for users to ask questions, the bot will monitor key metrics and notify them when something needs attention - inventory below threshold, overdue invoices past a certain amount, sales targets at risk. The goal isn'tjust to answer questions but to make sure the right questions get asked in the first place.