Пiсля впровадження Odoo для 50+ компанiй ми помiтили закономiрнiсть, яка нас непокоїла. Ми витрачали мiсяцi на налаштування системи, мiграцiю даних, навчання користувачiв та розгортання. Через пiвроку CEO - людина, яка пiдписала проект, - все ще просила асистента витягти цифри з Odoo. Самi вони нiколи не заходили в систему. Не тому, що система була поганою, а тому, що вiдкривати браузер, переходити у потрiбне меню, ставити фiльтри та читати дашборд - це надто великий тертя, коли ти просто хочеш знати виручку минулого мiсяця.
Це не проблема, специфiчна для Odoo. Таке саме вiдбувається iз SAP, iз Microsoft Dynamics, з будь-якою ERP. Люди, яким данi потрiбнi найбiльше - керiвники, засновники, менеджери у постiйному русi - найменш схильнi сидiти перед настiльним додатком i клiкати через меню. Їм потрiбнi вiдповiдi, а не iнтерфейси.
Ми почали з простого прототипу наприкiнцi 2025 року. Telegram-бот, який мiг пiдключатися до iнстансу Odoo i вiдповiдати на запитання природною мовою. Перша версiя використовувала базове зiставлення за ключовими словами - якщо ви набирали 'revenue', вiн витягував суму з account.move. Це було грубо, але реакцiя наших клiєнтiв була миттєвою. CEO виробничої компанiї сказав нам, що за перший тиждень з ботом перевiряв свої цифри частiше, нiж за попереднiй квартал через дашборд Odoo.
Справжнiй прорив стався, коли ми iнтегрували Claude як ШI-основу. Замiсть жорсткого зiставлення за ключовими словами користувачi могли ставити запитання природно: 'Скiльки одиниць SKU-4521 ми вiдвантажили минулого тижня?' або 'Який торговий представник мав найвищу маржу у першому кварталi?'. ШI розбирає намiр, мапує його до запитiв до моделей Odoo, отримує данi через XML-RPC i форматує вiдповiдь, зрозумiлу людинi. Вiн обробляє уточнюючi запитання з контекстом, тож ви можете запитати 'А у другому кварталi?', i вiн знатиме, що ви все ще говорите про маржу торгових представникiв.
Вибiр Telegram як iнтерфейсу був свiдомим. Ми розглядали створення власного мобiльного додатку, веб-дашборда, iнтеграцiї зi Slack. Але нашi клiєнти переважно на Близькому Сходi та в країнах СНД, де Telegram - стандартний iнструмент бiзнес-комунiкацiї. Вiн уже вiдкритий у людей весь день. Нуль встановлень додаткiв, нуль складнощiв онбордингу. Ви додаєте бота, один раз автентифiкуєтесь i починаєте ставити запитання.
Технiчна архiтектура пройшла три iтерацiї. Перша версiя була монолiтом - бот, ШI та iнтеграцiя з Odoo в одному Node.js процесi. Вона працювала для демо, але масштабувати її було неможливо. Друга версiя роздiлилась на мiкросервiси, але внесла надто багато складностi для нашої маленької команди. Третя версiя - яку ми маємо в продакшенi - це прагматичний монорепозитарiй iз Grammy.js для Telegram-бота, Fastify для API-рiвня та Prisma для нашої власної бази даних. Не мiкросервiси, не монолiт - просто розумний подiл у межах однiєї розгортуваної одиницi.
Те, що нас здивувало, - це скiльки роботи йде на визначення схеми. Кожен iнстанс Odoo рiзний. Клiєнти додають кастомнi поля, встановлюють рiзнi модулi, використовують рiзнi угоди щодо iменування. Нашому боту потрiбно розумiти, що клiєнт А називає поле товару 'x_brand', а клiєнт Б - 'product_brand_id'. Ми побудували систему автоматичного профiлювання схеми, яка зчитує метаданi Odoo клiєнта при першому пiдключеннi та зiставляє їхнi конкретнi iмена полiв iз нашими стандартними шаблонами запитiв.
Ціноутворення стало ще одним уроком. Спочатку ми планували просту модель оплати за користувача, але корпоративні клієнти хотіли передбачуваних витрат, тоді як малий бізнес прагнув низького порогу входу. Зрештою ми створили чотири рівні: 14-денний безкоштовний пробний період для тестування (1 користувач, 20 запитів, всі основні звіти), Starter за $39/місяць для невеликих команд (3 користувачі, 150 запитів на місяць, всі 43 звіти, 4 заплановані звіти), Pro за $149/місяць для компаній, що розвиваються (10 користувачів, 500 запитів на місяць, всі звіти плюс MRP, 15 запланованих звітів, пам'ять розмов, пріоритетна підтримка), та Enterprise з індивідуальним ціноутворенням для великих організацій (необмежена кількість користувачів, корпоративні інструменти, розгортання на власних серверах або через VPN, користувацькі інструменти, визначені в YAML, SLA 99,9%, виділений менеджер облікового запису). Ключовим інсайтом стало те, що обсяг запитів, а не кількість користувачів, є правильною віссю ціноутворення для AI-продукту, де кожен запит має реальну обчислювальну вартість.
Найскладнiшою iнженерною проблемою були не ШI чи iнтеграцiя з Odoo - а правильна обробка прав доступу Odoo. Коли користувач запитує 'Покажи менi зарплати всiх спiвробiтникiв', бот має дотримуватися тих самих прав доступу, якi Odoo застосовував би, якби цей користувач увiйшов безпосередньо. Ми вирiшуємо це, виконуючи запити через сервiсний обліковий запис зi старанно визначеним обсягом дозволiв, але це означає, що деякi запити повертають 'У вас немає доступу до цих даних' - i це коректна поведiнка, а не баг.
Ми також дiзналися, що галюцинацiї ШI - реальний ризик при роботi з бiзнес-даними. Якщо бот впевнено стверджує, що виручка першого кварталу становила $2,3 млн, хоча насправдi вона була $2,1 млн, це гiрше, нiж вiдсутнiсть вiдповiдi. Ми пом'якшуємо це тим, що нiколи не дозволяємо ШI генерувати числа - вiн лише форматує та пояснює данi, що надходять безпосередньо з запитiв до Odoo. ШI пише оповiдь, але кожне число у вiдповiдi простежується до реального запису в базi даних.
Через шiсть мiсяцiв пiсля запуску у нас є клiєнти у виробництвi, освiтi, роздрiбнiй торгiвлi та професiйних послугах, якi користуються ботом щодня. Середнiй клiєнт надсилає 15-20 запитiв на день, переважно з мобiльних пристроїв у неробочi години - саме той сценарiй використання, пiд який ми проектували. Найпопулярнiшi запити - фiнансовi зведення, рiвнi запасiв та стан воронки продажiв.
Що далi: ми будуємо проактивну систему сповiщень. Замiсть того, щоб чекати на запитання користувачiв, бот буде вiдстежувати ключовi метрики та повiдомляти їх, коли щось потребує уваги - запаси нижче порогу, простроченi рахунки понад певну суму, цiлi продажiв пiд загрозою. Мета - не просто вiдповiдати на запитання, а забезпечити, щоб правильнi запитання взагалi ставилися.