Make AI Toolkit 2026: أتمتة فرز رسائل العملاء بالعربية مع اعتماد بشري

ليس من الحكمة أن ترد شركة خليجية على رسائل عملائها بنموذج لغوي من دون قواعد. لكن من غير العملي أيضاً أن يقرأ الموظف كل رسالة متكررة يدوياً قبل أن يصل إلى السؤال المهم. هنا تظهر فائدة Make AI Toolkit: فرز أولي للرسائل، استخراج إشارات واضحة، ثم توجيه الحالات الحساسة أو غير الواثقة إلى إنسان.

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

ما الذي ستبنيه ولماذا هو أفضل من رد آلي مباشر؟

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

الفرق مهم خصوصاً في السعودية والإمارات حيث قد تصل الرسالة بمزيج عربي وإنجليزي أو بلهجة محلية، وقد تتضمن رقماً أو طلباً حساساً. إن أردت لاحقاً توسيع الأتمتة من استقبال الرسالة إلى CRM وواتساب، ابدأ بـدليل أتمتة المبيعات بالذكاء الاصطناعي، لكنه لا يغني عن اختبار التصنيف وحده أولاً.

ما هو Make AI Toolkit حالياً؟

توضح وثائق Make الرسمية أن Make AI Toolkit يحل محل Make AI Tools للتطبيقات الجديدة، ويجمع مهام مثل التصنيف واكتشاف اللغة والاستخراج والتلخيص والترجمة والتقييس. هذه المهام مفيدة لأنها تقيد نطاق ما نطلبه؛ بدلاً من سؤال مفتوح «ماذا تفعل بهذه الرسالة؟» نطلب تصنيفاً أو استخراجاً له مخرج متوقع.

تحقق من خطتك والحساب قبل الاعتماد على أي موصل أو نموذج خارجي، لأن التوافر والحدود تتغير. هذا الدليل يركز على تصميم العملية، وهو صالح سواء استخدمت مزود Make المدمج أو نموذجاً خارجياً مسموحاً في خطة شركتك. لا تضع مفتاح API أو بيانات شخصية في وصف السيناريو أو لقطة شاشة عامة.

المرحلة صفر: اختر صندوق بريد واحداً ومقياساً واحداً

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

• مقياس السرعة: زمن وصول الرسالة إلى الشخص المناسب.
• مقياس الجودة: نسبة التصنيف الذي يوافق عليه المراجع من أول مرة.
• مقياس السلامة: عدد الرسائل التي مرّت دون مراجعة وكان يجب تصعيدها.
• مقياس الأعمال: هل أصبحت الرسائل عالية القيمة تصل أسرع إلى المالك؟

لا تجعل «عدد السيناريوهات» مقياس نجاح. سيناريو واحد ثابت وواضح يجلب قيمة أكبر من عشرة سيناريوهات لا يعرف أحد لماذا أطلقتها أو كيف يوقفها عند الخطأ.

الخطوة 1: أنشئ السيناريو وارسم المسار على الورق

تشرح وثائق البدء في Make منطق بناء السيناريو عبر المشغلات والوحدات والاتصالات. قبل فتح اللوحة، ارسم المسار بخمس عقد: استقبال الرسالة، تنظيف بسيط، تصنيف/استخراج، فلتر قرار، ثم إخطار أو صف مراجعة. إذا لم تستطع شرح المسار على ورقة، لن تصلحه بسهولة في المنشئ.

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

الخطوة 2: نظّف الرسالة قبل التصنيف

الرسائل الواقعية فيها توقيع بريد، وسلسلة ردود، ووسوم HTML، وربما رقم طلب. إذا أرسلت كل ذلك للنموذج فلن تحصل على تصنيف أسوأ فقط؛ ستزيد احتمال أن يعامل التوقيع أو الرد القديم كأنه طلب جديد. استخرج آخر رسالة مفيدة، وأزل التوقيع الطويل، واحتفظ بالنص الأصلي داخل نظامك للمراجع.

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

الخطوة 3: صمّم مخرج الذكاء الاصطناعي مثل نموذج بيانات

لا تستخدم طلباً فضفاضاً مثل «حلل الرسالة». اختر حقولاً يمكن للسيناريو أن يقرأها. مثلاً: category وlanguage وsummary وneeds_human_review وreason. إذا كانت الأداة تدعم مخرجات منظمة في حسابك، عرّف القيم الممكنة للفئة. إذا لم تدعمها، اطلب النص بالهيكل نفسه ثم تحقق منه بقاعدة قبل استخدامه في الفلتر.

