لماذا تستضيف دعم عملائك ذاتيًا
لحلول دعم العملاء SaaS نموذج أعمال بسيط: تدفع لكل وكيل ولكل قناة، وتُخزَّن بيانات عملائك على خوادمهم. بالنسبة لوكالة ويب أو مؤسسة صغيرة ومتوسطة مغربية، يمكن أن تتراكم التكاليف بسرعة لتبلغ مئات الدراهم شهريًا حين يتجاوز الفريق شخصين أو ثلاثة. Chatwoot يعكس هذه المعادلة: تنشر المنصة على خادمك الخاص، وتدعو عدد الوكلاء الذي تحتاجه، وتربط جميع قنواتك بلا تكاليف إضافية. تبقى تبادلات عملائك على بنيتك التحتية — حجة قوية للامتثال لـGDPR وثقة العملاء وسيادة البيانات.
ما تحصل عليه مع Chatwoot المستضاف ذاتيًا
- صندوق وارد مشترك متعدد القنوات: دردشة مباشرة، بريد إلكتروني، WhatsApp، Telegram، Facebook Messenger ورسائل Twitter/X في لوحة تحكم واحدة.
- ودجت دردشة مباشرة قابل للتضمين: واجهة قابلة للتخصيص تُضاف إلى أي موقع ويب بسطرين من JavaScript.
- ردود جاهزة وقواعد أتمتة: التعيين التلقائي والرد الأول والتوجيه حسب اللغة أو الكلمة المفتاحية.
- تعاون الفريق: ملاحظات داخلية، تعيين المحادثات، الإشارات وطوابير الفريق المرئية لجميع الوكلاء.
- CRM مدمج: ملفات تعريف جهات الاتصال مع سجل المحادثات والسمات المخصصة والتصنيفات.
- واجهة برمجية REST وWebhooks: تكامل مع n8n أو Activepieces أو خادمك الخاص.
- رخصة MIT — بلا تسعير لكل وكيل، بلا بيانات ترسَل لطرف ثالث، سيادة كاملة.
المتطلبات الأساسية
يعمل Chatwoot بمكدس Ruby on Rails + Sidekiq + PostgreSQL 15 + Redis 7، أي أربع حاويات Docker. خطِّط لخادم VPS بذاكرة لا تقل عن 2 غيغابايت (يُوصى بـ4 غيغابايت لفرق تتجاوز 10 وكلاء). Ubuntu 24.04 مع Docker هو المسار الأسرع. على صعيد الشبكة، أعدّ نطاقًا فرعيًا — مثل support.your-domain.com — وبروكسي عكسي (Nginx أو Caddy) لتفعيل HTTPS. يستلزم Chatwoot FRONTEND_URL بصيغة HTTPS لعمل إعادة توجيه OAuth وروابط البريد الإلكتروني وسكريبت ودجت الدردشة المباشرة بشكل صحيح.
نشر Chatwoot على VPS في 6 خطوات
النشر بنقرة واحدة من Marketplace ServOrbit
افتح لوحة تحكم ServOrbit، اذهب إلى Marketplace ← التعاون والإنتاجية ← Chatwoot، ثم انقر على نشر. يسحب Docker صورة chatwoot/chatwoot:latest ويشغّل أربع حاويات: PostgreSQL وRedis وخادم Rails والعامل Sidekiq. عند الإقلاع الأول تعمل هجرة قاعدة البيانات تلقائيًا — انتظر 60 إلى 90 ثانية قبل توفر الواجهة.
إنشاء حساب المدير
اذهب إلى http://<IP-VPS>:3000. يعرض Chatwoot معالج الإعداد الأول: أدخل اسمك وبريدك الإلكتروني وكلمة مرور قوية. يصبح هذا الحساب المدير العام. يمكنك بعد ذلك دعوة وكلاء إضافيين وإنشاء فرق من لوحة الإعدادات.
تهيئة FRONTEND_URL وتفعيل HTTPS
وجِّه نطاقك نحو الخادم (سجل A → IP الخادم). ثبِّت Caddy (apt install -y caddy) وأنشئ /etc/caddy/Caddyfile: support.your-domain.com { reverse_proxy localhost:3000 }. أعد تحميل Caddy (systemctl reload caddy). ثم اضبط FRONTEND_URL=https://support.your-domain.com في ملف .env وأعد تشغيل حاوية الويب: docker compose restart web. يستخدم Chatwoot هذا العنوان لإعادة توجيه OAuth وروابط البريد وسكريبت الودجت.
إضافة أول صندوق وارد
في Chatwoot، اذهب إلى الإعدادات ← صناديق الوارد ← إضافة صندوق. اختر موقع الويب للدردشة المباشرة، أو البريد الإلكتروني للتبادلات SMTP/IMAP، أو قناة مراسلة مثل WhatsApp Cloud API أو Telegram. للدردشة المباشرة، انسخ سكريبت JavaScript المولَّد والصقه في <head> موقعك. يرى الزوار فور ذلك فقاعة الدردشة.
دعوة الوكلاء وتهيئة الأتمتة
اذهب إلى الإعدادات ← الوكلاء وأرسل دعوات بالبريد الإلكتروني. في الإعدادات ← الأتمتة، أنشئ قواعد لتعيين المحادثات تلقائيًا (مثلاً، WhatsApp ← فريق المبيعات، البريد ← الفوترة) وإرسال رسائل الاتصال الأول خارج ساعات العمل. يتولى عامل Sidekiq جميع المهام غير المتزامنة: إرسال رسائل البريد وتشغيل Webhooks وإشعارات الدفع.
ربط WhatsApp Business (اختياري)
أنشئ تطبيقًا في Meta for Developers وفعِّل WhatsApp Business Cloud API. في Chatwoot ← الإعدادات ← صناديق الوارد ← إضافة ← WhatsApp، أدخل رقم هاتف WhatsApp Business ومعرّف الحساب والرمز المميز ورمز التحقق من Webhook. تظهر رسائل WhatsApp الواردة الآن في صندوق الوارد المشترك جانب الدردشة المباشرة والبريد الإلكتروني.
تسجيل الدخول لأول مرة
افتح العنوان فور اكتمال التثبيت: تطالبك شاشة ترحيب بإنشاء أول حساب (الاسم والبريد وكلمة المرور)، ويصبح هذا الحساب مالك مساحة العمل.
أعدَّ الردود الجاهزة (الإعدادات ← الردود الجاهزة) منذ اليوم الأول: تأكيد الاستلام، تأكيد الطلب، مدد المعالجة. يوفّر وكلاؤك عدة دقائق لكل محادثة — واتساق الأسلوب مضمون بغض النظر عمّن يجيب. ادمجها مع قواعد الأتمتة لإرسال رد الاتصال الأول تلقائيًا ليلاً وعطل نهاية الأسبوع.
الوثائق الرسمية
للإعداد المتقدم (SMTP، LDAP SSO، تخزين S3، حسابات متعددة) والخيارات الخاصة بـChatwoot، راجع الوثائق الرسمية لـChatwoot المستضاف ذاتيًا. يغطي هذا الدليل النشر على VPS؛ وثائق المطوّر تبقى المرجع للإعدادات الدقيقة والتحديثات الكبرى.
الترقية من Chatwoot v3 إلى v4
أطلق Chatwoot الإصدار v4 في يونيو 2026 مع واجهة 'Nova UI' الجديدة وعدة هجرات مخطط PostgreSQL تعطيلية. ترقية في المكان من v3 تُعطّل المثيل بصورة منهجية إن لم تُجرَ بتحضير مسبق — وهذا موضوع المشكلة الرسمية #12088 التي ترصد أكثر حالات الفشل شيوعًا.
السبب الرئيسي للعطل: يُعيد v4 تسمية جدول mentions ويُعيد هيكلة جدول conversation_participants. تشغيل docker compose pull && docker compose up -d بلا نسخة احتياطية مسبقة يُطلق الهجرات تلقائيًا؛ إن فشلت هجرة في المنتصف (انتهاء المهلة، قيد FK غير محقق)، تبقى قاعدة البيانات في حالة وسيطة ولا يعود Chatwoot يعمل.
عمليًا، ثلاث فئات من المثيلات معرَّضة للخطر: تلك العاملة بـv3 مع أكثر من 50,000 محادثة (هجرات المجموعات الكبيرة بطيئة وقد تتجاوز مهلة Rails البالغة 30 ثانية)، وتلك التي تحتوي على أعمدة مخصصة غير موثقة في جدول contacts، وتلك التي تستخدم Sidekiq Pro (أُزيل من Community Edition في v4 — المهام في قائمة الانتظار وقت الهجرة تُفقَد).
إجراء الترقية من v3 إلى v4
نسخ قاعدة البيانات والأحجام احتياطيًا
قبل أي إجراء، احفظ الحالة الكاملة: docker compose exec postgres pg_dumpall -U postgres > /tmp/chatwoot-v3-dump-$(date +%F).sql. انسخ أيضًا أحجام Docker المرتبطة بـPostgreSQL وRails Storage. هذه النسخة الاحتياطية هي شبكة أمانك الوحيدة: إن فشلت الهجرة، الاستعادة هي المخرج النظيف الوحيد.
تثبيت علامة الصورة على v4
في docker-compose.yml، استبدل chatwoot/chatwoot:latest بـchatwoot/chatwoot:v4.0.2 (أو آخر إصدار ترقيعي لـv4). تجنّب latest في الإنتاج: تتبع هذه العلامة HEAD وقد تُدخل تراجعات دون إنذار. راجع سجل التغييرات لكل إصدار على GitHub قبل تحديد هدف.
تشغيل الهجرات يدويًا
بدلاً من ترك Rails تشغّل الهجرات عند بدء حاوية الويب، شغِّلها صراحةً في المقدمة لمراقبة التقدم: docker compose run --rm web bundle exec rails db:migrate. عند وقوع خطأ، تظهر الرسالة فورًا — تُحدّد الهجرة المعطوبة وتتيح تصحيحها أو تخطيها بـdb:migrate:up VERSION=... قبل إعادة التشغيل.
البدء والتحقق
بمجرد اكتمال الهجرات بلا أخطاء، ابدأ المكدس: docker compose up -d. سجّل الدخول إلى واجهة Nova UI وتأكد من وجود صناديق الوارد وجهات الاتصال والمحادثات الحالية. اختبر إرسال واستقبال رسالة على كل قناة متصلة. إن أظهر Sidekiq مهامًا فاشلة، استخدم واجهة Sidekiq Web (إن كانت مُفعَّلة على /sidekiq) لإعادة محاولتها.
تصحيح أمني v4.0.2: إبطال الرموز المميزة
يذكر سجل تغييرات Chatwoot v4.0.2 تصحيحًا في معالجة رموز المصادقة: في ظروف معينة، كانت الـmiddleware المصادقة في Rails تقبل رمزًا مُلغى من جهة الخادم حتى انتهاء صلاحية JWT الطبيعية. أثّر هذا على المثيلات التي لا يُجدَّد فيها user_access_token عند تسجيل الخروج الإجباري (انتهاء الجلسة، تغيير كلمة المرور، الإبطال من المدير).
إن كان مثيلك على v3 أو v4.0.0/v4.0.1، حدِّث إلى v4.0.2 كحد أدنى، ثم نفِّذ docker compose exec web bundle exec rails runner "UserAccessToken.where(revoked_at: ...Time.current).delete_all" لتنظيف الرموز المنتهية من قاعدة البيانات. هذا الإجراء لا يؤثر على الجلسات النشطة الشرعية: تُحذف فقط الرموز التي تحمل تاريخ revoked_at في الماضي.
