إنشاء منصة خدمات محلية: ما تبنيه في النسخة الأولى

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

ما الذي تبيعه المنصة فعلاً#

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

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

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

من أين يبدأ إنشاء منصة خدمات محلية#

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

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

1. اختر خدمة واحدة ونطاقاً جغرافياً واحداً

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

2. اجمع مقدمي الخدمة يدوياً قبل أي كود

   قابل عشرة أو خمسة عشر فنياً، وتحقق من هوياتهم وأعمالهم بنفسك، واتفق معهم على السعر والعمولة كتابة. هذه القائمة هي أصل المشروع الحقيقي.

3. أطلق نسخة أولية تقبل الطلبات وتوزعها

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

4. أدخل الدفع والعمولة بعد ثبات الطلبات

   حين يستقر تدفق الطلبات، اربط بوابة الدفع واجعل التحصيل داخل المنصة. الدفع الإلكتروني قبل وجود طلبات منتظمة يضيف تعقيداً بلا مقابل.

مشكلة العرض والطلب في الأسابيع الأولى#

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

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

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

كيف تحصّل عمولتك على كل طلب#

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

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

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

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

التحقق من مقدم الخدمة وحل الخلافات#

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

بيانات الهوية والعناوين وأرقام الجوال بيانات شخصية، ومعالجتها تخضع لنظام حماية البيانات الشخصية (PDPL) الذي تشرف عليه الهيئة السعودية للبيانات والذكاء الاصطناعي. عملياً هذا يعني أن تجمع ما تحتاجه فقط، وأن تحدد من يطّلع عليه داخل فريقك، وأن تكتب سياسة خصوصية تشرح مدة الاحتفاظ.

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

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

موقع أم تطبيق في النسخة الأولى#

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

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

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

أسئلة شائعة#

كم تستغرق منصة خدمات حتى الإطلاق؟#

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

هل أبني تطبيق مقدم الخدمة أولاً أم تطبيق العميل؟#

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

كيف أمنع اتفاق الطرفين خارج المنصة؟#

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

هل أحتاج ترخيصاً لتشغيل منصة خدمات؟#

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

ما الذي تقرره قبل أول سطر برمجي#

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