عبدالله الكندي يقارن تسعير SaaS: ثابت، لكل مستخدم، أو حسب الاستخدام

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

المثال اللي بنقيس عليه

نظام سحابي لإدارة مواعيد العيادات، وثلاثة عملاء. الأرقام هنا افتراضية للتوضيح، مو أسعار سوق:

• عيادة صغيرة: طبيب وموظفة استقبال، يعني مستخدمَين، وحوالي ٣٠٠ موعد في الشهر.
• مجمّع متوسط: ثمانية مستخدمين، وحوالي ٢٠٠٠ موعد.
• مجموعة طبية بعدة فروع: ثلاثين مستخدم، وحوالي ٩٠٠٠ موعد.

النموذج الأول: اشتراك ثابت للكل

لنفترض ٢٩٩ ريال شهرياً لأي عميل. العيادة الصغيرة تدفع ٢٩٩، والمجمّع ٢٩٩، والمجموعة ٢٩٩.

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

النموذج الثاني: لكل مستخدم

لنفترض ٧٩ ريال لكل مستخدم. العيادة تدفع ١٥٨، والمجمّع ٦٣٢، والمجموعة ٢٣٧٠. فجأة السعر يكبر مع العميل، وهذا منطقي ومفهوم للكل.

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

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

النموذج الثالث: حسب الاستخدام

لنفترض نص ريال لكل موعد. العيادة تدفع ١٥٠، والمجمّع ١٠٠٠، والمجموعة ٤٥٠٠. هنا السعر مربوط مباشرة بالقيمة: اللي يستفيد أكثر يدفع أكثر، والصغير يدخل بتكلفة منخفضة.

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

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

اختبار مقياس القيمة

السؤال الحقيقي مو «أي نموذج؟» بل «وش الوحدة اللي أربط فيها السعر؟». المقياس الجيد يجتاز أربعة اختبارات:

• يكبر لما تكبر استفادة العميل من النظام، مو لأي سبب ثاني.
• العميل يقدر يتوقعه قبل نهاية الشهر بدون آلة حاسبة.
• تقدر تقيسه بدقة بدون ما يفتح باب نزاع.
• ما يعاقب السلوك اللي تبيه: إضافة الفريق، أو استخدام النظام أكثر.

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

اللي ينتهي له أغلب الناس: باقات بحدود

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

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

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