Support Desk هجين: Chatwoot + Open WebUI لاقتراح ردود ذكية مع مراجعة بشرية

التفاصيل البرمجية والتهيئة

مقدمة حول سير العمل

سير عمل يدمج Chatwoot كـ inbox خدمة عملاء مع Open WebUI + Ollama كمصدر ذكي لاقتراح ردود من قاعدة المعرفة، يظهر الاقتراح كـ Private Note للوكيل البشري الذي يقرر النشر بعد المراجعة.

الهدف من سير العمل

تقليل متوسط زمن الرد على استفسارات العملاء بنسبة 40-60%، مع الحفاظ على المراجعة البشرية الإلزامية لكل رد مرسل. اقتراحات AI ترفع كفاءة الوكلاء، لا تحل محلهم.

الأدوات والتقنيات المستخدمة

تم استخدام الأدوات التالية: chatwoot و open-webui و ollama و n8n و apitable

تفاصيل تنفيذ سير العمل

• مستوى الصعوبة: متوسط
• الوقت المتوقع للإعداد:
• محفز التشغيل (Trigger):

خطوات العمل (الآلية)

1. إعداد Chatwoot وتثبيت قنواته (راجع tool review). تأكد من تفعيل webhooks في Settings → Integrations.
2. في Open WebUI، أنشئ Workspace باسم ‘Customer Support’. ارفع قاعدة المعرفة (Markdown files من FAQs الموقع، أدلة المنتج، سياسات).
3. في Open WebUI → Admin → Documents، استخدم bge-m3 كـ embedding، chunk size 800، Top-K 5-8.
4. أنشئ workflow في n8n: Webhook Trigger يستقبل أحداث Chatwoot عند `message_created` (event.type).
5. Filter Node: تابع فقط للمحادثات الواردة (sender_type=Contact)، تجاهل الردود الصادرة.
6. Code Node: استخرج محتوى الرسالة، معلومات العميل، تاريخ المحادثة السابقة (إن وُجد).
7. HTTP Request إلى Open WebUI API (/api/chat/completions) مع: prompt النظام محدد (‘أجب فقط من الوثائق المرفقة’)، الرسالة، Workspace ID للـ RAG.
8. Open WebUI يستعلم من Vector DB، يرسل context + question إلى Ollama، يعيد الجواب مع citations.
9. Code Node ينسّق الجواب: نص الرد المقترح + قائمة المصادر (كل مصدر مع رابط داخلي للوثيقة).
10. HTTP Request إلى Chatwoot API: أنشئ Private Note بالاقتراح، أضف tags للتصنيف (مثلاً ‘billing’, ‘technical’).
11. في حالة كشف ‘urgency’ عالية أو طلب قانوني، أرسل تنبيه Telegram للمشرف وأضف tag ‘needs-human-priority’.
12. Log في APITable: محادثة ID، نص العميل، الاقتراح، tags، timestamp.
13. بعد ساعة، n8n يفحص حالة المحادثة: هل أُرسل الرد المقترح كما هو؟ مُعدَّلاً؟ مُرفَضاً؟ يحدّث APITable.
14. تقرير أسبوعي للمشرف: نسبة قبول، أكثر الفئات، الفجوات في قاعدة المعرفة (أسئلة لم تجد إجابة جيدة).

وصف مفصل