صنّف الرسالة ضمن أحد الخيارات فقط:
sales_inquiry | support | complaint | partnership | unclear
أعد JSON صحيحاً فقط، يحوي:
category، language، summary، missing_information، needs_human_review، reason.
لا تكتب رداً للعميل ولا تخترع سعراً أو سياسة.
اجعل needs_human_review = true عند شكوى أو تهديد أو طلب قانوني أو غموض.

لا تستخدم «درجة ثقة 87%» كأنها حقيقة إحصائية؛ قد تكون مجرد تقدير لفظي من النموذج. إذا احتجت إلى قرار آلي، استخدم أسباباً وقواعد تستطيع مراجعتها: وجود شكوى، أو عدم اكتمال اسم المنتج، أو نص قصير، أو تصنيف unclear. ثم راقب النتائج البشرية لتعديل القاعدة.

الخطوة 4: أضف بوابة بشرية قبل أي فعل خارجي

هذه أهم خطوة. أرسل الملخص والتصنيف إلى جدول أو قناة مراجعة مع رابط الرسالة الأصلية، لكن لا تجعل السيناريو يرسل رد العميل. المراجع يختار «اعتماد»، أو «تعديل الفئة»، أو «تصعيد». عندئذ فقط يمكن أن تستأنف العملية وفق قرار واضح. تشرح وثائق Make حول مدخلات ومخرجات السيناريو طرق تنظيم البيانات داخل السيناريوهات؛ استفد من ذلك في جعل نتيجة المراجع جزءاً صريحاً من المسار، لا رسالة جانبية ضائعة.

في أول أسبوعين، اجعل المراجعة إلزامية لكل الحالات. بعد أن تجمع بيانات كافية، قد تسمح للتوجيه الداخلي الآلي لفئة منخفضة المخاطر، مع إبقاء الشكوى والرسالة الغامضة تحت الاعتماد. ليس الهدف الوصول إلى صفر تدخل بشري؛ الهدف أن يتدخل الإنسان في الموضع الذي يغير النتيجة فعلاً.

الخطوة 5: اختبر 20 رسالة صعبة قبل التشغيل

اختبر العربية الفصحى، واللهجة الخفيفة، والإنجليزية، والمزج بين اللغتين. أضف رسالة مكتوبة بلا علامات ترقيم، ورسالة بها شكوى مبطنة، ورسالة تسأل عن أكثر من منتج، ورسالة لا تذكر أي منتج. لا تستخدم بيانات العملاء الحقيقية في بيئة تجريب غير معتمدة؛ بدّل الأسماء والأرقام مع الحفاظ على بنية الرسالة.

كيف تقرأ اللقطات داخل Make؟

لا تحفظ أسماء الأزرار؛ افهم الطبقات: مشغّل يعطيك البيانات، ووحدة تحولها، وفلتر يقرر الطريق، ثم وجهة تحفظ أو ترسل النتيجة. كل طبقة يجب أن تُظهر لك ما دخل وما خرج عند التشغيل التجريبي. إذا كان لا يمكنك رؤية النص الذي صُنّف أو سبب الفلتر، فأنت لا تستطيع تدقيق خطأ العميل بعد ذلك.

اكتب تسمية عملية لكل وحدة: «تنظيف نص الرسالة»، «تصنيف أولي»، «توجيه الشكوى للمراجعة». بعد شهر، هذه التسمية أهم من اسم الموصل؛ لأن أي زميل يستطيع فهم منطق العملية من دون قراءة كل حقل.

الخصوصية والاعتمادية ليستا إضافتين لاحقتين

ضع أقل قدر ممكن من البيانات في كل خطوة، واحذف السجلات التجريبية التي لا تحتاجها، وحدد من يستطيع تعديل السيناريو أو رؤية التنفيذ. لا تفترض أن إخفاء البريد من الرسالة وحده يحل كل شيء؛ المحتوى قد يكشف هوية العميل أو طلبه. راجع دليل خصوصية البيانات والذكاء الاصطناعي للشركات الخليجية قبل ربط منصة الأتمتة بمصادر إنتاجية.

