استبدال حاسبة العروض التجارية في Excel داخل Bitrix24 بتطبيق بناه وكيل ذكاء اصطناعي

يعيش Excel في أقسام المبيعات أطول مما نتمنى. فما دام شخص واحد يستخدم الجدول، فكل شيء على ما يرام. وعندما يصبحون عشرة، تظهر لدى كل واحد نسخته الخاصة: أحدهم يعمل بقائمة أسعار قديمة، وآخر «عدّل قليلًا» المعادلة، وثالث منح العميل خصمًا أعلى من اللائحة. ولا يعرف المدير بذلك إلا من العقد الموقّع. وقد اختبر الكاتب التقني إيغور روسلياكوف، ضمن سلسلة مقالات Bitrix24 DevRel، مدى سرعة استبدال حاسبة كهذه بتطبيق داخل CRM إذا تولى وكيل ذكاء اصطناعي معظم العمل.

ما الذي بُني ولماذا

السيناريو مبسّط لكنه مألوف: شركة تبيع أثاثًا مكتبيًا. يبحث المدير عن المنتجات في الكتالوج، ويضيفها إلى الطلب، ويختار الشركة وجهة الاتصال، ويدخل الخصم. ويجب على التطبيق أن:

• يأخذ الأسعار الحالية من كتالوج CRM، لا من ثوابت في الكود؛
• يحسب المبلغ وفق قواعد موحدة؛
• يقيّد الخصم: حتى 100 000 ₽ بحد أقصى 5%، ومن 100 000 إلى 300 000 ₽ — 10%، ومن 300 000 ₽ — 15%؛
• ينشئ الصفقة والعرض التجاري مباشرة في Bitrix24.

ملاحظة مهمة: يُحدَّد الحد بحسب مبلغ الطلب قبل الخصم. وإذا أدخل المدير قيمة زائدة، فلا يقتطعها التطبيق بصمت، بل يرفض ويشرح النسبة المسموح بها.

استُخدم وكيل Bitrix24 Cowork/Code. وله وضعان: «Cowork» للعمل مع بيانات الأعمال في البوابة، و«Code» للتطوير. في الوضع الأول أنشأ الوكيل قسمًا تجريبيًا في الكتالوج يضم ستة منتجات، وثلاث شركات وجهات اتصال مرتبطة بها. وفي الثاني بنى التطبيق نفسه ونشره على منصة Bitrix24 Vibecode.

كيف بُني الأمر (البرومبت)

أكثر أجزاء المادة فائدة ليس الحاسبة نفسها، بل بنية الطلب. لم يكتب المؤلف البرومبت يدويًا: طلب أولًا من الوكيل صياغة مهمة دقيقة، ثم مرّر التقرير عبر ChatGPT، وعدّله عدة مرات وسلّمه للوكيل. وهذا يوفر الرموز (tokens) أيضًا.

تتضمن المهمة قرارات يُنسى عادةً وصفها:

• الخادم مصدر الحقيقة. لا يُقبل المبلغ القادم من العميل. قبل إنشاء الصفقة يقرأ الخادم الأسعار من الكتالوج من جديد ويعيد احتساب الحد. والتلاعب بالبيانات في المتصفح لا يجدي.
• الهوية تأتي من البوابة. يصبح الموظف الحالي مسؤولًا عن الصفقة. ويُؤخذ المعرّف من ترويسة البوابة، لا من متن الطلب.
• الوصول بحسب القسم. يتلقى الموظف من خارج القسم المسموح رفضًا واضحًا، لا شاشة فارغة. وتُنفَّذ الإجراءات في CRM بصلاحياته، لا باسم المسؤول.
• عدم التكرار (Idempotency). يُنشأ مفتاح الطلب مرة واحدة لكل عملية حساب. والنقر المتكرر يعيد الصفقة المنشأة سابقًا، أما النسخة المتوازية المكررة فتتلقى الرمز 409.
• حدود صارمة. ما لا يزيد على 50 سطرًا، والكمية من 1 إلى 999، والخصم من 0 إلى 50، ولا وكيل (proxy) شامل إلى البوابة.
• قائمة «ما لا يجب فعله». الموافقات وضريبة القيمة المضافة والهامش وسجل التدقيق مؤجلة إلى الإصدار التالي. وهذا يحمي من تضخم المهمة.

وينبغي ذكر ترتيب العمل أيضًا: أولًا اختبارات الجزء المالي (الحدود 99 999,99 / 100 000 / 299 999,99 / 300 000)، ثم الخادم، ثم الواجهة، ثم فحص الأمان والنشر. ولا ينشئ الوكيل الصفقة التجريبية إلا بعد تأكيد من إنسان.

القيود وما يمكن الاستفادة منه

أولًا التحفظات. هذه مادة من سلسلة فريق DevRel في Bitrix24 نفسه، لذا فهي تعرض أداة المورّد في صورة مواتية. والحالة نموذجية: كتالوج من ستة منتجات وقاعدة خصم واحدة لا يعادلان قائمة أسعار حقيقية بمئات البنود والاستثناءات. وفي الجزء المتاح من النص لا توجد أرقام نهائية عن الوقت وعدد التكرارات، لذلك لا يمكن تقدير التوفير. وتبقى أسئلة يطرحها المؤلف نفسه: إلى أي مدى يأمن المرء على الحسابات في تطبيق كتبه الذكاء الاصطناعي، ومن سيتولى صيانته؟

والخلاصة العملية للمطوّر ومدير المنتج أوسع من Bitrix24. إذا سلّمتم أداة داخلية لوكيل ذكاء اصطناعي، فجودة النتيجة يحددها لا النموذج بل المواصفات الفنية. صِفوا أين تكمن الحقيقة (الخادم)، وما الممنوع قبوله من العميل، وكيف تُتفادى التكرارات، وما الذي لا يدخل صراحةً في الإصدار. واختبروا المال والصلاحيات بتجارب عند حدود القيم. ولا تنشئوا كيانات فعلية في CRM دون تأكيد بشري: وقد أدرج المؤلف هذا البند أيضًا في المهمة.