Dupa implementarea Odoo pentru peste 50 de companii, am observat un tipar care ne-a deranjat. Petreceam luni intregi configurand un sistem, migrand date, instruind utilizatorii si implementand totul. Sase luni mai tarziu, CEO-ul - persoana care a aprobat proiectul - inca ii cerea asistentului sau sa extraga cifre din Odoo. Nu se autentifica niciodata personal. Nu pentru ca sistemul era prost, ci pentru ca deschiderea unui browser, navigarea catre meniul corect, setarea filtrelor si citirea unui dashboard genereaza prea multa frictiune atunci cand vrei doar sa stii veniturile de luna trecuta.
Aceasta nu este o problema specifica Odoo. Se intampla cu SAP, cu Microsoft Dynamics, cu fiecare ERP. Oamenii care au cea mai mare nevoie de date - directori, fondatori, manageri in miscare - sunt cei mai putin inclinati sa stea in fata unei aplicatii desktop si sa faca click prin meniuri. Vor raspunsuri, nu interfete.
Am inceput cu un prototip simplu la sfarsitul lui 2025. Un bot Telegram care se putea conecta la o instanta Odoo si putea raspunde la intrebari in limbaj natural. Prima versiune folosea potrivire simpla de cuvinte cheie - daca tastai 'venituri', extragea totalul din account.move. Era rudimentar, dar reactia clientilor a fost imediata. CEO-ul unei companii de productie ne-a spus ca si-a verificat cifrele mai mult in prima saptamana cu botul decat in trimestrul anterior folosind dashboard-ul Odoo.
Adevarata descoperire a venit cand am integrat Claude ca nucleu IA. In loc de potrivire rigida de cuvinte cheie, utilizatorii puteau pune intrebari natural: 'Cate unitati de SKU-4521 am expediat saptamana trecuta?' sau 'Care reprezentant de vanzari a avut cea mai mare marja in T1?'. IA analizeaza intentia, o mapeaza la interogari ale modelelor Odoo, preia datele prin XML-RPC si formateaza un raspuns lizibil pentru om. Gestioneaza intrebarile ulterioare cu context, astfel incat poti intreba 'Dar in T2?' si stie ca inca vorbesti despre marjele reprezentantilor de vanzari.
Alegerea Telegram ca interfata a fost deliberata. Am luat in considerare construirea unei aplicatii mobile personalizate, a unui dashboard web, a unei integrari Slack. Dar clientii nostri sunt predominant din Orientul Mijlociu si regiunea CSI, unde Telegram este instrumentul implicit de comunicare de business. Oamenii il au deja deschis toata ziua. Fara instalare de aplicatie, fara frictiune de onboarding. Adaugi botul, te autentifici o data si incepi sa pui intrebari.
Arhitectura tehnica a trecut prin trei iteratii. Versiunea unu a fost un monolit - bot, IA si integrare Odoo toate intr-un singur proces Node.js. A functionat pentru demo, dar era imposibil de scalat. Versiunea doi s-a impartit in microservicii, dar a introdus prea multa complexitate pentru echipa noastra mica. Versiunea trei - ceea ce rulam in productie - este un monorepo pragmatic cu Grammy.js pentru botul Telegram, Fastify pentru stratul API si Prisma pentru propria noastra baza de date. Nu microservicii, nu monolit, doar separare rezonabila intr-o singura unitate implementabila.
Un lucru care ne-a surprins a fost cata munca implica detectarea schemei. Fiecare instanta Odoo este diferita. Clientii adauga campuri personalizate, instaleaza module diferite, folosesc conventii de denumire diferite. Botul nostru trebuie sa inteleaga ca clientul A numeste campul produsului 'x_brand', in timp ce clientul B il numeste 'product_brand_id'. Am construit un sistem automat de profilare a schemei care citeste metadatele Odoo ale clientului la prima conexiune si mapeaza numele specifice ale campurilor lor la sabloanele noastre standard de interogare.
Prețurile au fost o altă lecție. Inițial am planificat un model simplu per utilizator, dar clienții enterprise doreau costuri previzibile, în timp ce întreprinderile mici doreau puncte de intrare accesibile. Am ajuns la patru niveluri: o perioadă de probă gratuită de 14 zile pentru testare (1 utilizator, 20 interogări, toate rapoartele de bază), Starter la 39$/lună pentru echipe mici (3 utilizatori, 150 interogări pe lună, toate cele 43 de rapoarte, 4 rapoarte programate), Pro la 149$/lună pentru companii în creștere (10 utilizatori, 500 interogări pe lună, toate rapoartele plus MRP, 15 rapoarte programate, memorie conversațională, suport prioritar), și Enterprise cu prețuri personalizate pentru organizații mai mari (utilizatori nelimitați, instrumente enterprise, deployment on-premise sau VPN, instrumente personalizate definite în YAML, SLA 99.9%, account manager dedicat). Ideea cheie a fost că volumul de interogări, nu numărul de utilizatori, este axa corectă de prețuri pentru un produs AI unde fiecare interogare are un cost real de procesare.
Cea mai grea problema de inginerie nu a fost IA sau integrarea Odoo - a fost gestionarea corecta a drepturilor de acces Odoo. Cand un utilizator intreaba 'Arata-mi toate salariile angajatilor', botul trebuie sa respecte aceleasi drepturi de acces pe care Odoo le-ar impune daca acel utilizator s-ar autentifica direct. Rezolvam acest lucru rulind interogarile printr-un cont de serviciu cu permisiuni atent delimitate, dar asta inseamna ca unele interogari returneaza 'Nu aveti acces la aceste date' - ceea ce este comportament corect, nu un bug.
De asemenea, am invatat ca halucinatia IA este un risc real cand se lucreaza cu date de business. Daca botul afirma cu incredere ca veniturile din T1 au fost 2,3 milioane $ cand de fapt au fost 2,1 milioane $, asta este mai rau decat niciun raspuns. Atenuam acest risc nepermitand niciodata IA-ului sa genereze numere - doar formateaza si explica datele care vin direct din interogarile Odoo. IA scrie naratiunea, dar fiecare numar din raspuns se urmareste inapoi la o inregistrare reala din baza de date.
La sase luni dupa lansare, avem clienti din productie, educatie, retail si servicii profesionale care folosesc botul zilnic. Clientul mediu trimite 15-20 de interogari pe zi, in majoritate de pe mobil in afara orelor de birou - exact cazul de utilizare pentru care am proiectat. Cele mai populare interogari sunt sumarele financiare, nivelurile de stoc si starea pipeline-ului de vanzari.
Ce urmeaza: construim un sistem de alerte proactive. In loc sa astepte ca utilizatorii sa puna intrebari, botul va monitoriza metrici cheie si ii va notifica cand ceva necesita atentie - stoc sub prag, facturi restante peste o anumita suma, tinte de vanzari in pericol. Scopul nu este doar sa raspunda la intrebari, ci sa se asigure ca intrebarile potrivite sunt puse in primul rand.