وابنِ وضع فشل بسيطاً: إذا تعطلت خطوة الذكاء الاصطناعي، لا تفقد الرسالة ولا تتركها معلقة. أرسلها إلى قائمة احتياط مع وقت الاستلام وسبب الفشل، ونبه مالك التشغيل. أفضل أتمتة ليست التي لا تفشل أبداً، بل التي تفشل بطريقة واضحة وقابلة للاسترداد.

خطة تشغيل من سبعة أيام

في اليوم الأول اجمع الرسائل المموهة وحدد الفئات. في الثاني ارسم المسار وحدد الرسائل المستثناة. في الثالث ابنِ الاستقبال والتنظيف فقط. في الرابع أضف التصنيف والمخرج المنظم. في الخامس راجع عشرين حالة مع شخص من المبيعات أو الدعم. في السادس شغّل القناة التجريبية مع اعتماد يدوي. في السابع راجع الأخطاء ومؤشر الزمن، ثم قرر ما إذا كانت حالة واحدة تستحق التوسع.

الخلاصة: Make AI Toolkit لا ينبغي أن يكون آلة ردود سريعة، بل طبقة تنظيم تجعل الرسالة تصل إلى الشخص المناسب مع سياق أوضح. صمّم الحقول، واختبر الرسائل الصعبة، وأبقِ الاعتماد البشري في القرارات التي قد تؤثر في العميل أو سمعة الشركة.

تصميم مصفوفة التوجيه قبل وضع أي فلتر

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

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

كيف تكتب تعليمات تصنيف تتحمل العربية المختلطة؟

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

اطلب من النموذج المحافظة على لغة الملخص أو تحديد اللغة فقط، لا ترجمة الرسالة تلقائياً ما لم تكن هناك حاجة تشغيلية. الترجمة قبل الفهم قد تغير اسم المنتج أو سياق العبارة. وإذا احتاج فريقك ملخصاً موحداً بالعربية، اجعل الرسالة الأصلية متاحة بجانبه للمراجع، ولا تجعل الملخص بديلاً عن المصدر.

قواعد حاسمة:
- «شكوى» تشمل تضرر العميل أو ادعاء فشل خدمة أو طلب استرداد أو تهديد بالتصعيد.
- عند وجود أكثر من نية، اختر الأعلى خطورة واكتب البقية في summary.
- لا تستنتج بلد العميل أو قدرته الشرائية أو أولوية تجارية من الاسم أو اللهجة.
- لا تكتب جواباً للعميل ولا تعد بمدة أو سعر.

اختبار القبول: كيف تعرف أن المسار يوفر وقتاً بالفعل؟

شغّل 30 إلى 50 رسالة مموهة عبر السيناريو، ثم اجعل موظفاً يصنفها يدوياً من دون رؤية اقتراح الذكاء الاصطناعي أولاً. بعد ذلك قارن الفئتين والسبب. قياسك ليس «كم رسالة صنفها النموذج»، بل نسبة التطابق في الفئات الحساسة، وكم مرة وفر الملخص قراءة كاملة، وكم رسالة احتاجت تصحيحاً يدوياً.

إذا اختلف النموذج والمراجع، سجّل نوع الاختلاف. إن كان بسبب فئة غير معرفة جيداً، حسّن التعريف أو أضف فئة. إن كان بسبب رسالة غامضة، قد يكون التصعيد الصحيح هو النتيجة الأفضل حتى لو بدا أقل آلية. لا تدفع النظام إلى اختيار فئة فقط كي ترفع نسبة الأتمتة.

ارسم خط أساس قبل تشغيل السيناريو: متوسط زمن التوجيه الحالي، وعدد الرسائل المتأخرة، وعدد مرات انتقال الرسالة بين الفرق. ثم قارن أسبوعاً بأسبوع. قد تجد أن النموذج لا يقلل زمن أول رد، لكنه يقلل التحويل الخاطئ؛ هذه فائدة عملية يجب أن تظهر في قرارك.

المراقبة اليومية: ما الذي يراه مالك التشغيل؟

لا يحتاج مالك التشغيل إلى لوحة معقدة. يكفيه عدد الرسائل الواردة، التوزيع حسب الفئة، عدد التصعيدات، عدد حالات الفشل، وزمن بقاء الرسائل في طابور المراجعة. أضف قائمة بأكثر 10 رسائل صُححت فئتها. هذه القائمة غالباً أغنى من متوسط عام؛ تكشف المصطلحات أو السيناريوهات التي لم يتعلم المسار التعامل معها.

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

الموافقات والأدوار داخل الفريق

