عدة شركات، تركيب واحد، بلا زبائن مشتركين

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

iKonekt يشغلهم كلهم من تركيب واحد، والفصل بينهم محفوظ في قاعدة البيانات ماشي في الكود. هذا التمييز يبان أكاديمي حتى اليوم اللي ما يبقاش كذلك.

شنو المجموعة فعلاً تقدر تشارك

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

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

السؤال اللي المجموعة دايماً تسأله ثانياً

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

والسؤال اللي يسألوه ثالثاً: "شنو يصير إذا بِعنا إحدى العلامات؟" الحد اللي قاعدة البيانات تحفظه هو أيضاً حد تقدر تطلع منه نسخة نظيفة. هذا ماشي صدفة — الفصل وقابلية النقل هما نفس الخاصية من اجتماعين مختلفين.