## المشكلة فرق خدمة العملاء في الشركات الصغيرة والمنظمات تواجه ضغط استفسارات متكرر. 60-70% من الاستفسارات اليومية أسئلة شائعة لها إجابات في الوثائق، لكن الوكيل يبحث يدوياً في كل مرة. هذا يبطئ الرد ويرهق الفريق. الحل التجاري (Intercom Fin, Zendesk AI) مكلف. الحل الـ self-hosted يستفيد من Open WebUI + Ollama + RAG على قاعدة المعرفة. ## المُدخلات – محادثات Chatwoot الواردة من كل القنوات (موقع، WhatsApp، Email، Telegram) – قاعدة معرفة Markdown (FAQs، أدلة المنتج، سياسات الإرجاع، …) — مفهرسة في Open WebUI – نموذج LLM يدعم العربية: qwen2.5:14b أو 32b – Embedding model: bge-m3 – n8n كـ ناقل بين Chatwoot و Open WebUI ## المُخرجات – Private Notes داخل محادثة Chatwoot تحوي ردوداً مقترحة مع مصادر – تصنيف تلقائي للمحادثة (فئة، أولوية) كـ tags – تنبيه للمشرف إذا كانت المحادثة تحتاج تحويلاً متخصصاً (مثلاً: قانوني) – إحصاءات في APITable: كم رد قُبل، كم عُدِّل، كم رُفِض ## مخطط Mermaid “`mermaid graph LR A[عميل يرسل رسالة] –> B[Chatwoot Inbox] B –>|Webhook on new message| C[n8n] C –>|Query with context| D[Open WebUI API] D –>|RAG على قاعدة المعرفة| E[Ollama qwen2.5:14b] E –>|Suggested reply + sources| D D –> C C –>|Add as Private Note| B C –>|Log to APITable| F[(APITable)] B –>|Agent reviews + sends| A G[Knowledge Base MD files] -.fed into.-> D “` ## نقاط الفشل – Chatwoot webhook لا يصل: قد يكون بسبب تغير IP أو HTTPS غير صحيح. اختبر مع webhook.site أولاً. – Open WebUI يجيب من ذاكرة النموذج لا من الوثائق: prompt النظام يجب أن يكون صريحاً (‘أجب فقط من السياق، إذا لم تجد قل لا أعرف’). – Ollama يستغرق وقتاً طويلاً للنماذج الكبيرة على CPU: قد يجعل الاقتراح يصل بعد رد العميل ثانية. الحل: GPU أو نموذج أصغر، أو تشغيل async مع notification. – Private Note يظهر للعميل بطريق الخطأ: تأكد من استخدام `private: true` في API call، اختبر بحساب وهمي. – اقتراح بمعلومات قديمة: قاعدة المعرفة لم تُحدَّث. ضع تذكيراً شهرياً للمشرف لمراجعتها. – Hallucination في الجواب: النموذج يخترع تفاصيل غير موجودة في الوثائق. الحل: RAG strict + temperature منخفض + مراجعة بشرية إلزامية. – العميل بلغة لهجة (مصرية، شامية، خليجية): النموذج قد يجيب بالفصحى بشكل غير طبيعي. خيار: تحديد نموذج (Aya) يدعم اللهجات أو إضافة instruction في prompt. ## نقاط المراجعة البشرية – الوكيل دائماً يرى الاقتراح كـ Private Note قبل أي إرسال — لا رد تلقائي للعميل – الوكيل يعدّل (تحسين، تخصيص) أو يرفض الاقتراح بنقرة، ثم يرسل الرد النهائي بنفسه – محادثات بـ tags ‘legal’ أو ‘medical’ أو ‘complaint’ تتطلب تحويلاً لمتخصص قبل أي رد – اقتراحات بـ confidence منخفض (الـ RAG لم يجد مصادر قوية) تُمَيَّز للوكيل بـ ‘⚠ تحقق من الإجابة’ – مراجعة شهرية للنسبة: إذا قبول الاقتراحات < 40%، النموذج أو قاعدة المعرفة تحتاج تحسين ## اعتبارات الخصوصية محادثات Chatwoot قد تحوي بيانات شخصية (أسماء، عناوين، أرقام دفع). كل المعالجة يجب أن تكون على بنية المنظمة: • Ollama محلي — لا تستخدم OpenAI API لاقتراح الردود (سترسل بيانات العميل). • n8n self-hosted — لا n8n.cloud لهذا الـ workflow. • APITable لتسجيل المحادثات: شفّر القاعدة، صلاحيات على مستوى الصف. • قاعدة المعرفة في Open WebUI ليست حساسة عادة (وثائق عامة)، لكن إذا حوت معلومات داخلية، احصرها في Workspace خاص بالـ Support. • GDPR/PDPL: للعملاء الأوروبيين أو السعوديين، احفظ سجل حذف البيانات الشخصية حسب الطلب — تأكد أن APITable و Chatwoot كلاهما يدعمان هذا. ## ملاحظات الصيانة تحديث قاعدة المعرفة شهرياً: راجع المحادثات التي رفض الوكلاء اقتراحاتها، أضف الإجابات الصحيحة كوثائق. مراقبة جودة الاقتراحات أسبوعياً عبر تقارير APITable. ترقية النموذج عند صدور إصدارات جديدة من qwen — قد تحسّن الجودة جوهرياً. اختبار E2E شهرياً (محادثة وهمية → اقتراح → مراجعة) للتأكد أن لا شيء كسر.