حدد ثلاثة أدوار على الأقل: مالك أعمال يقرر الفئات وقواعد التصعيد، ومالك تقني يدير الاتصال والأسرار، ومراجع جودة يرى نتائج التشغيل. في شركة صغيرة قد يؤدي شخص دورين، لكن لا ينبغي أن يكون شخص واحد هو من يكتب القاعدة ويعتمد كل رسالة حساسة ويراجع أداءه من دون رقابة. هذا فصل بسيط يقلل الأخطاء غير المرئية.

وعندما يطلب فريق المبيعات «اجعلوا النظام يرد تلقائياً»، لا ترفض أو تقبل مباشرة. اطلب قائمة ردود معتمدة للحالات البسيطة، وقاعدة توقف، وتجربة محدودة. الرد الآلي هو مرحلة أخرى لها مخاطر مختلفة عن التصنيف. قد تبدأ برد يؤكد الاستلام فقط، ثم تقيس أثره قبل عرض سعر أو توصية.

سيناريوهات يجب أن تتوقف عندها الأتمتة

• تهديد قانوني أو مطالبة باسترداد أو نزاع في الدفع.
• بيانات صحية أو وثائق هوية أو معلومات مالية حساسة.
• طلب تغيير حساب أو صلاحيات أو بيانات دفع.
• رسالة غامضة جداً، أو نص فارغ، أو مرفق لا يستطيع النظام تحليله بأمان.
• تكرار عدد كبير من الرسائل من العميل نفسه خلال وقت قصير.
• انقطاع الموصل أو فشل خطوة النموذج أو تجاوز حد تشغيل.

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

كيف تتوسع بعد نجاح الحالة الأولى؟

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

بعد نجاح التوجيه، تستطيع التفكير في مسودة رد داخلية لا تُرسل تلقائياً. اجعلها تستند إلى قاعدة معرفة معتمدة، واربطها بمراجعة. هذا المسار يتكامل جيداً مع إدارة المعرفة بالذكاء الاصطناعي للشركات، لكنه لا يجوز أن يبدأ بمصادر غير مراجعة أو بملفات متاحة لأي شخص.

التكلفة: راقب تكلفة الخطأ قبل تكلفة التشغيل

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

اختر سقفاً لتشغيل التجربة، وحدد من يوقف السيناريو إذا تجاوز الفشل أو التأخير مستوى معيناً. هذا القرار البسيط يمنع «التشغيل الصامت» الذي يستمر رغم أن الرسائل لا تصل إلى أصحابها. كما يجعل موافقة الإدارة مبنية على تجربة محدودة ذات حدود، لا على وعود عامة بالأتمتة.

بعد شهر: اجتماع مراجعة من ثلاثين دقيقة

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

وثّق القرار والسبب ومالك التنفيذ وتاريخ المراجعة التالية. عندها فقط تتحول الأتمتة من سيناريو تقني إلى عملية يمكن للإدارة الوثوق بها وتحسينها عبر الوقت.

لا تنس التواصل مع الفريق الذي سيتلقى الرسائل. اشرح له معنى كل فئة وما الذي يراه في الملخص وكيف يبلغ عن خطأ. الأتمتة التي لا يفهمها المستلمون ستُتجاوز يدوياً، حتى لو كانت منطقية من الناحية التقنية.

ومع نمو الحجم، راجع الصلاحيات والحدود دورياً. قد تكون قاعدة آمنة على عشر رسائل في اليوم غير مناسبة عند وصول آلاف الرسائل أو عند إضافة موظفين ومصادر بيانات جديدة.

ملاحظة بصرية مهمة

في الدليل العملي لا ينبغي أن توجد صورة لمجرد كسر النص. لا أدرج لقطة إلا إذا كان القارئ يستطيع أن يحدد منها خطوة أو إعداداً أو قراراً. لهذا حذفت الرسوم الزخرفية القادمة من صفحة Make الرسمية؛ هي صحيحة كمادة تعريفية للموقع، لكنها لا تشرح كيفية بناء سيناريو أو مراجعة مخرج.

عند توفر لقطة فعلية من بيئة Make بعد إعداد سيناريو تجريبي بمحتوى مموه، يمكن إضافتها تحت خطوة محددة مع تعليق يشرح بالضبط ما الذي يجب ملاحظته. إلى ذلك الحين، يبقى الجدول والخطوات النصية أوضح وأصدق من واجهة لا تحمل معلومة قابلة للتطبيق.