بعد تطبيق Odoo لأكثر من 50 شركة، لاحظنا نمطاً أزعجنا. كنا نقضي أشهراً في إعداد نظام وترحيل البيانات وتدريب المستخدمين ونشر كل شيء. بعد ستة أشهر، كان المدير التنفيذي - الشخص الذي وقّع على المشروع - لا يزال يطلب من مساعده سحب الأرقام من Odoo. لم يسجل دخوله بنفسه أبداً. ليس لأن النظام كان سيئاً، لكن لأن فتح متصفح والتنقل إلى القائمة الصحيحة وتعيين الفلاتر وقراءة لوحة المعلومات هو احتكاك كبير عندما تريد فقط معرفة إيرادات الشهر الماضي.
هذه ليست مشكلة خاصة بـ Odoo. تحدث مع SAP ومع Microsoft Dynamics ومع كل نظام ERP. الأشخاص الذين يحتاجون البيانات أكثر - المديرون التنفيذيون والمؤسسون والمديرون المتنقلون - هم الأقل احتمالاً للجلوس أمام تطبيق سطح مكتب والنقر عبر القوائم. يريدون إجابات، لا واجهات.
بدأنا بنموذج أولي بسيط في أواخر 2025. بوت Telegram يمكنه الاتصال بنسخة Odoo والإجابة على الأسئلة باللغة الطبيعية. استخدم الإصدار الأول مطابقة كلمات مفتاحية أساسية - إذا كتبت 'revenue'، كان يسحب الإجمالي من account.move. كان بدائياً لكن رد فعل عملائنا كان فورياً. أخبرنا المدير التنفيذي لشركة تصنيع أنه فحص أرقامه في الأسبوع الأول مع البوت أكثر مما فعل في الربع السابق باستخدام لوحة معلومات Odoo.
الاختراق الحقيقي جاء عندما دمجنا Claude كعمود فقري للذكاء الاصطناعي. بدلاً من مطابقة الكلمات المفتاحية الصارمة، يمكن للمستخدمين طرح الأسئلة بشكل طبيعي: 'كم وحدة من SKU-4521 شحنا الأسبوع الماضي؟' أو 'أي مندوب مبيعات حقق أعلى هامش في الربع الأول؟' يحلل الذكاء الاصطناعي النية، ويربطها باستعلامات نماذج Odoo، ويجلب البيانات عبر XML-RPC، وينسق إجابة قابلة للقراءة البشرية. يتعامل مع أسئلة المتابعة مع السياق، فيمكنك أن تسأل 'وماذا عن الربع الثاني؟' ويعرف أنك لا تزال تتحدث عن هوامش مندوبي المبيعات.
اختيار Telegram كواجهة كان متعمداً. فكّرنا ببناء تطبيق جوال مخصص، لوحة معلومات ويب، تكامل Slack. لكن عملاءنا معظمهم في الشرق الأوسط ومنطقة الكومنولث، حيث Telegram هو أداة التواصل التجاري الافتراضية. الناس يفتحونه طوال اليوم. لا تثبيت تطبيق، لا احتكاك توجيهي. تضيف البوت، وتصادق مرة واحدة، وتبدأ بطرح الأسئلة.
البنية التقنية مرّت بثلاث تكرارات. الإصدار الأول كان monolith - البوت والذكاء الاصطناعي وتكامل Odoo كلها في عملية Node.js واحدة. عمل للعروض التوضيحية لكن كان من المستحيل توسيعه. الإصدار الثاني انقسم إلى microservices لكنه أدخل تعقيداً كبيراً لفريقنا الصغير. الإصدار الثالث - ما نشغله في الإنتاج - هو monorepo براغماتي مع Grammy.js لبوت Telegram و Fastify لطبقة API و Prisma لقاعدة بياناتنا. ليس microservices، ليس monolith، فقط فصل معقول ضمن وحدة نشر واحدة.
شيء فاجأنا هو كمية العمل في اكتشاف المخطط. كل نسخة Odoo مختلفة. العملاء يضيفون حقولاً مخصصة، يثبتون وحدات مختلفة، يستخدمون اصطلاحات تسمية مختلفة. يحتاج بوتنا لفهم أن العميل أ يسمي حقل المنتج 'x_brand' بينما العميل ب يسميه 'product_brand_id'. بنينا نظام تحديد مخطط تلقائي يقرأ بيانات Odoo الوصفية للعميل عند الاتصال الأول ويربط أسماء حقولهم المحددة بقوالب استعلاماتنا القياسية.
كان التسعير درسًا آخر. خططنا في البداية لنموذج بسيط قائم على عدد المستخدمين، لكن عملاء المؤسسات أرادوا تكاليف يمكن التنبؤ بها بينما أرادت الشركات الصغيرة نقاط دخول منخفضة. انتهى بنا الأمر بأربع مستويات: نسخة تجريبية مجانية لمدة 14 يومًا للاختبار (مستخدم واحد، 20 استعلامًا، جميع التقارير الأساسية)، ومستوى Starter بسعر 39 دولارًا شهريًا للفرق الصغيرة (3 مستخدمين، 150 استعلامًا شهريًا، جميع التقارير البالغ عددها 43، 4 تقارير مجدولة)، ومستوى Pro بسعر 149 دولارًا شهريًا للشركات النامية (10 مستخدمين، 500 استعلام شهريًا، جميع التقارير بالإضافة إلى MRP، 15 تقريرًا مجدولًا، ذاكرة المحادثات، دعم ذو أولوية)، ومستوى Enterprise بأسعار مخصصة للمؤسسات الأكبر (مستخدمون غير محدودين، أدوات المؤسسات، نشر داخلي أو عبر VPN، أدوات مخصصة محددة في YAML، اتفاقية مستوى خدمة 99.9%، مدير حساب مخصص). كانت الرؤية الأساسية هي أن حجم الاستعلامات، وليس عدد المستخدمين، هو المحور الصحيح للتسعير لمنتج ذكاء اصطناعي حيث يكون لكل استعلام تكلفة حوسبة فعلية.
أصعب مشكلة هندسية لم تكن الذكاء الاصطناعي أو تكامل Odoo - كانت التعامل مع صلاحيات Odoo بشكل صحيح. عندما يسأل مستخدم 'أظهر لي جميع رواتب الموظفين'، يحتاج البوت لاحترام نفس صلاحيات الوصول التي سيفرضها Odoo إذا سجّل ذلك المستخدم دخوله مباشرة. نحلّ هذا بتشغيل الاستعلامات عبر حساب خدمة بصلاحيات محددة بعناية، لكن هذا يعني أن بعض الاستعلامات تُرجع 'ليس لديك وصول لهذه البيانات' - وهو سلوك صحيح، وليس خطأ.
تعلمنا أيضاً أن هلوسة الذكاء الاصطناعي خطر حقيقي عند التعامل مع بيانات الأعمال. إذا قال البوت بثقة أن إيرادات الربع الأول كانت 2.3 مليون دولار بينما كانت فعلياً 2.1 مليون، فهذا أسوأ من عدم الإجابة. نخفف هذا بعدم السماح للذكاء الاصطناعي بتوليد الأرقام إطلاقاً - إنما ينسق ويشرح البيانات القادمة مباشرة من استعلامات Odoo. الذكاء الاصطناعي يكتب السرد، لكن كل رقم في الإجابة يعود إلى سجل قاعدة بيانات فعلي.
بعد ستة أشهر من الإطلاق، لدينا عملاء في التصنيع والتعليم والتجزئة والخدمات المهنية يستخدمون البوت يومياً. العميل المتوسط يرسل 15-20 استعلاماً يومياً، معظمها من الجوال خارج ساعات العمل - بالضبط حالة الاستخدام التي صممنا لها. أكثر الاستعلامات شيوعاً هي الملخصات المالية ومستويات المخزون وحالة خط مبيعات.
ما هو التالي: نبني نظام تنبيهات استباقي. بدلاً من انتظار المستخدمين لطرح الأسئلة، سيراقب البوت المقاييس الرئيسية وينبههم عندما يحتاج شيء للاهتمام - مخزون تحت العتبة، فواتير متأخرة بعد مبلغ معين، أهداف مبيعات في خطر. الهدف ليس فقط الإجابة على الأسئلة بل ضمان طرح الأسئلة الصحيحة في المقام الأول.