عبدالله عبدالرحيم الكندي: دروس «يوجيسير» في بناء سوق يربط طرفين

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

الدرس الأول: الطرفين ما يجون مع بعض

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

الدرس الثاني: الثقة هي المنتج الحقيقي

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

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

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

الدرس الثالث: الدعم جزء من البنية، مو ملحق

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

الدرس الرابع: الإحالة تحل جزء من مشكلة البداية

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

الدرس الخامس: لوحة الإدارة أكبر مما تتوقع

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

الدرس السادس: مراجعة المتجر جزء من الخطة

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

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