Nach der Implementierung von Odoo fuer ueber 50 Unternehmen fiel uns ein Muster auf, das uns stoerte. Wir verbrachten Monate mit der Einrichtung eines Systems, der Datenmigration, der Benutzerschulung und der Bereitstellung. Sechs Monate spaeter bat der CEO - die Person, die das Projekt genehmigt hatte - immer noch seinen Assistenten, Zahlen aus Odoo zu ziehen. Er loggte sich nie selbst ein. Nicht weil das System schlecht war, sondern weil es zu viel Aufwand ist, einen Browser zu oeffnen, zum richtigen Menue zu navigieren, Filter zu setzen und ein Dashboard zu lesen, wenn man einfach nur den Umsatz des letzten Monats wissen will.
Das ist kein Odoo-spezifisches Problem. Es passiert mit SAP, mit Microsoft Dynamics, mit jedem ERP. Die Personen, die Daten am dringendsten benoetigen - Fuehrungskraefte, Gruender, Manager unterwegs - sind diejenigen, die am wenigsten wahrscheinlich vor einer Desktop-Anwendung sitzen und durch Menues klicken. Sie wollen Antworten, keine Oberflaechen.
Wir begannen Ende 2025 mit einem einfachen Prototyp. Ein Telegram-Bot, der sich mit einer Odoo-Instanz verbinden und Fragen in natuerlicher Sprache beantworten konnte. Die erste Version verwendete einfaches Keyword-Matching - wenn man 'Umsatz' eingab, zog er die Summe aus account.move. Es war rudimentaer, aber die Reaktion unserer Kunden war sofort da. Der CEO eines Fertigungsunternehmens sagte uns, er habe in der ersten Woche mit dem Bot oefter seine Zahlen geprueft als im gesamten vorherigen Quartal mit dem Odoo-Dashboard.
Der wirkliche Durchbruch kam mit der Integration von Claude als KI-Backbone. Anstelle von starrem Keyword-Matching konnten Benutzer Fragen natuerlich stellen: 'Wie viele Einheiten von SKU-4521 haben wir letzte Woche verschickt?' oder 'Welcher Vertriebsmitarbeiter hatte die hoechste Marge in Q1?' Die KI analysiert die Absicht, ordnet sie Odoo-Modellabfragen zu, ruft die Daten ueber XML-RPC ab und formatiert eine fuer Menschen lesbare Antwort. Sie bearbeitet Folgefragen mit Kontext, sodass man 'Was ist mit Q2?' fragen kann und sie weiss, dass es immer noch um Vertriebsmitarbeiter-Margen geht.
Die Wahl von Telegram als Oberflaeche war bewusst. Wir haben den Bau einer eigenen mobilen App, eines Web-Dashboards und einer Slack-Integration in Betracht gezogen. Aber unsere Kunden befinden sich ueberwiegend im Nahen Osten und in der GUS-Region, wo Telegram das Standard-Geschaeftskommunikationstool ist. Die Leute haben es schon den ganzen Tag geoeffnet. Es gibt keine App-Installation, keine Einarbeitungshuerde. Man fuegt den Bot hinzu, authentifiziert sich einmal und stellt Fragen.
Die technische Architektur durchlief drei Iterationen. Version eins war ein Monolith - Bot, KI und Odoo-Integration in einem einzigen Node.js-Prozess. Es funktionierte fuer Demos, war aber unmoeglich zu skalieren. Version zwei wurde in Microservices aufgeteilt, fuehrte aber zu viel Komplexitaet fuer unser kleines Team. Version drei - was wir in der Produktion betreiben - ist ein pragmatisches Monorepo mit Grammy.js fuer den Telegram-Bot, Fastify fuer die API-Schicht und Prisma fuer unsere eigene Datenbank. Keine Microservices, kein Monolith, einfach sinnvolle Trennung innerhalb einer bereitstellbaren Einheit.
Was uns ueberraschte, war der enorme Aufwand fuer die Schema-Erkennung. Jede Odoo-Instanz ist anders. Kunden fuegen benutzerdefinierte Felder hinzu, installieren verschiedene Module, verwenden unterschiedliche Namenskonventionen. Unser Bot muss verstehen, dass Kunde A sein Produktfeld 'x_brand' nennt, waehrend Kunde B es 'product_brand_id' nennt. Wir haben ein automatisches Schema-Profiling-System gebaut, das beim ersten Verbindungsaufbau die Odoo-Metadaten des Kunden liest und seine spezifischen Feldnamen auf unsere Standard-Abfragevorlagen abbildet.
Die Preisgestaltung war eine weitere wichtige Lektion. Ursprünglich planten wir ein einfaches Modell pro Benutzer, aber Enterprise-Kunden wollten vorhersehbare Kosten, während kleine Unternehmen niedrige Einstiegspunkte benötigten. Wir entschieden uns schließlich für vier Stufen: eine 14-tägige kostenlose Testversion (1 Benutzer, 20 Abfragen, alle Kernberichte), Starter für $39/Monat für kleine Teams (3 Benutzer, 150 Abfragen pro Monat, alle 43 Berichte, 4 geplante Berichte), Pro für $149/Monat für wachsende Unternehmen (10 Benutzer, 500 Abfragen pro Monat, alle Berichte plus MRP, 15 geplante Berichte, Konversationsgedächtnis, Priority Support) und Enterprise mit individueller Preisgestaltung für größere Organisationen (unbegrenzte Benutzer, Enterprise-Tools, On-Premise- oder VPN-Bereitstellung, in YAML definierte kundenspezifische Tools, 99,9% SLA, dedizierter Account Manager). Die entscheidende Erkenntnis war, dass das Abfragevolumen und nicht die Benutzeranzahl die richtige Preisachse für ein KI-Produkt ist, bei dem jede Abfrage tatsächliche Rechenkosten verursacht.
Das schwierigste technische Problem waren nicht die KI oder die Odoo-Integration - es war die korrekte Handhabung von Odoos Zugriffsrechten. Wenn ein Benutzer fragt 'Zeig mir alle Mitarbeitergehaelter', muss der Bot dieselben Zugriffsrechte respektieren, die Odoo durchsetzen wuerde, wenn sich dieser Benutzer direkt einloggen wuerde. Wir loesen dies, indem wir Abfragen ueber ein Dienstkonto mit sorgfaeltig festgelegten Berechtigungen ausfuehren, aber das bedeutet, dass einige Abfragen 'Sie haben keinen Zugriff auf diese Daten' zurueckgeben - was korrektes Verhalten ist, kein Fehler.
Wir haben auch gelernt, dass KI-Halluzination ein echtes Risiko bei Geschaeftsdaten darstellt. Wenn der Bot selbstbewusst behauptet, der Q1-Umsatz betrage 2,3 Mio. $, obwohl er tatsaechlich 2,1 Mio. $ betrug, ist das schlimmer als gar keine Antwort. Wir mindern dies, indem wir die KI niemals Zahlen generieren lassen - sie formatiert und erklaert nur Daten, die direkt aus Odoo-Abfragen stammen. Die KI schreibt die Erzaehlung, aber jede Zahl in der Antwort laesst sich auf einen tatsaechlichen Datenbankdatensatz zurueckfuehren.
Sechs Monate nach dem Launch haben wir Kunden in der Fertigung, im Bildungswesen, im Einzelhandel und bei professionellen Dienstleistungen, die den Bot taeglich nutzen. Der durchschnittliche Kunde sendet 15-20 Abfragen pro Tag, meistens mobil ausserhalb der Buerozeiten - genau der Anwendungsfall, fuer den wir entwickelt haben. Die beliebtesten Abfragen sind Finanzuebersichten, Lagerbestaende und Vertriebspipeline-Status.
Was kommt als Naechstes: Wir bauen ein proaktives Alarmsystem. Anstatt darauf zu warten, dass Benutzer Fragen stellen, wird der Bot wichtige Kennzahlen ueberwachen und sie benachrichtigen, wenn etwas Aufmerksamkeit erfordert - Lagerbestand unter der Schwelle, ueberfaellige Rechnungen ueber einem bestimmten Betrag, gefaehrdete Umsatzziele. Das Ziel ist nicht nur, Fragen zu beantworten, sondern sicherzustellen, dass die richtigen Fragen ueberhaupt gestellt werden.