بناء CRM ولوحة تحكّم على Lovable — دليل عربي تطبيقي
خطوات بناء CRM كامل على Lovable: عملاء محتملون، جهات اتصال، صفقات ومراحل، أنشطة ومتابعة، صلاحيّات، سجلّ العميل، لوحة مؤشّرات، استيراد وتصدير، وحماية بيانات كلّ مستخدم عن الآخر.
١) العملاء المحتملون (Leads)
Lead هو أيّ شخص أبدى اهتمامًا ولم يتحوّل بعد لعميل. الجدول المقترح: leads(id، owner_id، full_name، email، phone، source، status، score، notes، created_at). اجعل status ENUM (new/contacted/qualified/lost). أضف نموذجًا عامًّا في صفحة الهبوط ينشئ Lead مع source='landing'. القاعدة: كلّ Lead مربوط بـowner_id = auth.uid() للمستخدم الذي يديره، ولا يُقرأ إلا عبر سياسة USING (auth.uid() = owner_id)، أو has_role للمدراء.
٢) جهات الاتصال (Contacts)
بعد تأهيل Lead يتحوّل إلى Contact. الجدول: contacts(id، owner_id، lead_id nullable، full_name، company، email، phone، position، tags text[]، created_at). أضف علاقة اختيارية بجدول companies لو احتجت CRM B2B. لا تدمج leads وcontacts في جدول واحد بحجّة «التبسيط» — تختلف السياسات، الحقول، وطبيعة العلاقة.
٣) الصفقات والمراحل (Deals & Stages)
الصفقة تمثّل فرصة بيع محدّدة القيمة. الجدول: deals(id، owner_id، contact_id، title، amount numeric، currency، stage، probability int، expected_close date، status). اجعل stage جدولًا مستقلاًّا stages(id، name، order، color) لتسمح بتخصيص المراحل (Lead → Qualified → Proposal → Won/Lost) من الواجهة بلا تعديل schema. اعرضها في لوحة Kanban قابلة للسحب والإفلات، وحدّث stage عبر server function للتحقّق من الصلاحيات.
٤) الأنشطة والمتابعة
أنشئ جدول activities(id، owner_id، deal_id، contact_id، type، subject، due_at، done_at، notes)، حيث type ENUM (call/email/meeting/task). صفحة «اليوم» تعرض كلّ الأنشطة المستحقّة لهذا المستخدم فقط. أضف تذكيرات بريديّة عبر Lovable Email قبل ساعة من due_at. لا تسمح بحذف نشاط مكتمل — علّمه مؤرشفًا فقط لتحافظ على السجلّ.
٥) الصلاحيات (Roles & Teams)
استخدم النمط القياسي: ENUM app_role ('owner','manager','sales','viewer')، جدول user_roles، ودالّة has_role SECURITY DEFINER. Owner يرى كلّ شيء، Manager يرى فريقه، Sales يرى صفقاته فقط، Viewer قراءة فقط بلا تعديل. طبّق ذلك داخل سياسات RLS مباشرة، ولا تعتمد على إخفاء الأزرار في الواجهة كطبقة أمان.
٦) سجلّ العميل (Timeline)
ابنِ جدول activity_log(id، actor_id، entity_type، entity_id، action، diff jsonb، created_at) عبر trigger على contacts وdeals. عند فتح Contact اعرض Timeline موحّدة: 'أنشأ سلمى الصفقة'، 'حدّث المرحلة إلى Proposal'، 'أضاف مكالمة'. هذا السجلّ يُنقذك في الخلافات ويعطي شعورًا احترافيًّا للمنتج.
٧) لوحة المؤشّرات
لوحة واحدة لا لوحات. اعرض 4-6 مؤشّرات فقط: عدد Leads الجدد هذا الأسبوع، معدّل التحويل إلى صفقة، Pipeline (مجموع قيمة الصفقات المفتوحة)، MRR/الإيراد المُغلَق شهريًّا، عدد الأنشطة المتأخّرة. استخدم views في قاعدة البيانات لحساب الملخّصات بدل الحساب في المتصفّح. اجعل كلّ مؤشّر قابلًا للنقر للتعمّق.
٨) الاستيراد والتصدير
لكلّ CRM جدّي: استيراد CSV وتصدير CSV. للاستيراد أنشئ صفحة تعرض معاينة أوّل 5 صفوف، ثمّ خريطة أعمدة (Column Mapping): «اعمود A = full_name، B = email». نفّذ الاستيراد داخل server function مع تحقّق من المكرّرات (email موجود مسبقًا). للتصدير، ولّد ملف CSV UTF-8 مع BOM لعرض العربية بشكل صحيح في Excel.
٩) منع تسرّب البيانات بين المستخدمين
أخطر خطأ في CRM أن يرى مستخدم بيانات آخر. اختبر يدويًّا: سجّل بحسابين مختلفين، افتح devtools، جرّب استعلامًا مباشرًا على جدول deals للمستخدم الآخر — يجب أن يعود فارغًا. أضف اختبار Playwright يفشل إن ظهر أيّ صفّ لا يخصّ المستخدم. لا تعتمد على WHERE في استعلام الواجهة كطبقة أمان — RLS هي الطبقة الوحيدة الموثوقة.
قائمة تحقّق قبل الإطلاق
RLS مفعّلة على كلّ الجداول، has_role مستخدم في السياسات، Timeline يعمل، الاستيراد/التصدير يعمل مع العربية، لوحة مؤشّرات تُحمَل في أقلّ من ثانية، اختبار عزل البيانات ناجح، وسجلّ الأنشطة يظهر آخر 10 عمليات في الصفحة الرئيسية. عند اكتمال هذه القائمة، CRM جاهز للاستخدام الحقيقي.
- هيرو تحريري لصفحة هبوطهيرو مقسّم 8/4 بدون تدرّجات، بأسلوب Stripe/Linear.
هل كان هذا المحتوى مفيداً؟
استلم أحدث الأدلّة والبرومبتات كل أسبوع
خلاصة عربية أسبوعية عن Lovable وVibe Coding — بلا سبام، إلغاء متى شئت.