سوق رقمي بثلاثة أدوار للمستخدمين: شرح المعمارية على مثال Vsedomatut

في أبريل 2026 أطلقنا سوق العقارات Vsedomatut خلال 3 أسابيع. داخل المنصة ثلاثة أنواع من الحسابات وتكامل مع نظام Odoo/Zoho-Bitrix (منصة CRM روسية) أبقى سير العمل القائم لدى العميل. في ما يلي شرح للمعمارية بلا نظرية زائدة.

ما هو السوق الرقمي بثلاثة أدوار

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

في حالة Vsedomatut توزّعت الأدوار على النحو التالي:

• المشتري — يبحث عن شقة، ويترك طلبًا، ويحفظ الإعلانات التي تهمه.
• الوكيل / المالك — ينشر الإعلانات مباشرة ويرد على الطلبات.
• الشريك — شركة خارجية تقدّم الإعلانات عبر حساب منفصل مع مراجعة إلزامية.

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

لماذا احتجنا إلى حساب الشريك

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

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

المعمارية — كيف تعمل تقنيًا

ثلاثة حسابات لا تعني ثلاثة مواقع منفصلة. إنها نظام مصادقة واحد بمسارات لوحات تحكم مختلفة وصلاحيات API مختلفة. المصادقة في Vsedomatut مبنية على JWT مخصصة — حل من دون خدمات خارجية، يلائم البنية التحتية الروسية للعميل.

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

• الواجهة الأمامية: Next.js + TypeScript + Tailwind.
• الخادم: Node.js + PostgreSQL.
• المصادقة: JWT مخصصة من دون منصة تفويض خارجية.
• التكامل: واجهة برمجة Odoo/Zoho-Bitrix لمزامنة الكتالوج.
• لوحة الإدارة: أكثر من 50 وظيفة — مراجعة، تحليلات، مستخدمون، أدوار، إشعارات.

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

كيف وزّعنا الصلاحيات بين الأدوار

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

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

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

كيف تعمل مراجعة الإعلانات

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

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

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

ماذا أعطى التكامل مع Odoo/Zoho-Bitrix

كان لدى مارات نظام داخلي على Odoo/Zoho-Bitrix يحتوي قاعدة عقارات. إنشاء قاعدة ثانية كان سيكسر سير العمل المعتاد للفريق. لذا يقرأ السوق الرقمي البيانات عبر واجهة برمجة Bitrix ويعيد إليه حالات الطلبات.

حلّ هذا التكامل ثلاث مشاكل تحديدًا:

• لم نضطر إلى نقل البيانات إلى نظام منفصل عند الإطلاق.
• استمر المديرون في العمل ضمن واجهة Bitrix المألوفة.
• يتحدّث الكتالوج على الموقع تلقائيًا لا عبر جداول يدوية.

شرح أعمق للنهج headless في مقالة «متى ننتقل من Odoo/Zoho-Bitrix إلى Next.js».

المدة والسعر

أُطلق Vsedomatut خلال 3 أسابيع من توقيع العقد إلى الإطلاق العام. كان السعر ثابتًا — لا تقديرات بالساعة تتضخم مع كل توضيح. شملت المرحلة الأولى ثلاثة حسابات، ولوحة إدارة بمراجعة، وتكامل واجهة برمجة Bitrix، وإعداد SEO أساسي، وتصميم متجاوب.

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

ما الذي يجب التفكير فيه قبل التطوير

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

السؤال الثاني هو مصدر الحقيقة. في Vsedomatut بقي هذا المصدر داخل نظام Bitrix لدى العميل. أبقى ذلك سير العمل على حاله. في مشروع آخر قد يكون المصدر CRM أو ERP أو PostgreSQL أو واجهة برمجة شريك. القاعدة الأساسية: تجنّب وجود قاعدتي بيانات متساويتين تنحرف إحداهما عن الأخرى بعد أسبوع من الإطلاق.

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

لماذا هذه ليست مجرد «منطقة شخصية»

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

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

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

أي مؤشرات يجب أن يراقبها صاحب العمل

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

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

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

لماذا لوحة الإدارة أهم مما تبدو

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

تشمل لوحة Vsedomatut أكثر من 50 وظيفة: إدارة الإعلانات، المستخدمين، الأدوار، المراجعة، الطلبات، الإشعارات، والتحليلات. هذه ليست «تفاصيل داخلية»، بل مكان عمل الفريق. هنا يُحسم المسار من إعلان الشريك إلى النشر في الكتالوج.

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

متى تناسب هذه المعمارية أعمالكم

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

• لديكم مجموعة من موردي المحتوى الخارجيين: شركاء، وكلاء، تجار.
• يجب مراجعة المحتوى قبل النشر.
• على المشترين التواصل مع الموردين مباشرة.
• لديكم بالفعل نظام CRM أو نظام إدارة آخر لا تريدون كسره.
• تحتاجون تحليلات لكل دور بشكل منفصل.

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

الأسئلة الشائعة

كم تكلف منصة سوق رقمي بثلاثة أدوار؟

يعتمد على عدد التكاملات وتعقيد المنطق. النسخة الأساسية بثلاثة حسابات ولوحة إدارة تبدأ من 16,500 درهم إماراتي — سعر ثابت، 3 إلى 4 أسابيع من العمل. السعر النهائي يُحسب بعد جلسة قصيرة لمراجعة المهمة. ضريبة القيمة المضافة غير مشمولة.

هل يمكننا البدء بدورين وإضافة الثالث لاحقًا؟

نعم. تُبنى المعمارية مع توقّع توسعة الأدوار من اليوم الأول. إضافة دور جديد لاحقًا تستغرق عادةً 5 إلى 10 أيام.

هل التكامل مع Odoo/Zoho-Bitrix إلزامي؟

لا. لدى مارات كان Bitrix جاهزًا، لذلك تكاملنا معه. إذا كان لديكم CRM مختلف، أو نظام مخزون، أو لا شيء على الإطلاق، تبقى المعمارية كما هي ويتغيّر مصدر البيانات فقط.

من يراجع إعلانات الشركاء؟

أي مستخدم لديه صلاحية المراجعة في لوحة الإدارة. لدى مارات فريق صغير من شخصين يستعرضان الإعلانات الواردة ويقبلانها أو يرفضانها مع تعليق.

هل يمكن إطلاق سوق رقمي من دون مطوّرين داخليين؟

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

هل تريدون سوقًا رقميًا مماثلًا؟

إذا أردتم مقارنة هذا الشكل بصيغة أبسط، اطّلعوا على مقالة «كم تكلف صفحة هبوط وما الذي تدفعون مقابله». وللاطلاع على المسائل التقنية، تنفع مقالة «متى ننتقل من Odoo/Zoho-Bitrix إلى Next.js». باقي المواد في قائمة المدونة.