كل عميل يبي تعديل خاص: كيف تخصّص نظام SaaS بلا ما تتفرّع الكود؟

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

القاعدة الذهبية: كود واحد، سلوك مختلف

في SaaS الصحي، كل العملاء يشتغلون على نفس الكود ونفس النسخة. الاختلاف بينهم يجي من البيانات والإعدادات، مو من ملفات برمجية مختلفة. يعني بدل «نسخة شركة س»، عندك «إعداد: الموافقة على مرحلتين = مفعّل» لشركة س فقط.

أدوات التخصيص الأربع

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

كيف تتعامل مع طلب تخصيص جديد؟

قبل ما تقول نعم أو لا، مرّر الطلب على هذا الفلتر:

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

مفاتيح الميزات أكثر من مجرد تخصيص

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

أخطاء تجعل التخصيص كابوساً

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

مثال عملي: طلب «موافقة على مرحلتين»

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

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

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

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

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

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